Subject: notes from my conversation with keith moore concerning a6/dname

From: Paul Vixie <[email-masked]>
Date: Tue, 19 Mar 2002 21:01:41 -0800

these are not my views, but rather represent my understanding of keith's
position regarding A6/DNAME.

> given that we cannot recall or deprecate the clients who are now making
> AAAA queries, or the caching nameservers who are able to forward and/or
> cache AAAA queries, we therefore cannot legislate the existence of A6 RR's
> or the use of A6 queries at this late date.  IPv6 is considered to be
> "partly deployed" in this sense.
> 
> A6 could still be specified as an authority server issue, such that an
> authority server who heard a AAAA query but had only A6 data could do some
> kind of "AAAA synthesis".  DNSSEC complicates this since synthesized RR's
> probably will not have covering SIG's nor be present in the NXT bitmaps.
> 
> DNAME and bitstring labels would require changes to the deployed base of
> caching/forwarding name servers, and is likewise considered beyond reach
> at this "partly deployed" stage of IPv6.
>
> renumbering, either for A RR's or AAAA RR's, could be aided as much by
> a zone preprocessor running on the primary, as it would be by A6.

those are my words, and keith claims that he would use different words, but
he approved the above summary.  keith also reminded me that he's been out
of the IESG for a couple of years and his views are now entirely personal.

i note that to avoid the SIG problem on synthesized AAAA's, these AAAA's
would have to be sent as additional data, which places them outside
DNSSEC and therefore subject to replay attacks.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Robert Elz <[email-masked]>
Date: Wed, 20 Mar 2002 16:11:07 +0700

Date:        Tue, 19 Mar 2002 21:01:41 -0800
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | these are not my views, but rather represent my understanding of keith's
  | position regarding A6/DNAME.

Keith is usually not shy about sending his own e-mail ??

But in response to (the modified but approved version of) Keith's words...

  | > A6 could still be specified as an authority server issue, such that an
  | > authority server who heard a AAAA query but had only A6 data could do some
  | > kind of "AAAA synthesis".  DNSSEC complicates this since synthesized RR's
  | > probably will not have covering SIG's nor be present in the NXT bitmaps.

We discussed this option ages ago, and concluded it simply doesn't work.
On the other hand, doing the synthesis near the client works just fine
A client is likely going to use some simpler, probably configured,
security mechanism (TSIG perhaps) to communicate with its back end
resolver - so doesn't really need to know (in many cases) that the
actual signatures verify - it is often just going to trust that the
back end resolver has verified things, and its local security to know
that it is the trusted back end resolver who is sending the reply.

  | > DNAME and bitstring labels would require changes to the deployed base of
  | > caching/forwarding name servers, and is likewise considered beyond reach
  | > at this "partly deployed" stage of IPv6.

There is currently ~0 deployed IPv6 nameservers in any real use - it will
remain that way until there are IPv6 reachable root (and COM etc) servers.

We could easily make the transition to A6 happen at the same time servers
start sending queries using IPv6 transport (the number of those that exist
now - in use - is miniscule).

  | > renumbering, either for A RR's or AAAA RR's, could be aided as much by
  | > a zone preprocessor running on the primary, as it would be by A6.

No, that's simply wrong.   Aside from the previous discussion on this list
in the past few days, this requires the renumbered site to know it has been
renumbered.   While many of you simply can't conceive of a renumbering
where the affected site never knows it happened - I certainly can, and it
is something I would like to work toward making possible.   To do this
we need to make it possible for a site to manage their own DNS, without
ever having to know what their prefix is.   This is not too hard for
reverse lookups (the delegated zone is the same whatever its delegation point,
provided it occurs at the same depth in the tree and as long as it doesn't
try and include RR values that are inside the domain) but for the forward
zone, A6 is the only current answer.

Once again, no requirement that anyone actually do things this way - it is
just an option for sites that really don't want to care about details like
address prefixes (meaningless random strings of bits with no inherent
meaning - other than to the routing system, which is none of their business)

kre

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Mar 2002 08:58:09 -0800

> now - in use - is miniscule).

that's an interesting possibility, it would let us declare a flag day for
the recursive/forwarding servers.  my hunch is that it would complicate life
for the 6to4 people to say that pre-V6 recursive/forwarding servers could
not be used to serve V6 islands.  

it bugs me that there was and remains no architecture or plan for this stuff.

