Subject: FW: AAAA/A6

From: [email-masked]
Date: Thu, 22 Mar 2001 06:37:50 +0900

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

itojun

------- Forwarded Message

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

	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 [email-masked]
- --------------------------------------------------------------------

------- End of Forwarded Message

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

---

From: [email-masked]
Date: Thu, 22 Mar 2001 08:44:56 +0900

on AAAA/A6, there was a comment in wg meeting that basically says:
	- A6 helps very very large multihomed IPv6 network.
	- those who says "AAAA is just fine" has never operated large-enough
	  IPv6 network yet.

	for very very large multihomed IPv6 network, i guess A6 does not
	work either.
	if we cross the limit where zone files are over manageable size,
	none of A6 nor AAAA with manually managed zone file, will work.
	we need solution from different aspect something, including:
	- dynamic updates, to remove management burdens from client
	- name server with good backend database
		(in this case AAAA and A6 management costs are requal)
	- good perl script with AAAA (easy enough, deployable now)
	i don't think it wise to delegate management labor into protocol.

	the second bullet sounded a bit harsh to me, unless you have already
	opreated large-enough IPv6 network with A6.  i believe our network
	is already large enough, and i'm happy with AAAA.

itojun

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 22 Mar 2001 05:58:39 -0800

A6 wasn't originated by the DNS community, it was a response to the IPv6
community's desire to push their rapid/continuous renumbering requirement
into DNS rather than having to invent new support protocols in IPv6 itself.

Therefore if the IPv6 community withdraws its rapid/continuous renumbering
requirement then the DNS community will absolutely withdraw its A6 proposal.
I do not consider this likely, and moreover, while I'm not a direct
participant in the IPv6 community, I think that rapid/continuous renumbering
is the only thing that makes IPv6 worth deploying.

> 		(in this case AAAA and A6 management costs are requal)

For any given network this may or may not be the case.  Sounds like for the
IIJLab network it is the case.  But I know of hundreds of networks for whom
it is NOT the case (starting with most of PAIX's customers.)  Good backend
databases, or even...

> 	- good perl script with AAAA (easy enough, deployable now)

...good perl scripts, are not universally applicable or scalable, and will
not lead to transit-provider fluidity.  Some of the stickiness of a network
to its transit provider has to do with the cost of renumbering.  And at the
moment, multihoming is hellishly expensive since it requires portable address
space which most networks don't have the resources to qualify for.

> 	i believe our network is already large enough, and i'm happy with AAAA.

in contrast, i believe that IPv6 is not worth its deployment cost, not even
in a testbed, unless we deploy (or test) the rapid/continuous renumbering
features.  if you don't believe me, find a member of the GPRS community and
ask *them*.  or anyone in the mobile data community.  or anyone whose network
touches PAIX or Equinix or similar for the majority purpose of selecting their
transit providers based on price and quality and without regard to renumbering
cost.

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Mar 2001 09:41:57 -0600

> requirement then the DNS community will absolutely withdraw its A6

sorry, but i have a small problem with some choices of words, though not
necessarily deep semantics.

the a6 document was an ipngwg document.  hence the dns community can not
withdraw the proposal, it was not ours to withdraw.  we can work with the v6
community to find what is best, in our small and oh so fallable views, for
the internet. also, i don't think either you, i, or any other single person
should be speaking in the name of the dns community.

personally, i am as tempted by the large address space of v6 as i am by
renumbering.  i suspect the latter has feet of clay, and the former badly
needs a better routing architecture.  but this may be the wrong wg for this
part of the discussion.

randy, just another bozo on this bus

---

From: [email-masked]
Date: Fri, 23 Mar 2001 01:19:03 +0900

>is the only thing that makes IPv6 worth deploying.

	if this is the case, ipngwg would need to supply the requirement to
	renumbering (like frequency, network size, whether it covers multiple
	admin boundary or not, whatever).  i have never seen such document.

>features.

	(this is outside of the topic, i guess)  deployment cost is high
	partly because there are too fancy proposals thrown into it.  we,
	those who are trying hard to deploy IPv6 sooner, are trying to seek
	the ways to make it really work.  i believe this A6/AAAA debate, as
	well as our tests of IPv6 router renumbering protocol, are part of
	the effort.

itojun