A number of the points you raise have already been addressed.

The IPV6 Reverse resolution question has been discussed at length in
DNSEXT previously. In fact, it was proposed to remove reverse resolution
entirely from IPV6 for just the reason Dr. Huang notes.  A 128 bit IPV6
address is 16 octets. To perform reverse resolution requires traversing
16 levels of DNS tree. Even the delegations impose significantly larger
trees on the registries. It is recognized that this isn't going to be
very scalable, or even possible.  IPV6 proposes to use ICMP Node
Identification query instead.  At present, there is an IPV6 reverse
tree, but it is not guarenteed it will stay. It is for transition--so
that gethostbyaddr() still works on IPv6 during transition.

See for example the discussions here:

http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html

                --Dean

On Sat, 28 Jun 2008, Phil Regnauld wrote:
>       
> >    2.3 Reverse Resolution
> > 
> >    Reverse Resolution uses .IN-ADDR.ARPA domain today. In IPv6,
> >    .IP6.ARPA was defined by [RFC3152], and more detail information can
> >    be found in [RFC3596]. Because IPv6 has a huge Name Space, it is
> >    difficult to keep reverse RRs in today's architecture.
> 
>       Question: Why ?
> 
>       Yes, IPv6 space is immense, but for the foreseeable future, only a
>       very small part of it will be populated.  Same goes for IP6.ARPA.
>       But there are no data, either by you or others, supporting the
>       claim that it will be more difficult to accomodate reverse
>       information as IP6.ARPA grows.
> 
>       Do you have some simulation, model or other data-based prediction
>       that can be used to illustrate this problem ?


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to