> is something I would like to work toward making possible.

as long as i'm still hard coding addresses for things like master name
servers for AXFR purposes and other similar uses, blind renumbering will
not be possible.  i agree that A6 leaves this door open but i do not
believe that the IETF leadership cares about quick or nimble renumbering
for IPv6, and absent such care, they are going to put A6/DNAME into the
field of weeds called "experimental."

the two saving graces, should this occur, are (1) we can rip most of the
"go slow" code out of BIND9, and (2) the whole TLA/subTLA "address as path"
addressing architecture seems to have collapsed, and nonaggregatable /35's
and maybe even /32's are getting handed out by the V6 RIR's, which means
the whole mess is back to BGP filtering for guidance, just like V4 is now.

raw/pure AAAA alongside the TLA/subTLA "address as path" architecture would
have been anticompetitive in the extreme, and would have restricted IPv6
to small networks or the edges of large (NAT'ed) networks.  but pure/raw
AAAA alongside "anything goes" V6 allocation is just a routing problem and
will probably drive the router economy but that's presumably acceptable
(or else the IETF leadership would care more about quick/nimble renumbering.)

---

From: Derek Atkins <[email-masked]>
Date: 20 Mar 2002 12:08:02 -0500

Robert Elz <[email-masked]> writes:

> reverse lookups (the delegated zone is the same whatever its
> delegation point, provided it occurs at the same depth in the tree
> and as long as it doesn't try and include RR values that are inside
> the domain) but for the forward zone, A6 is the only current answer.

I disagree.  The reverse tree needs to know where in the tree it is,
because it needs to know the full zone that is is serving.  A DNS
request is not made for a partial domain name (even in the reverse
tree).  Therefore, if a request is made for an ipv6 address, we
have the problem that the request is made for:

        1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.ip6.arpa.

Assume that you were delegated a /64, so your dns configuration is:

        @ IN SOA ()

        1.2.3.4.5.6.7.8 IN PTR my-host.my.domain.

The problem is that you need to know what your domain should be!  If you
get renumbered, then you need to know so you can change your dns
configuration from <old-domain>.ip6.arpa to <new-domain>.ip6.arpa.
This cannot be automated -- it requires user intervention.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Robert Elz <[email-masked]>
Date: Thu, 21 Mar 2002 17:49:47 +0700

Date:        Wed, 20 Mar 2002 08:58:09 -0800
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | as long as i'm still hard coding addresses for things like master name
  | servers for AXFR purposes and other similar uses, blind renumbering will
  | not be possible.

You mean it won't be possible for some.  Certainly, though when it gets
needed, ways around this can probably be found (I can generate a named.conf
from a script/program if I need to, and I can do that every 10 minutes if
that's required).

But even without that, small sites, serving only their own domain, don't
need any addresses in any named.conf (other than the reverse zone I mostly
botched yesterday) that will be subject to renumbering.

The primary server just has the name of the file containing the zone,
and the zone contains A6 records for addresses.   The secondary server
has the primary server's site local address configured into it.  resolv.conf
files either get built dynamically, or have site local addresses configured
in them.

Even with current technology, it certainly is possible.  But for the things 
where there are problems in current implementations (an off site secondary
would have the site's global address currently configured into it's config,
and so have to be updated) fixes, corrections, improvements, can be made
as the need arises - and need only be installed by those who need them.

That's the difference with A6 - it can't be installed just by those who
need it - it is an internet wide decision - what RR type is requested in
lookup messages, and what is the form of the responses.  It is something 
everyone needs to agree on, so can never really be adjusted once it has
been significantly deployed.

  | "go slow" code out of BIND9, and (2) the whole TLA/subTLA "address as path"
  | addressing architecture seems to have collapsed,

Yes, it seems that people have gone back to believing that aggregation
can be ignored.   Whether that's correct or not doesn't matter too much,
as we can always fix aggregation later if it turns out to be necessary,
by just renumbering lots of places (one at a time, as needed).   There are
plausible fixes for almost everything that might be a mistake that's
being made now.  Except for failure to adopt A6 - that decision would
put us into a corner that there's simply no way out of.

Even if the worst nightmares of bad A6 configs come true, we could fix
that - servers that simply refuse to process A6 other than in the cases
deemed safe (worst case, A6 0 only, or whole A6 chain in the packet, or
whatever else was deemed necessary at the time) could be deployed at
enough important sites around the net, that the operators of servers would
soon learn that they have to follow the new rules, or their names simply
don't work at lots of places (just as a whole bunch of people managed to
be convinced that _ wasn't legal in domain names by deploying software
that told them that...)

A6, with some guidelines on how people should actually configure it
most likely, is the only sane way to progress.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 21 Mar 2002 18:05:59 +0700

Date:        20 Mar 2002 12:08:02 -0500
    From:        Derek Atkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | The reverse tree needs to know where in the tree it is,

Ah yes, of course, that part of my brain must have been switched off
yesterday.

But ...

  | If you
  | get renumbered, then you need to know so you can change your dns
  | configuration from <old-domain>.ip6.arpa to <new-domain>.ip6.arpa.
  | This cannot be automated -- it requires user intervention.

No, not at all.   It currently requires user intervention.   This doesn't
have to be true for ever, this is server config info, the server has to
find out the info from somewhere, but it could easily be implemented
by having something like

	zone $REV_A6(my-name.my-isp.net).IP6.INT {
	}

in named.conf (or equiv for other servers).   That is, look up the A6 0
record that your ISP provides for you, take the address from that and
reverse it, to form the zone name, which is what tells you where you are
in the tree.   This is just a SMOP (including dealing with remembering the
TTL, refreshing the lookup as requried, doing the equivalent of "ndc reconfig"
whenever the A6 record changes, ... - so perhaps not so S, but still just a 
MOP).

I also thought that this was what DNAME was supposed to allow to work.

But even without any of that, the kind of simple organisation that I'm
concerned about can, if they want, have automatic renumbering, forward
and backward, today, with just A6.   The forward is easy, that was yesterday's
message.   The reverse just uses the rfc2317 technique.   That is, the ISP
actually runs the IP6.INT domain for the client (the natural one) but then
has CNAME records for the client's forward addresses, that refer to names
in some (constant) zone that the client manages for themselves.  When the
client adds new systems they need to contact the ISP to get new CNAME records
added (doing CNAMEs for a whole IPv6 /64 isn't the same as doing it for an
IPv4 /27...), but that's possible (and can be automated - even just using
DynDNS at the ISP today) and is done only when the client knows they're
making a change.  WHen the client gets renumbered, they really don't have
to know about it at all - the only queries sent to them (A6 or PTR, or
anything else) are all inside their known domain name.

