Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jul 2004 17:53:52 +0000

> > Considering the DNAME-baed renaming mechanism documented at
> > <http://www.isc.org/pubs/tn/isc-tn-2002-1.txt>, what I wonder
> > is, why doesn't Bill Manning just put in a DNAME at IP6.INT
> > renaming the whole tree to point at IP6.ARPA?
> 
> 	in part, because there are entries in ip6.int that have no
> 	counterpart in ip6.arpa.... otherwise, a really good idea.

i think that you should spend your efforts trying to get the .INT
content mirrored in .ARPA somehow.  such as contacting the folks
who own the delegations you have in .INT and teaching them how to
re-register their content in .ARPA, such as by going through their
RIR's.

>       i have been trying to get the good folks at ICANN to effect
>	such changes as can be done, done.

icann's not involved at all.  once you get the content re-registered
in .ARPA, you can put a DNAME at the top of your .INT zone and the
rest is history.

> 	and i do not belive that older implementations will be
> 	out there forever.  but as long as the number of queries
> 	for ip6.int is noticable, i plan on serving the data.

what's the standard for "noticable"?  1qps?  10qps?  100qps?  what
are you seeing, in qps, today?

---

From: [email-masked]
Date: Wed, 28 Jul 2004 18:52:37 +0000

> re-register their content in .ARPA, such as by going through their

	not all entries in the .int tree are RIR related. the most
	obvious is 3ffe::/16. It does not help that the IETF has a
	BCP/PS RFC that prohibits any entry in ip6.arpa that is not
	an RIR managed block.

> in .ARPA, you can put a DNAME at the top of your .INT zone and the

	er, yes ICANN is involved. And I understand the process here.

> are you seeing, in qps, today?

	the standard is likely different for different people.
	we did have this same discussion - about 10 years ago
	when there was a proposal to shut down in-addr.arpa and
	move the v4 reverse anchor to ip4.int... :)

	as to qps, not so many, but that may be due to the fact that
	once sites get the RIR, 6bone, and other delegations cached,
	they don't come back too often.

--bill

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jul 2004 19:29:32 +0000

> 	obvious is 3ffe::/16.

3ffe::/16 goes "poof" on june 6 2006 if i recall correctly.  no worries.

>	It does not help that the IETF has a BCP/PS RFC that
>	prohibits any entry in ip6.arpa that is not an RIR
>	managed block.

that's a political issue that i think folks here could take all sides of.

> 	move the v4 reverse anchor to ip4.int... :)

i remember.  the problem was, the installed base was too large to consider
such a thing.  it was worth of study, and there was a study, and in the end
it was decided that changing it would be a bad idea.

> 	they don't come back too often.

then you could safely just do nothing, right?

---

From: Gert Doering <[email-masked]>
Date: Wed, 28 Jul 2004 22:35:08 +0200

Hi,

> 	BCP/PS RFC that prohibits any entry in ip6.arpa that is not

