[PDB Tech] Are we ready for the next step in IP management ?
Martin J. Levy
mahtin at mahtin.com
Mon May 8 02:41:07 PDT 2017
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/pdb-tech/attachments/20170508/99175dfb/attachment-0001.html>
More information about the Pdb-tech
mailing list