In any case, the message is not to give up on A6 just because it seems like
that some of the problems it is useful to help with,look like they have 
difficulties in other areas.   All those other difficulties (that I can
think of now anyway) can be solved by local incremental upgrades.   A6
cannot be.  It needs to remain, not be farmed out to experimental (ie: dead).

kre

---

From: Alan Barrett <[email-masked]>
Date: Thu, 21 Mar 2002 15:11:35 +0200

On Wed, 20 Mar 2002, Derek Atkins wrote:
> The reverse tree needs to know where in the tree it is,
> because it needs to know the full zone that is is serving.

Yes, but DNAME would allow the zone that is bing served to have a
name that's very different from the name that the client originally
asked for.

> if a request is made for an ipv6 address, we have the problem that the
> request is made for:
> 
> Assume that you were delegated a /64 [...]

In a world with DNAME, your upstream could say something like

          9.10.11.12.13.14.15.16.ip6.arpa.	DNAME \
			reverse-tree.your-forward-domain.example.

> so your dns configuration is:
> 
>         @ IN SOA ()
> 
> The problem is that you need to know what your domain should be!

No problem in a world with DNAME.  The origin for that zone is
"reverse-tree.your-forward-domain.example."

> If you get renumbered, then you need to know so you can change your
> dns configuration from <old-domain>.ip6.arpa to <new-domain>.ip6.arpa.

It could be automated.  Not in today's world, but I would like to see a
future in which an upstream ISP could renumber their customers without
the customers having to do anything by hand.  Deprecating A6 and DNAME
will make that future much more difficult to reach.

I agree with KRE that if we deprecate A6 now, we will probably never
have an opportunity to put it back, but if we deprecate DNAME now, we
will have another chance later.

--apb (Alan Barrett)

---

From: Jim Reid <[email-masked]>
Date: Thu, 21 Mar 2002 07:14:50 -0800

