Re: draft-ymbk-6to4-arpa-delegation-00.txt

[Alain Durand <[e-mail]>]

I have some comments about section 3.1 "6to4 NS records derived from 
IPv4 NS records"
when 6to4 is deployed by end users.

Who is going to get the delegation: the ISP or the end customers?

In IPv4 land, current practise is home customers do not get the delegation
in the reverse tree DNS of their /32, so I suspect it would be the same 
in IPv6 land.
[Note that, if the IPv4 address used for the 6to4 router is transient 
(DHCP allocated
with a short lease, say one day), getting the delegation maintained properly
would probably not be trivial anyway.]

End customers will only deploy 6to4 because their ISP does not support 
IPv6 yet.
Is it reasonable to expect the same ISP to manage the IPv6 reverse DNS zone?
Perhaps yes if this can be done automaticaly, probably not if it involves
manual intervention on the zones themselves.

More, in IPv4 land, it is rather easy to prepopulate the zone with all 
the PTR,
this is not possible in IPv6 land because of the size of the address space.

So it seems to me that, for this to work, something like what I suggested
a fews days ago in DNSext is needed. I'll repost it here.

    - Alain.

-------------------
Repost from DNSext:

As highlighted in the DNSop wg in
draft-durand-ngtrans-dns-issues-00.txt & 
draft-durand-ngtrans-dns-issues-01.txt
(this draft needs to be rename draft-ietf-dnsop-ipv6-dns-isssues-..)
a current IPv4 practise of end-user ISPs is to pre-populate the reverse 
tree DNS
with records like dsl-customer-374.pop-12.isp.net
Due to the size of Ipv6 adddres space, this practise is no more possible.

Several solutions have been proposed so far, but all of them have 
serious drawbacks:
- do not populate the reverse tree at all
- only populate for some hosts
- use wildcard DNS records
- dynamically generate DNS records

This is a new proposal that should not get in the way of DNSsec
but would require some changes in the stub resolver library routines,
getnameinfo and getaddrinfo. I would like to get feedback from the 
DNSext wg
before I present this to DNSop.

   - Alain.

ps: as this was first discussed with a few people last week at ARIN, it was
too late to publish an Internet Draft, so here is an outline of the 
proposal.

Note: this is a similar idea as described in RFC1101

DNS operational requirements:
For each /64 network, in the delegated /64 reverse zone:
a record:
0.0.0.0.0.0.0.0 IN PTR networkname
and in the direct zone
networkname IN AAAA xxxxxxxxxxx:0.0.0.0.0.0.0.0 SHOULD be in place.

Stub resolver library changes:

getaddrinfo():
- if a PTR exist for the IPv6 address, returns it.
- else
    - split the IPv6 address into a /64 $prefix and an Interface ID 
$interfaceID
      (note $interfaceID is a pure hex string)
    - append Interface ID all zeros to $prefix to form $networkAddr
    - lookup a PTR for $networkAddr into $networkName
    - if it exists, return the string $InterfaceID "+" $networkName
    - else return non existant

getnameinfo():
- only for AAAA lookups:
- lookup AAAA for $name
- if exist, retuns it
- if not exist AND $name matches the syntax $interfaceID "+" non empty 
valid DNS name then:
    - check $interfaceID is a 64 bit long hex string
    - look AAAA for the RHS to $netAddr
    - if non existant, return error
    - if lower 64 bits non empty, return error
    - append $interfaceID to $netAddr into $Addr
    - return $Addr
- else return non existant

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[e-mail]>.