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

From: Randy Bush <[email-masked]>
Date: Sat, 09 Nov 2002 20:02:00 -0800

in order to formally request delegation the 6to4 reverse zone, we
need a document such as joao and i drafted the other month but
never published.  see

  <http://psg.com/~randy/draft-ymbk-6to4-arpa-delegation-00.txt>

i would appreciate it if this document could be discussed in
v6ops.  thanks.

randy

---

From: Keith Moore <[email-masked]>
Date: Sun, 10 Nov 2002 08:51:53 -0500

Randy,

for what it's worth, I've updated the 6to4 and DNS document referenced
in this draft.  the current version is draft-moore-6to4-dns-03.txt .

Keith

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 11 Nov 2002 02:06:54 +0900

>in this draft.  the current version is draft-moore-6to4-dns-03.txt .

	will you guys get a slot in dnsop also?

itojun

---

From: Randy Bush <[email-masked]>
Date: Sun, 10 Nov 2002 09:16:45 -0800

> will you guys get a slot in dnsop also?

good question.  perhaps both belong there as opposed to v6ops.

dnsop, please see
   
   <ftp://ftp.ietf.org:/internet-drafts/draft-moore-6to4-dns-03.txt>
   <http://psg.com/~randy/draft-ymbk-6to4-arpa-delegation-00.txt>

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Nov 2002 14:28:15 +0100

fwiw, I think both of these documents are important to get done. The
delegation looks like a no-brainer, but constructive review from dnsop of 
draft-moore- would be very welcome.

   Brian

---

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

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 12 Nov 2002 04:07:12 +0900

>a fews days ago in DNSext is needed. I'll repost it here.

	i would prefer it if you impose no changes to getaddrinfo/getnameinfo
	with your proposal.  arrangements within server side would be better
	at this stage
	(we can't change deployed codebase any longer, there are huge number
	of Solaris 8 boxen out there).

itojun

---

From: Alain Durand <[email-masked]>
Date: Mon, 11 Nov 2002 13:32:12 -0800

>	of Solaris 8 boxen out there).
I would like not to change it too, but the alternative to create records
on the fly in the DNS servers is an invitation for DOS attack on DNSsec...

    - Alain.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 15 Nov 2002 13:16:30 -0500

> on the fly in the DNS servers is an invitation for DOS attack on DNSsec...

why?

the synthesized records are "like" glue records, aren't they?
so they shouldn't be signed anyway....?

           Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 20 Nov 2002 09:47:06 -0500

> so they shouldn't be signed anyway....?

I was corrected by Rob Austein.
If we want to be able to use DNSSEC at the 6to4 leaf nodes, the synthesized 
record set has to include a (signed) DS record.

And then it gets ugly.....

                     Harald

---

From: [email-masked]
Date: Mon, 25 Nov 2002 11:38:30 +0900

>on the fly in the DNS servers is an invitation for DOS attack on DNSsec...

	i don't understand why you would want to sign synthesized (generated-
	on-the-fly) record with DNSSEC.  if you don't sign it, the server
	should be able to respond proptly enough (= no worry for DoS).

itojun