[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