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

From: Alain Durand <[email-masked]>
Date: Mon, 11 Nov 2002 10:49:42 -0800

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 <[email-masked]>.

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Nov 2002 13:34:50 -0800

[ v6ops removed from cc: ]

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

as far down the tree as it can go.  and note that the current
version
  <http://psg.com/~randy/draft-ymbk-6to4-arpa-delegation-00.html>
makes this a bit clearer.

> End customers will only deploy 6to4 because their ISP does not
> support IPv6 yet.

see the revised section

randy

---

From: Alain Durand <[email-masked]>
Date: Mon, 11 Nov 2002 14:41:37 -0800

Randy Bush wrote:

 > Under the described method, the holders of IPv4 address space can 
request the delegation
 > of a sub-zone in the 2.0.0.2.ip6.arpa DNS tree to the parties from 
which they obtained
 > that IPv4 address space, following the mapping of IPv4 delegations.
 > This sub-zone can then be populated by the entity deploying the 6to4 
infrastructure.

==> This last sentence is where the problem is.
The "entity deploying the 6to4 infrastructure" is not necessarily
the one who manages the delegation. See my previous example
of end-user customer.

- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Nov 2002 23:35:27 +0200 (EET)

> the one who manages the delegation. See my previous example

Totally agree.  Therefore depending on the full v4 delegation path would 
appear to be useless (and even worse -- if there are only 0.01% of sites 
where actually any records will be found).

More analysis is needed before going down this path..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords