Subject: draft-durand-ngtrans-dns-issues-00.txt

From: Alain Durand <[email-masked]>
Date: Thu, 27 Jun 2002 15:58:47 -0700

I've written a short draft to try to summarize DNS related issues in 
IPv6 deployment.
I would like to get comments from the DNSop wg.

http://www.ietf.org/internet-drafts/draft-durand-ngtrans-dns-
issues-00.txt

Aside the issue of name space fragmentation, I would like to ask feedback
on the reverse zone issues.

	- Alain.

---

From: [email-masked]
Date: Fri, 28 Jun 2002 09:21:00 +0000

I don't understand why you say 6to4 use of 2.0.0.2.ip6.arpa has scaling 
problems.

There was a brief discussion in the corridor at NANOG-Toronto, and as
far as I can see, it should be easy to manage the reverse tree for existing
IPv4 users by forseeable RIR processes when the time comes.

You also don't say anything about ip6.int to ip6.arpa transition. Since
its now deprecated, it might be a good idea to address what happens during
the transition window (ie while vendors don't yet have resolvers doing 
an initial lookup in ip6.arpa, failing over to ip6.int before returning null)

-George

> 
> --Boundary_(ID_OKK4qxVJdHDQY97uJRrclw)
> Content-type: text/plain; charset=US-ASCII; format=flowed
> Content-transfer-encoding: 7BIT
> 
> --Boundary_(ID_OKK4qxVJdHDQY97uJRrclw)
> Content-type: text/enriched; charset=US-ASCII
> Content-transfer-encoding: 7BIT
> 
> <underline><color><param>0000,6666,0000</param>http://www.ietf.org/internet
-drafts/draft-durand-ngtrans-dns-issues-00.txt</color></underline>
> --Boundary_(ID_OKK4qxVJdHDQY97uJRrclw)--
--
George Michaelson       |  APNIC
Email: [email-masked]    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3100  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net

---

From: Alain Durand <[email-masked]>
Date: Thu, 27 Jun 2002 17:08:35 -0700

> IPv4 users by forseeable RIR processes when the time comes.

