[PDB Tech] Are we ready for the next step in IP management ?
raja mohan marappan
raja.mohan at myix.my
Wed May 10 23:12:35 PDT 2017
Thanks. I have rectified.
On 8 May 2017 at 17:41, 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/pdb-tech/attachments/20170511/3047d967/attachment-0001.html>
More information about the Pdb-tech
mailing list