[6bone] ip6.arpa ...

Robert Kiessling Robert.Kiessling@de.easynet.net
20 Feb 2003 20:55:52 +0000


Bill Manning <bmanning@ISI.EDU> writes:

> 	as I stated these are gripes.  the nut of the issue is that
> 	RIPE is proposing to edit/change the zone data between
> 	the 3ffe:: delegations as seen from ip6.int  and ip6.arpa
> 
> 	This is fatally flawed, as some folks will get one set of 
> 	answers while others will get distinctly different answers
> 	to the same questions, based on the age of the resolver that
> 	is in their endsystems.  

You cannot avoid that. Having the same delegations on
sub-e.f.f.3.ip6.arpa level does not guarantee that the eventual
answers are the same, since the nameserver to which it's finally
delgated can have different zones for ....ip6.arpa and ...ip6.int. And
quite often they would.

The only way to avoid that is to recursively transfer all the
subzones. I wouldn't think anyone seriously proposes this.

> 	the transition proposal I made has certain features as "checklist"
> 	items.  If you really don't care about IPv6 transport or zone
> 	transmission integrity, they can be excised.  And the simplist,	
> 	fastest way to get e.f.f.3.ip6.arpa. out the door is to have
> 	the IANA delegate that point to -exactly- the same server 
> 	suite that hosts the e.f.f.3.ip6.int delegation.  

Then why has't this been done long ago?

> 	the servers for ip6.int all have native IPv6 capability 
> 	as well as IPv4 capability and have since 2000.  

This might be, but as long as this capability is not announced it's of
no use for resolving.

> dig ip6.int. ns
imag.imag.fr.           3d23h53m15s IN A  129.88.30.1

> dig imag.imag.fr. aaaa
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

Let's have a look into our cache how the situation actually looks.

> dig ip6.int ns

;; ADDITIONAL SECTION:
z.ip6.int.              20h24m5s IN AAAA  3ffe:0:1::c620:242
ns3.nic.fr.             2d14h19s IN A   192.134.0.49
ns3.nic.fr.             3d21h13m44s IN AAAA  2001:660:3006:1::1:1
flag.ep.net.            16h24m6s IN A   198.32.4.13
flag.ep.net.            23h48m24s IN AAAA  3ffe:805::2d0:b7ff:fee8:c4d9
imag.imag.fr.           3d23h47m58s IN A  129.88.30.1
munnari.oz.au.          1d22h32m12s IN A  128.250.1.21
munnari.oz.au.          1h48m48s IN AAAA  2001:388:c02:4000::1:21
y.ip6.int.              20h24m5s IN AAAA  3ffe:50e::1

> dig 6.0.1.0.0.2.ip6.arpa. ns

;; ADDITIONAL SECTION:
ns.ripe.net.            18h56m42s IN AAAA  2001:610:240:0:193::193
ns.ripe.net.            1d21h45m57s IN A  193.0.0.193
ns.apnic.net.           12h31m21s IN A  203.37.255.97
munnari.oz.au.          1d22h31m20s IN A  128.250.1.21
munnari.oz.au.          1h47m56s IN AAAA  2001:388:c02:4000::1:21
auth03.ns.uu.net.       40m38s IN A     198.6.1.83
svc00.apnic.net.        1d23h57m7s IN A  202.12.28.131
sunic.sunet.se.         4h14m23s IN A   192.36.125.2
ns3.nic.fr.             2d13h59m27s IN A  192.134.0.49
ns3.nic.fr.             3d21h12m52s IN AAAA  2001:660:3006:1::1:1

So the difference here is 55% AAAA vs. 30% AAAA. Or in absolute terms
three vs. five AAAA answers. This does not look like a substantial
difference to me.

> 	Moving to the RIPE proposal looks like moving backward to
> 	me, in a number of respects.  I would really like to be
> 	persuaded that it really is an advancement.

Any delegation is an advancement.

Robert