> On Fri, Apr 07, 2006 at 12:30:23PM +1000, Mark Andrews wrote:
> >
> > > > http://v6fix.net/docs/ip6.int show that a number of current
> > > > resolvers are still falling back to IP6.INT. Until these
> > > > resolvers are corrected to be arpa (nibble) only the load
> > > > on the IP6.INT servers will only increase.
> > >
> > > presuming IANA leaves that delegation in place...
> > > if they pull it, the load goes to the INT servers...
> > > me, i'd need a COMPELLING reason to pull the delegations.
> > > i've not heard one yet... but its not my call. :)
> > >
> > > --bill
> >
> > Ask Sun why they still fallback to IP6.INT.
> > Ask the glibc developers why they still fallback to IP6.INT.
>
> nope... the IETF has been preaching the death of ip6.int for
> years and have declared it to historic, depricated, et.al.
> ... kind of like what happened when the IETF declared RIPv1 dead.
There is a big difference between declaring RIPv1 dead and
declaring IPv6.INT dead. Using RIPv1 between consenting
parties doesn't impact on other people. Continuing to
perform ip6.int queries impacts on other people. We wouldn't
behaving this debate if there wasn't a impact.
This is very much a case of "nip it in the bud".
> if developers have their own reasons for ignoring IETF edicts
> there is zero percentage in my asking them questions. Or was this
> a retorical question?
>
> > I suspect the answers will be: "there is still information
> > under IP6.INT that is not available under IP6.ARPA,
> > in-particular local information and we can't break local
> > reverse lookups for our customers."
>
> Perhaps ... it took several heroic efforts to undo some (imho)
> misguided attempts to restrict any DNS entries in reverse maps to
> RIR's or their customers. the 3ffe:: delegation took a serious hit
> with that "change"... There is still some vestigal goo that only
> sits in ip6.int...
>
> > To be able to close down IP6.INT you have to get all the
> > vendors to stop querying IP6.INT or remove the data available
> > under IP6.INT globally.
>
> but whats the point? instead of shooting the horse and trying
> to get unstuck from the mess left behind, a credible stratagy is
> to just leave the delegations in place to deal w/ the leftovers...
> eventually, after a suitable(*) mourning period, pull the delegations.
> whats the rush? RIRs are not going to populate any data in this
> part of the tree... this might be enough clue for OS/developers
> to figure out that the ip6.arpa arguement, while technically lame,
> is the wave of the future and they can be persuaded to change...
>
> * imho 3 - 5 years. i think it is finally time to shut off the pre-6bone
> delegation... the servers have gotten less than 10 queries this year... and
> 4 of them have been from me... :)
People stopped using those address. They are not going to stop
using IPv6 in general.
How will you know when it is time to pull the delegations if you
don't pull them now? What metric do you intend to use? Is that
metric currently being met?
At the moment all I've see reported is that there are queries.
I'd like to see a break down like
NODATA IP6.INT and NODATA IP6.ARPA
NODATA IP6.INT and DATA IP6.ARPA
DATA IP6.INT and NODATA IP6.ARPA
DATA IP6.INT and DATA IP6.ARPA
where DATA is the there is a RRset there and NODATA is there
was no records of the requested type or the was name error returned.
servfail and refused should also be treated as no data.
The interesting one is DATA IP6.INT and NODATA IP6.ARPA. Is
a suitable metric < 50%, < 25%, < 10%, < 5%, < 1%, < .05%?
Can we get an anlysis of the last month's IP6.INT queries as
seen by the IP6.INT servers and generate the above statistics?
Mark
> > Deploying empty IP6.INT zones in recurive nameservers would
> > allow local IP6.INT to still succeed without creating load
> > on the global servers. However I would only recommend this
> > course if we can't convince Sun and glibc to fix there
> > resolvers.
>
> There is some validity to keeping authoritative copies of
> "special" zones ... but there is a real problem of when (not IF)
> there is a change required ... then there is the whole syncronization
> problem of having to upgrade (thousands, 10's of thousands, 100's
> of thousands?) of systems. Experiences with the whole belt/suspenders
> thing over the last 15 years has been an effort in futility.
>
> --bill
>
> >
> > 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
--
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
