There is an easy solution -- do not allocate less than /16s. This would relieve InterNIC from caring about IN-ADDRs (and will do good things for routing, too). --vadim All ISPs receiving /16 prefix blocks from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes longer than /16 issued directly from the InterNIC. I think you mean shorter, as in: The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes SHORTER than /16 issued directly from the InterNIC. No, I think he means longer. IN-ADDR.ARPA can only be delegated on octet boundaries, so IN-ADDR for /16 and shorter prefixes will be delegated in /16 chunks. IN-ADDR for prefixes longer than /16 must still be maintained by the root, since they cannot be delegated. For example, assume an ISP has been allocated the prefix 204.160/14. Along with this, the InterNIC will delegate the corresponding IN-ADDR domains: 160.204.IN-ADDR.ARPA 161.204.IN-ADDR.ARPA 162.204.IN-ADDR.ARPA 163.204.IN-ADDR.ARPA If the ISP were instead only assigned 204.160.0/17, the associated IN-ADDR range would be: 0.160.204.IN-ADDR.ARPA ... 127.160.204.IN-ADDR.ARPA which is not octet-aligned and therefore cannot be delegated. --Vince
There is an easy solution -- do not allocate less than /16s. This would relieve InterNIC from caring about IN-ADDRs (and will do good things for routing, too).
--vadim
All ISPs receiving /16 prefix blocks from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes longer than /16 issued directly from the InterNIC.
Of course that violates the NIC charter as being the NIC of first and last resort. -- --bill
There is an easy solution -- do not allocate less than /16s. This would relieve InterNIC from caring about IN-ADDRs (and will do good things for routing, too). --vadim
And how will this help reduce routing entries caused by people punching holes in existing and new CIDR blocks? As I've argued elsewhere, in the end service providers *must* start filtering something to protect their own infrastructure. Why not filter long prefixes if those prefixes were easy to determine? Relying on the registries is just a delaying action that encourages bad behavior.
Of course that violates the NIC charter as being the NIC of first and last resort.
Big deal. Regard, -drc
Of course that violates the NIC charter as being the NIC of first and last resort.
Big deal.
There is a rather significant chunk of address space is allocated to people who will never connect to the Internet that have rejected rfc1597 for whatever reason. Mark -- Mark Kosters markk@internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services
No, I think he means longer. IN-ADDR.ARPA can only be delegated on octet boundaries, so IN-ADDR for /16 and shorter prefixes will be delegated in /16 chunks. IN-ADDR for prefixes longer than /16 must still be maintained by the root, since they cannot be delegated. this is a very bad thing, since it forces an ip NETWORK provider also to deal with the DNS of its customers, not just to assign a pointer to their DNS. when is this problem solved? with ipv6? -- juha
participants (5)
-
bmanning＠ISI.EDU -
David R Conrad -
Juha Heinanen -
Mark Kosters -
Vadim Antonov