Thanks. I have rectified. On 8 May 2017 at 17:41, Martin J. Levy <[email protected]> wrote:
> WE still keep IP's in string fields. This email is NOT about that issue > (but I know it would help). > > I'm focusing on how we can improve some of our IP address fields and make > sure that we have some increased form of authentication of user-entered > IPs. > > This assume a pre IX-F world; but in fact there's zero reason to say that > statement. IX-F exists and yet I think I can continue to proceed > independent of that. > > Background: I've focused once or twice (along with Grizz, Andy D, etc) in > the IPs used within PeeringDB (1.0 and 2.x). Collectively, we have cleaned > up so much crud; however there more to do. > > Here are some dumps of data that may show some still incorrect data. I'm > singularly focusing on the *prefix* column of the *peeringdb_ixlan_prefix* > table. > > So I want to address a few LANs as I believe there's nearly always a need > for these to actually be something different (/64's being the norm for v6, > /24's for v4). > > In the first case, I think we have some interesting choices out there (and > the HKIX allocation was a good example of an early v6 IX allocation); > however it's now now and these seems wrong. I can't explain the /128's ... > as that's not a "LAN". > > ; > > ; IPv6 smaller than /64's > > ; > > > mysql> SELECT peeringdb_ix.name AS ix_name, peeringdb_ix.country AS > ix_cc, peeringdb_ixlan.name AS prefix_name, protocol, prefix > > FROM peeringdb_ixlan_prefix > > LEFT JOIN peeringdb_ixlan ON peeringdb_ixlan.id = > peeringdb_ixlan_prefix.ixlan_id > > LEFT JOIN peeringdb_ix ON peeringdb_ix.id = peeringdb_ixlan.ix_id > > WHERE prefix LIKE '%/9%' OR prefix LIKE '%/1%' > > ORDER BY ix_cc, ix_name; > > +---------------+-------+----------------+----------+------- > ----------------------------+ > > | ix_name | ix_cc | prefix_name | protocol | prefix > | > > +---------------+-------+----------------+----------+------- > ----------------------------+ > > | TorIX | CA | | IPv6 | > 2001:504:1a::34:0/111 | > > | WPGIX | CA | | IPv6 | 2001:504:2c::/116 > | > > | DIX | DK | rs01.dix.dk | IPv6 | > 2001:7f8:1f::248/128 | > > | DIX | DK | rs02.dix.dk | IPv6 | > 2001:7f8:1f::249/128 | > > | FR-IX | FR | | IPv6 | > 2001:7f8:59:0:75::/96 | > > | MyIX | MY | | IPv6 | 2001:de8:10::/112 > | > > | EPIX.Katowice | PL | | IPv6 | 2001:7f8:5b::1/128 > | > > | DataLine-IX | RU | SHARED-UNICAST | IPv6 | > 2001:7f8:62:52::100/128 | > > | DataLine-IX | RU | SHARED-UNICAST | IPv6 | > 2001:7f8:62:52::200/128 | > > | TPIX-TW | TW | | IPv6 | > 2406:d400:1:133:203:163:222:0/112 | > > | UA-IX | UA | | IPv6 | 2001:7f8:5d::/116 > | > > +---------------+-------+----------------+----------+------- > ----------------------------+ > > 11 rows in set (0.01 sec) > > mysql> > > In the second case, I think these are RIR allocations placed in PDB vs the > allocated LAN. I skipped the /48's as there are tons of those! > > I believe they also really operate as /64's. > > ; > > ; These are IXs that have placed their site allocations into PDB vs their > LAN. In all cases, I bet they are really /64's > > ; > > > mysql> SELECT peeringdb_ix.name AS ix_name, peeringdb_ix.country AS > ix_cc, peeringdb_ixlan.name AS prefix_name, protocol, prefix > > FROM peeringdb_ixlan_prefix > > LEFT JOIN peeringdb_ixlan ON peeringdb_ixlan.id = > peeringdb_ixlan_prefix.ixlan_id > > LEFT JOIN peeringdb_ix ON peeringdb_ix.id = peeringdb_ixlan.ix_id > > WHERE protocol = "IPv6" AND ( ( prefix LIKE '%/32' OR prefix LIKE > '%/4%' OR prefix LIKE '%/5%' ) AND prefix NOT like '%/48' ) > > ORDER BY ix_cc, ix_name; > > +--------------+-------+--------------+----------+-----------------------+ > > | ix_name | ix_cc | prefix_name | protocol | prefix > | > > +--------------+-------+--------------+----------+-----------------------+ > > | AuvernIX | FR | AuvernIX LAN | IPv6 | 2001:7f8:81::/56 | > > | AuvernIX | FR | LyonIX LAN | IPv6 | 2001:7f8:81:100::/56 | > > | Hopus | FR | | IPv6 | 2a02:e5c::/32 | > > | IX Liverpool | GB | Titanic | IPv6 | 2001:7f8:a2::/49 | > > | IX Liverpool | GB | Mersey | IPv6 | 2001:7f8:a2:8000::/49 | > > | SGIX | SG | | IPv6 | 2001:de8:12::/56 | > > +--------------+-------+--------------+----------+-----------------------+ > > 5 rows in set (0.00 sec) > > mysql> > > Third case. What about DIX ? We seem to allow: > > mysql> SELECT peeringdb_ix.name AS ix_name, peeringdb_ix.country AS > ix_cc, peeringdb_ixlan.name AS prefix_name, protocol, prefix > > FROM peeringdb_ixlan_prefix > > LEFT JOIN peeringdb_ixlan ON peeringdb_ixlan.id = > peeringdb_ixlan_prefix.ixlan_id > > LEFT JOIN peeringdb_ix ON peeringdb_ix.id = peeringdb_ixlan.ix_id > > WHERE ix_name = 'DIX' > > ORDER BY ix_cc, ix_name; > > +---------+-------+-------------+----------+----------------------+ > > | ix_name | ix_cc | prefix_name | protocol | prefix | > > +---------+-------+-------------+----------+----------------------+ > > | DIX | DK | | IPv6 | 2001:7f8:1f::/48 | > > | DIX | DK | DIX LAN | IPv4 | 192.38.7.0/24 | > > | DIX | DK | DIX LAN | IPv6 | 2001:7f8:1f::/64 | > > | DIX | DK | rs01.dix.dk | IPv4 | 192.38.7.248/32 | > > | DIX | DK | rs01.dix.dk | IPv6 | 2001:7f8:1f::248/128 | > > | DIX | DK | rs02.dix.dk | IPv4 | 192.38.7.249/32 | > > | DIX | DK | rs02.dix.dk | IPv6 | 2001:7f8:1f::249/128 | > > +---------+-------+-------------+----------+----------------------+ > > 7 rows in set (0.01 sec) > > mysql> > > A /48 and a /64 (plus two /128's). Huh? I guess we are an IPAM now. :) > > While these are the v6 examples, the same holds true for v4; but with > plenty of variance. ESPANIX is a pair of /25's (from a single /24) that > make up their two LANs. No issue there. There's are plenty or /23 or /22 > LANs and there are some smaller lLANs. > > There is some background here. The prefix column technically defines the > range of an IP see within the *ipaddr4* and *ipaddr6* fields within > *peeringdb_network_ixlan*. That is a vital restriction placed on the > users data. > > I would like to recommend a cleanup or realization of why we have this > extra data in the *peeringdb_ixlan_prefix* table. > > Thought, > > Martin > > > > _______________________________________________ > Pdb-tech mailing list > [email protected] > http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech > >
_______________________________________________ Pdb-tech mailing list [email protected] http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
