> > This document is also ignoring the IP6.INT counterpart for the
> > IP6.ARPA addresses above. IP6.INT is in the process of being wound
> > up with clients already not querying for this suffix.
>
> IP6.INT was deprecated in RFC 4159. It is no longer in the process of
> being wound up.
As long as there are clients which make IP6.INT queries as
the result of calling getnameinfo(), etc. it is in the
process of being wound up. I expect there will be a very
long tail here but so long as the traffic doesn't get too
large it should not be a issue.
Removing "counterpart for the IP6.ARPA addresses above"
would be appropriate.
Note: my IPv6 provider [Bcc'd] hasn't yet removed the
delegation for my /64 under ip6.int. I'm not going to stop
serving the zone until that delegation is removed or the
parent zone is removed. I suspect most end user sites are
in the same position.
Cleaning up IP6.INT has to be a top down process. The top
has started by the RIR's should, if they havn't already,
inform all the old registants under IP6.INT that the
delegation has been removed and that they no longer need
to serve the next zone down. This should ripple down
from there.
Yes I could unilaterally stop serving but that would break
thing rather than resulting in NXDOMAIN being returned for
the few sites that can still resolve the names.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