Can you please elaborate how this will work?
Will it require collaboration from the IPv4 upstream provider?
(i.e. will the delegation under the  2.0.0.2.ip6.arpa follow the same
path as under in-addr.arpa?
Another way to ask the question is where will 6to4 users have
to go to get reverse delegation? to their ISP or directly to the RIR?

How will it work when the IPv4 address is transient, i.e. DHCP allocated
for a short lease (typically less than a day)?

> an initial lookup in ip6.arpa, failing over to ip6.int before returning 

good point, I will add a section about this in the next revision.

	- Alain.

---

From: [email-masked]
Date: Fri, 28 Jun 2002 10:18:59 +0000

> 
> --Boundary_(ID_9YQaujQF4/xZHQntVm8C/g)

If its done top-down yes. if we worked out a way to take existing delegation
rights in 4land, and map them cleaning into 6land, it might be mitigated.

> path as under in-addr.arpa?

I think so, yes. 

> to go to get reverse delegation? to their ISP or directly to the RIR?

I think to their ISP.

> for a short lease (typically less than a day)?

Isn't this the same for any transient address DNS issue? I don't see a
specific 6 Issue here.

cheers

-George

---

From: Alain Durand <[email-masked]>
Date: Thu, 27 Jun 2002 17:28:40 -0700

> Isn't this the same for any transient address DNS issue? I don't see a

In v4-land, it is common to use automatically generated PTR for 
transient addresses.
in v6-land, with 6to4, a single IPv4 transient address will generate a 
/48 prefix, that is
2^80 addresses. I doubt it is a good idea to generate that many records!

Note: there is a similar issue with plain, non-6to4, transient prefixes.

My draft suggest to use wildcard PTR records. Does it makes sense?

	- Alain.

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Jun 2002 17:56:20 -0700

> My draft suggest to use wildcard PTR records. Does it makes sense?

no, as wildcards will likely not be securable

randy

---

From: Aidan Williams <[email-masked]>
Date: Fri, 28 Jun 2002 11:43:32 +1000

> Isn't this the same for any transient address DNS issue? I don't see a

The mechanisms are likely the same, but the way they get used will
probably be quite different.  Right now mechanisms for doing dynamic
updates of v4 PTR records really aren't required.

The difference does seem to be one of scale.  The widespread use of
6to4 could imply a considerable increase in the number of PTR records
for devices that now have global addresses and would now like a global
name->address->name to go with it.

Some options which occur to me are:

  - ignore reverse maps as not being particularly useful
    (I have some sympathy with this approach)

  - wildcard all 6to4 reverse entries as Alain is suggesting
    (to me this makes them "not particularly useful", apart from
     making various bits of software "work" that probably shouldn't
     have been relying on them in the first place)

  - make increased use of dynamic updates
    which has a whole can of worm with how you manage the trust
    relationships (ie keys) to authenticate the updates

IPv6 hosts typically construct their addresses using stateless
autoconfiguration (using their MAC address, or a more random
concoction to increase privacy) and so a DNS server in an ISP doesn't
have a simple way of predicting what that address might be in order to
create a sensible PTR record.  Hence you need some kind of dynamic
update...

If the ISP were to enable dynamic updates for reverse maps it would
need to secure them and that probably means authenticating updates
within a 2002:IPv4/48 block to the user/box/system that you gave an
IPv4 address to.  If the IPv4 address changes, lots of PTRs
potentially get updated (thats fine).

More importantly, can the trust relationships be made to scale?

In some specific system architectures (cable systems are one I'm
familiar with) bits of equipment (cable modems) are to some extent
trusted within the system.  If 6to4 and such existing architectures
can be made to fit comfortably together (I believe they can be with
HFC systems), existing trust relationships may be leveraged to
scalably authenticate the dynamic updating of IPv6 reverse maps.

However, I don't think there is a general answer ..

- aidan

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Jun 2002 15:32:26 +0700

Date:        Thu, 27 Jun 2002 17:28:40 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | In v4-land, it is common to use automatically generated PTR for 
  | transient addresses.
  | in v6-land, with 6to4, a single IPv4 transient address will generate a 
  | /48 prefix, that is
  | 2^80 addresses. I doubt it is a good idea to generate that many records!

You don't generate that many records, you generate the NS records that
make the delegation, and inside the zone, the zone origin.  For this kind
of setup, all the contents of the zone are constant (or if they're
dynamic, it is just another instance of the same thing - not a part of
the same one).

  | My draft suggest to use wildcard PTR records. Does it makes sense?

No.   While technically they're allowed, they make no sense to actually
use.   PTR records (for this purpose) are useful only if there's some way
to verify them.

Of course, an option is simply to decide that we've had enough of PTR
records, and deprecate the things.   No, that's not what I mean at all.
PTR records themselves are fine, what I mean is to deprecate IP6.ARPA
(and IN-ADDR.ARPA and IP6.INT and everything else like it).

And I don't mean "replace it with icmp name lookups" - while those also
have a purpose (like the PTR record in the DNS) that purpose doesn't need
to be to answer the generic question "what is the name associated with
this address?"

What I mean is to not answer that question.   There doesn't seem to be
any good reason other than curiosity.   That is, "because I want to know".

Let's just trash the concept, make name->address a one way function, and
be done with all of this (which includes how we manage to find names for
3041 addresses, just in case someone doesn't see that as a totally stupid
question).

kre

---

From: Shane Kerr <[email-masked]>
Date: Fri, 28 Jun 2002 11:58:41 +0200

On 2002-06-28 15:32:26 +0700, Robert Elz wrote:
>   | My draft suggest to use wildcard PTR records. Does it makes
>   | sense?
> 
> No.   While technically they're allowed, they make no sense to
> actually use.   PTR records (for this purpose) are useful only if
> there's some way to verify them.

It's also not clear to me how a wildcard PTR is different from (or
better than) a NS record.

<snip/>

> Let's just trash the concept, make name->address a one way function,
> and be done with all of this (which includes how we manage to find
> names for 3041 addresses, just in case someone doesn't see that as a
> totally stupid question).

This is an interesting idea.  To be honest, I gave up on address to
name mapping in IPv6 a while ago.  Doing it in a manner that is both
sufficiently distributed and secure seems like a very difficult
problem, and the benefits are not at all clear.

The problem as I see it is that IPv6 is so huge that it requires
automated processes to manage address space.  This means either
running a DNS server at each level or allowing dynamic updates.
Either one requires strong trust relationships be established - which
is going to be a lot of work.

I agree with the proposal.

-- 
Shane
Not speaking on behalf of any other entity.

---

From: Jim Reid <[email-masked]>
Date: Fri, 28 Jun 2002 03:55:40 -0700

>>>>> "Shane" == Shane Kerr <[email-masked]> writes:

    >> actually use.  PTR records (for this purpose) are useful only
    >> if there's some way to verify them.

    Shane> It's also not clear to me how a wildcard PTR is different
    Shane> from (or better than) a NS record.

Well as someone already said, signing wildcard RRs can't be done
easily (if at all) with DNSSEC. "Here's a SIG record for the name that
you looked up even though that name doesn't exist and only matches a
wildcard." At least the NS record(s) and the delegation of the zone
they serve can be signed.

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Jun 2002 21:03:58 +0700

Date:        Fri, 28 Jun 2002 03:55:40 -0700
    From:        Jim Reid <[email-masked]>
    Message-ID:  <[email-masked]>

  | Well as someone already said, signing wildcard RRs can't be done
  | easily (if at all) with DNSSEC.

Yes, but even if you're not requiring DNSSEC level of authentication,
just doing the "lookup the name and compare the A6 (maybe AAAA) records
with the address I started with" trick doesn't work with wildcard
PTR records.   It is almost possible to make it work with IPv4, by
simply giving the name in the wildcard PTR an RRSet that lists every
possible address.   I suspect that's not going to work real well with
IPv6...

kre