FW: AAAA/A6

[[e-mail]]

	i'm not sure which wg is the better place.

itojun

------- Forwarded Message

Subject: Re: The case against A6 and DNAME
From: [e-mail]
Date: Thu, 22 Mar 2001 01:59:24 +0900
Message-ID: <[e-mail]>

	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.
- --------------------------------------------------------------------
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 [e-mail]
- --------------------------------------------------------------------

------- End of Forwarded Message



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.