Subject: RE: The case against A6 and DNAME

From: [email-masked]
Date: Wed, 14 Mar 2001 09:21:51 -0600

this is premature because consensus is still split. but I do think it needs
to be on someones agenda to discuss to see what happens when we are all face
to face and in person.  I think this issue will also spill over to a
potential interim meeting.

/jim

> -----Original Message-----
> From: ext D. J. Bernstein [mailto:[email-masked]]
> Sent: Wednesday,March 14,2001 3:10 AM
> To: [email-masked]
> Subject: Re: The case against A6 and DNAME
> 
> 
> I propose retiring A6, DNAME, and ip6.arpa. The procedure for this is
> specified in RFC 2026, section 6.4: we ask the IESG to change 
> the status
> of the specifications to Historic. Clients and servers will go on
> happily using AAAA and ip6.int.
> 
> See http://cr.yp.to/djbdns/killa6.html if you missed the discussion of
> why A6 and DNAME are a bad idea.
> 
> ---Dan
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 14 Mar 2001 09:58:24 -0800

Hi,

Having been involved in the first implementation of these features, I am no 
fan of A6, DNAME, or bitstring labels.  However, I agree with Jim -- it is 
premature for 2026 to be moved to historic.  The functionality these 
features can provide would be useful and could be made to work reliably if 
suitably constrained, even if it doesn't quite fit into Bernstein's DNS 
implementation.  More operational experience is required before we have 
sufficient information to decide if the pain of A6, DNAME, and bitstring 
labels outweigh their benefits.

Rgds,
-drc

---

From: "JIM FLEMING" <[email-masked]>
Date: Wed, 14 Mar 2001 12:01:44 -0600

I believe that the free world and free markets will decide these matters.
Fortunately, parts of planet Earth are still a democracy with capitalism.

Jim Fleming
http://www.unir.com
Mars 128n 128e
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Mar 2001 14:06:57 -0000

David R. Conrad writes:
> would be useful and could be made to work reliably if suitably constrained

I don't believe you. Please say for the record exactly what constraints
you have in mind, so that we can see whether the constrained mechanism
is (1) reliable and (2) useful.

---Dan

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 15 Mar 2001 10:38:30 -0800

At 02:06 PM 3/15/2001 +0000, D. J. Bernstein wrote:
>I don't believe you.

I care?

>Please say for the record exactly what constraints

A6 can be seen as a generalization of AAAA.  It provides a means within the 
DNS to separate the routing prefix from the endpoint identifier thereby 
providing hooks to simplify renumbering.   I'd consider that a useful 
feature.  However in the trivial case, A6 can be made to work exactly like 
AAAA.  Constrain the depth of the A6 chain or constrain how the delegations 
are done and you can gain whatever level of reliability or usefulness you 
desire.

Are you saying A6 cannot be made as reliable as AAAA?

Rgds,
-drc

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 2001 01:16:57 -0000

David R. Conrad writes:
> Constrain the depth of the A6 chain

How? Exactly what constraint do you have in mind?

If you mean that the depth is at most 0---i.e., A6 is used just like
AAAA---then you're right that the reliability problems disappear. But A6
with this constraint is completely pointless. We should simply use AAAA.

If you mean that the depth is at most 1---i.e., A6 is used just like
AAAA, except that A6 is allowed to point to a prefix.* name if the
owner is _not_ a prefix.* name---then you're wrong about reliability.
The aol.com A6 suicide example follows this constraint.

You claimed that these features ``would be useful and could be made to
work reliably if suitably constrained.'' The features are useless with
the first constraint, and unreliable with the second constraint. If you
have some other constraint in mind, please say exactly what it is, so
that we can see whether the constrained feature is reliable and useful.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Fri, 16 Mar 2001 20:26:45 +1100

Date:        16 Mar 2001 01:16:57 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | If you
  | have some other constraint in mind, please say exactly what it is, so
  | that we can see whether the constrained feature is reliable and useful.

I suspect this is a pointless discussion, as neither A6 nor DNAME is
going to be made historic before there's ever been any realistic chance
to experiment with them and discover whether they are workable or not.

But if one were forced to add a constraint to A6, it may be that it
would only be legal to refer to names in the same zone (servers can
enforce that trivially when loading the zone, resolvers could ignore
any responses that didn't include the complete chain in one packet).

But until we see how well it works in practice, we won't know whether
there is even any point discussing any of this - this is the kind of
thing that should be being discussed when the doc is ready to be considered
to be advanced to DS status, and we're certainly not there yet.

kre

---

From: [email-masked] (Niels M�ller)
Date: 16 Mar 2001 14:23:25 +0100

> any responses that didn't include the complete chain in one packet).

Another reasonable constraint might be to require that each link in an
A6 chain add at least one bit to the prefix. If nothing else, it lets
clients and resolvers get away without special hacks to detect cycles.

/Niels

---

From: [email-masked]
Date: Thu, 22 Mar 2001 01:59:24 +0900

i guess i prefer AAAA much more than A6, because of the following
	logic.  could someone shed some light on the following items?
	i don't think i'm convinced yet.

	i agree that we need to test A6 in the real world situation.
	however, for a guy who is using IPv6 in a daily basis, i cannot wait
	till the test gets done... so i prefer AAAA gets deployed and kept.

	(note: the following is separate from topics raised by DJB)

itojun

real dns cloud:
- if we end up using "A6 0 <128bit>" everywhere, there's no benefit
  against AAAA.
- if we are to use fragmented A6s (128bit splitted into multiple A6s),
  i got couple of issues/worries.
  (1) query delays bothers me and we don't know how the additional
  delays interact with various timeout parameters.  also, are we sure that we
  have no problem with additional query/reply traffic imposed by fragmented A6?
  (2) some says that caches will avoid querying fragmented A6s again and again.
  however, most of the libc resolver implementations do not cache anything.
  (3) if some of the fragments are DNSSEC-signed and
  some are not, how should we treat that address?  RFC2874 section 6 briefly
  talks about it, not sure if complete answer is given.
  (4) it is much harder to code A6 fragment reassemble code, i expect
  to see a lot of security-issue bugs in the future (from our experiences).
  (5) i don't think there's too big benefits from renumbering.
  query-replace over AAAA zone file is easy enough.  you may need to sign
  zones on renumber, but given that the frequency of renumber is fairly low
  it shouldn't be an issue.
  to those who says that we can renumber frequently: from rrenum discussion
  it is clear that we cannot renumber more frequently than DNS TTL (or TTL*2).
  (6) there were some mentions about limiting # of fragments, but there's no
  such guarantee.

resolver issues:
suppose that we synthesize AAAA, or A6 0 <128bit>, at the DNS server
contacted by libc resolver, to avoid some of the complexities given above
(see BIND 9.2.0 snap behavior).  the approach has the following drawbacks:
- DNSSEC signs will get removed, making it impossible for libc resolvers
- when do we decide to synthesize A6 0 <128bit>?  client may be asking for
  raw A6 record (can be fragmented), client may be asking for synthesized A6 0
  <128bit> record.
- synthesized records have TTL=0.  is it really okay? (most of libc resolvers
  do not cache, so it should not be too bad)
we at least need a flag to determine when to synthesize, and when we do not.
(note that if we simply use AAAA in all places, we have no such problem at all)

deplyment issue:
we can't wait till BIND9 gets deployed everywhere.