[PDB Tech] Are we ready for the next step in IP management ?
Hugo Slabbert
hugo at slabnet.com
Mon May 8 08:36:19 PDT 2017
>I can't explain the /128's ...as that's not a "LAN".
...
>Third case. What about DIX ?
...
>| 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. :)
Seems like they are/were trying to provide their route server IPs somehow
within the LAN field. I haven't tracked this down in the docs; is there a
canonical way for an IX to indicate its route server info?
--
Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E | also on Signal
[1] https://www.peeringdb.com/apidocs/#!/ix
On Mon 2017-May-08 02:41:07 -0700, Martin J. Levy <mahtin at mahtin.com> 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
>Pdb-tech at lists.peeringdb.com
>http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.peeringdb.com/pipermail/pdb-tech/attachments/20170508/f052b8eb/attachment.sig>
More information about the Pdb-tech
mailing list