[6bone] .int / .arpa

[Iljitsch van Beijnum]

On 16-feb-05, at 18:49, John Fraizer wrote:

>> I have working revDNS zone for my subnet (.ip6.arpa), but i still 
>> need ip6.int.

> #!/bin/bash
> sed 's/ip6.arpa/ip6.int/g' source.ip6.arpa > destination.ip6.int

Ok, so what happens now is that d.e.a.d.b.e.e.f.ip6.arpa and 
d.e.a.d.b.e.e.f.ip6.int are equivalent. However, this doesn't seem to 
be in line with the RFCs I'm reading.

In the beginning, there was RFC 1886, and we had the x.x.x.x.ip6.int 
reverse mapping and life was good.

Then at some point a whole bunch of RFCs was published with a whole new 
way of doing things, in the RFC 2[8|6]7x range. However, those RFCs DO 
NOT mandate the use of x.x.x.x.ip6.arpa, as far as I can tell from a 
quick scan.

According to those RFCs, looking up the reverse mapping should be done 
the way the host and nslookup commands on my Mac do:

[alumange:~] iljitsch% host 2001:200::8002:203:47ff:fea5:3085
Host \[x2001020000008002020347FFFEA53085/128].ip6.arpa not found: 
3(NXDOMAIN)
[alumange:~] iljitsch% nslookup -silent 
2001:200::8002:203:47ff:fea5:3085 sequoia
Server:         sequoia
Address:        2001:1af8:2:5::2#53

** server can't find \[x2001020000008002020347FFFEA53085/128].ip6.arpa: 
NXDOMAIN

Now RFC 3364 says the RFC 2874 is better, but the additional benefit 
over the RFC 1886 way is too small to warrant the trouble of the 
gruesome upgrade cycle that's needed.

So how did we end up in the current x.x.x.x.ip6.arpa situation? I 
haven't been able to find any document that mandates this, what gives?