We have been through *that* argument before - it wasn't very good 2 years
ago (the 6bone *is* (was) an internet registry, and nothing says "only the 
4 established IPv4 regional registries are considered").

Besides that, e.f.f.3.ip6.arpa *has* been delegated, so what's this
argument supposed to be about?

; <<>> DiG 8.3 <<>> @dns1.icann.org e.f.f.3.ip6.arpa 
;; AUTHORITY SECTION:
e.f.f.3.ip6.arpa.       23h30m IN NS    ns3.nic.fr.
e.f.f.3.ip6.arpa.       23h30m IN NS    flag.ep.net.
e.f.f.3.ip6.arpa.       23h30m IN NS    imag.imag.fr.
e.f.f.3.ip6.arpa.       23h30m IN NS    sonata.hexago.com.

- looks perfectly fine to me.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  65398  (60210)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 29 Jul 2004 03:00:28 +0200

> - looks perfectly fine to me.

Actually, it's even in a better state than e.f.f.3.ip6.int:

Doc-2.2.2: doc e.f.f.3.ip6.arpa.
Summary:
   No errors or warnings issued for e.f.f.3.ip6.arpa.
Done testing e.f.f.3.ip6.arpa.  Thu Jul 29 02:56:22 CEST 2004

Doc-2.2.2: doc e.f.f.3.ip6.int.
Summary:
   ERRORS found for e.f.f.3.ip6.int. (count: 3)
   WARNINGS issued for e.f.f.3.ip6.int. (count: 1)
Done testing e.f.f.3.ip6.int.  Thu Jul 29 02:57:15 CEST 2004

Details:
========
Found 5 NS and 2 glue records for e.f.f.3.ip6.int. @flag.ep.net. (AUTH)
Found 4 NS and 2 glue records for e.f.f.3.ip6.int. @ns3.nic.fr. (AUTH)
Found 5 NS and 1 glue records for e.f.f.3.ip6.int. @y.ip6.int. (AUTH)
Found 5 NS and 2 glue records for e.f.f.3.ip6.int. @z.ip6.int. (AUTH)
ERROR: Found 2 diff sets of NS records
   === from servers authoritative for e.f.f.3.ip6.int.
NS list summary for e.f.f.3.ip6.int. from parent (ip6.int.) servers
  == flag.ep.net. imag.imag.fr. ns3.nic.fr.
  == sonata.hexago.com. y.ip6.int. z.ip6.int.
soa @flag.ep.net. for e.f.f.3.ip6.int. serial: 2002091315
soa @imag.imag.fr. for e.f.f.3.ip6.int. serial: 2002091315
soa @ns3.nic.fr. for e.f.f.3.ip6.int. serial: 2004072801
soa @sonata.hexago.com. for e.f.f.3.ip6.int. serial: 2004072801
soa @y.ip6.int. for e.f.f.3.ip6.int. serial: 2002091315
soa @z.ip6.int. for e.f.f.3.ip6.int. serial: 2002091315
WARN: Found 2 unique SOA serial #'s for e.f.f.3.ip6.int.
ERROR: Found 2 unique sets of NS records
   === from authoritative domain (e.f.f.3.ip6.int.) servers
ERROR: NS list from e.f.f.3.ip6.int. authoritative servers does not
  === match NS list from parent (ip6.int.) servers
NS list summary for e.f.f.3.ip6.int. from authoritative servers
  == flag.ep.net. imag.imag.fr. ns3.nic.fr.
  == sonata.hexago.com. y.ip6.int. z.ip6.int.

Best regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 29 Jul 2004 03:52:19 +0200

> WARN: Found 2 unique SOA serial #'s for e.f.f.3.ip6.int.

BTW... _this_ could be, because sonata.hexago.com. does
load their .arpa zone file as .int master zone:

$ dig @ns3.nic.fr. e.f.f.3.ip6.int. SOA +norec +short
sonata.hexago.com. support.eng.hexago.com. 2004072801 10800 900 259200 86400
$ dig @ns3.nic.fr. e.f.f.3.ip6.arpa. SOA +norec +short
sonata.hexago.com. support.eng.hexago.com. 2004072801 10800 900 259200 86400

==> ns3.nic.fr thinks sonata.hexago.com is master for .int...
flag.ep.net disagrees:

$ dig @flag.ep.net. e.f.f.3.ip6.int. SOA +norec +short
dot.ep.net. hostmaster.ep.net. 2002091315 900 900 4800 9600

So not only does sonata.hexago.com. load the .arpa zone also as .int
zone, but also ns3.nic.fr sync .int from sonata.hexago.com as master
instead of dot.ep.net.

Then again, dot.ep.net doesn't feel authoritative for e.f.f.3.ip6.int
at all:

$ dig @dot.ep.net. e.f.f.3.ip6.int. SOA +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17674
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 7

Given the fact that e.g. flag.ep.net still is authoritative, and given
the very short expiry timeout of the zone, I guess that dot.ep.net isn't
the real master anyway... as the zone would have timed out already if
it were (master being lame should result in slaves dropping authority
after expiry time passed, IIRC).

Regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 30 Jul 2004 11:49:18 +0200

> Actually, it's even in a better state than e.f.f.3.ip6.int:

And while we're at it, ip6.int itself is also broken:

ERROR: no SOA record for ip6.int. from munnari.oz.au.

$ host munnari.oz.au.
munnari.oz.au has address 128.250.22.2
munnari.oz.au has address 128.250.1.21
$ host -t aaaa munnari.oz.au.
munnari.oz.au has AAAA address 2001:388:c02:4000::1:21
$ dig @128.250.22.2 ip6.int. SOA +short +norec
$ dig @128.250.1.21 ip6.int. SOA +short +norec
$ dig @2001:388:c02:4000::1:21 ip6.int. SOA +short +norec

==> munnari.oz.au is completely lame for ip6.int.

NS list summary for ip6.int. from parent (int.) servers
  == flag.ep.net. imag.imag.fr. munnari.oz.au.
  == ns3.nic.fr. y.ip6.int. z.ip6.int.
NS list summary for ip6.int. from authoritative servers
  == flag.ep.net. ns3.nic.fr. y.ip6.int.
  == z.ip6.int.
ERROR: NS list from ip6.int. authoritative servers does not
  === match NS list from parent (int.) servers
ERROR: imag.imag.fr. claims to be authoritative, but does not appear in
NS list from authoritative servers

So the whole delegation thing is broken. The int. TLD servers delegate
ip6.int to imag.imag.fr which feels it self authoritative, but isn't
in the NS RRset of the ip6.int zone. And ip6.int is delegated to
munnari.oz.au which doesn't know about this (anymore).

Regards,
Daniel