>>>>> "Robert" == Robert Elz <[email-masked]> writes:

    Robert> A6, with some guidelines on how people should actually
    Robert> configure it most likely, is the only sane way to progress.

You may be right, up to a point. Tools for checking A6 configuration
would help too. However the thought of stub resolvers having to deal
with A6 or bit-string labels is too horrifying for words. I'm not sure
it's a Good Thing to require that complexity in the firmware of (say)
a domestic appliance or if it would even be feasible.

---

From: Robert Elz <[email-masked]>
Date: Thu, 21 Mar 2002 23:01:01 +0700

Date:        Thu, 21 Mar 2002 07:14:50 -0800
    From:        Jim Reid <[email-masked]>
    Message-ID:  <[email-masked]>

  | However the thought of stub resolvers having to deal
  | with A6 or bit-string labels is too horrifying for words.

We have been through this before.   Even if we wanted to make that happen
it is too late now anyway.   We simply have to support AAAA queries from
dumb resolvers (the things that send with RD on and have no way to cope
with getting an answer with RA off).

I must say that the appeal of bitstrings was never as clear to me, I'd
not be nearly as upset to see them silently vanish.   But perhaps that's
just because I'm ignorant of their potential, so no-one should consider
killing them just because I'm not sure what they're good for.

kre

---

From: Alan Barrett <[email-masked]>
Date: Thu, 21 Mar 2002 17:52:43 +0200

> a domestic appliance or if it would even be feasible.

That's why people have proposed putting AAAA synthesis in the recursive
resolvers, leaving the stub resolvers on less capable devices to make
AAAA queries as before, but allowing the zone administrators to publish
A6 records.

I thought that there was broad agreement to deprecate bitstring labels.

--apb (Alan Barrett)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Mar 2002 09:39:02 -0800

> most likely, is the only sane way to progress.

for the record, i still believe this.  however, i have stopped believing
that the current IETF leadership is convincable about any part of it, so i
am declaring defeat.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Mar 2002 12:17:36 -0000

[ post by non-subscriber ]

Robert Elz writes:

> A6 is the only current answer

A6 is an IPv6-specific record requiring support from every DNS cache on
the Internet. That wouldn't be a reasonable use of the word ``current''
even if A6 actually solved the stated problem---which it doesn't, never
mind all the other flaws.

Here's the _current_ answer, what actually happens in the real world.
DNS service for these dinky zones is provided by a much larger DNS
hosting service, often the ISP. The occasional updates are handled
through a local protocol.

The DNS host can, of course, allow indirection in the local protocol.
This doesn't require support from DNS software at other sites.

As for security: Someone who can change the leading bits of your IP
address might as well sign the whole thing. It's up to the security
protocol to allow sufficiently specific signing-authority delegations.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Robert Elz <[email-masked]>
Date: Sun, 24 Mar 2002 21:28:28 +0700

Date:        21 Mar 2002 12:17:36 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | [ post by non-subscriber ]

This time I am not going to go through the song & dance to get the
reply back to the author of this message...  If he doesn't want to see
replies, so be it.

  | A6 is an IPv6-specific record requiring support from every DNS cache on
  | the Internet.

While we're still using IPv4 for transport (and for all IPv4 only
DNS caches), no more than any other random RR that gets introduced,
that is, support means "cache the bits, and return them when asked".
There's no name compression for A6 records, however nice it would be
to have it.

  | Here's the _current_ answer, what actually happens in the real world.
  | DNS service for these dinky zones is provided by a much larger DNS
  | hosting service, often the ISP. The occasional updates are handled
  | through a local protocol.

Once again, you're providing a solution that happens to meet your
particular view of how the world should work.  No doubt many organisations
will do just that - but there's no reason to force them too.  If we can
make it so that sites don't have to go fiddling their DNS all the time,
more of them will run it for themselves.

  | As for security: Someone who can change the leading bits of your IP
  | address might as well sign the whole thing. It's up to the security
  | protocol to allow sufficiently specific signing-authority delegations.

No thanks.   The ISP has to be trusted to deal with the prefix - they
provide routing to it, if they want to screw their customers, they don't
need to go fiddling the DNS for the prefix for that.   But they know
nothing about the internals of the site, what addresses exist, and what
should exist.   I see no reason to create an industry for ISPs (we charge
$10 per name per year top put your names in our DNS...) that sites could be
coerced into using by an ISP that changed their address, forcing them to
chase the DNS updates.

kre