North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: v6 gluelessness

  • From: Joe Abley
  • Date: Tue Jan 22 11:18:32 2008

On 22-Jan-2008, at 03:47, Stephane Bortzmeyer wrote:

Currently, with the present ICANN procedures, this is not an
option. ICANN knows only the TLD managers, not the nameserver
managers. For ICANN, depends on the TLD it serves, not on
Randy Bush. (It would be a sensible model, but a different model, with
different actors.)

With the current process, renumbering servers can be a lot of work: imagine arranging for (say) twenty different TLD managers of varying responsiveness and with different first languages to send the same message at roughly the same time to IANA, and then imagine the collation exercise required at the IANA to match together the non- synchronised and inconsistent requests that actually arrive.

This perhaps goes some way to explain the observed actions of TLD nameserver operators to either avoid or limit the pain of renumbering. Many servers are now numbered out of PI /24s which are used for nothing else; the RIPE NCC's approach (of not re-using the same nameserver name) has already been mentioned.

Randy's goal of adding an AAAA record in the root zone to is, in effect, an exercise in renumbering (even though it's adding an address, rather than changing an existing one).

Based on what I've seen, the pragmatic approach is:

1. Renumbering is hard, but there's no workaround, so get ready to endure the pain.

2. Do what you can to avoid having to experience the pain again.

In this case, (2) might involve not only adding the AAAA (and, ideally, doing so from a PI /48 assigned under an RIR's critical infrastructure policy, and never using that /48 for anything else), but also renumbering's IPv4 address into a similarly PI / 24. If there was ever a desire to change the name of the nameserver, this would also be the time to do it.

This doesn't fix anything for anybody who follows, of course.