Subject: (ngtrans) Re: Joint DNSEXT & NGTRANS agenda

From: [email-masked]
Date: Wed, 01 Aug 2001 23:03:11 +0900

>  | 4 Jun-ichiro itojun Hagino <[email-masked]>:
>  |   <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aaaa-a6-01.txt>
>This one contains a bunch of info on the current state of the world,
>followed by a large amount of FUD.   There's essentially nothing in it
>of value to the discussion.  I could analyse this doc paragraph by
>paragraph, and was once planning to do so - but I think that would be
>a waste of everyone's time.

	plesae comment paragraphs one by one, or drop the assertion that it
	is a FUD.  i wrote this because i believe there are serious problems
	with respect to the deployment as well as operation.  if you don't get
	the problem, please say so (and I will need to describe it better).
	if you saw any mistakes in the draft. please say so (and i will need
	to correct those points, or describe them better).
	it's not productive to assert someone's draft as a FUD!

itojun

---

From: Robert Elz <[email-masked]>
Date: Thu, 02 Aug 2001 01:24:46 +0700

Date:        Wed, 01 Aug 2001 23:03:11 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	plesae comment paragraphs one by one,

OK, I'll do that.   I'd actually suggest that most people not read much
of this message - if my original assertion is correct, you'll just be
wasting your time.  If it isn't, then it will be the responses to this
message that show that.

  |     or drop the assertion that it is a FUD.

I'm afraid you'll be seeing a bit more of that in this message.

  |     i wrote this because i believe there are serious problems
  | 	with respect to the deployment as well as operation.

I don't doubt that at all - no aspersions on your motives, or anyone
else's.   I just don't think that this doc adds much to the debate.
That isn't to say that A6 should be adopted because of this, but nor
is there anything here to suggest it shouldn't.

  | 	it's not productive to assert someone's draft as a FUD!

Unfortunately, sometimes it is.

I'll omit the boilerplate, abstract, and similar sections in this
analysis of course...

Section 1 is just a brief restatement of the basics of the RR types.
No problems there.   Though in 1.2, if you wanted to be truly fair,
you'd add M O P Q R as more nodes in the zone file (same as N with
different interface identifiers).   After all, your typical zone file
has more end nodes than subnets, and there are usually more of those
that providers, etc...  The example shown makes it look like A6 will
have of the order of 13 RRs for a single node's addresses, whereas AAAA
only requires 3.    Make that be 6 nodes (a very small network) and
you get 18 RR's for the A6 case, 18 RRs for the AAAA case.   And that's
with an overly elaborate A6 setup for most people (especially for a net
that small).

Section 2 is a statement about the state of the world as it is, no
problems there either.

Section 3 is where the comparisons are.

3.1 is how AAAA is familiar, we know it works, ... the beginnings of FUD.

3.2 	
	If we are to use fragmented A6s (128bit splitted into multiple A6s),
	we have a lot of issues/worries."
FUD. 

	If we are to resolve IPv6 addresses using fragmented A6 records, we
	need to query DNS multiple times to resolve a single DNS name into
	an IPv6 address.

should be "we might need to query".

	Since there has been no DNS record types that require multiple
	queries for resolution of the address itself, we have very little
	experience on such resource records.

Not true, all non-trivial DNS lookups require multiple queries.  In particular
doing a lookup for any alias (owner of a CNAME) requires the CNAME be
resolved, and then the A record be found (potentially via more CNAMEs).
We have lots of experience with such things.   The only part that differs
is the "of the address itself".  More FUD.

	There will be more delays in name resolution compared to queries to
	A/AAAA records.

Not true.  "There might be more delays" would be better.

	If we define a record with more number of fragments,
	there will be more query roundtrips.

Same.  There might be more round trips.   How many more (what the average
increase is, for a typical query) hasn't been measured.   ie: FUD.

	There are only few possibilities to query fragments in parallel.

True, but this is not new.

	In the above example, we can resolve
	A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others.

Take a complex example and treat it as a common case ... create FUD.

	At this moment, there is very little documents available, regarding to
	the relationship between DNS record TTL and the query delays.

This is true, but it is nothing new for A6.   The same applies to very
short TTLs in NS, CNAME, ...

eg: if I do an A lookup of www.example.com and get back

	www.example.com.  1 IN CNAME www.example.net.

and then it takes more than 1 second to figure out the A related to
www.example.net, am I allowed to still return that CNAME?  If not, then
all the rest of the resolution is useless, it doesn't apply.   A6 is just
this same problem.   It would be a good idea to codify Rob Austein's
response to this issue and settle it.   Raising it in the context of A6
in particular is just more FUD.

The rest of page 5 is just exploring this issue in more detail, it isn't
related to A6 specifically at all.

	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.

There's no difference here with A6 or any other DNS chain, which is only
partially secure.   Either you have en unbroken chain of sigs/keys back to
something that you trust, or the data is unsecured.  Nothing new for A6.   FUD.

	It is much harder to implement A6 fragment reassemble code, than to
	implement AAAA record resolver.  AAAA record resolver can be implemented
	as a straight extension of A record resolver.

More FUD.   More, this is irrelevant FUD.   It is more difficult to
implement a DNS resolver than a HOST.TXT lookup, but we still switched
from HOSTS.TXT to the DNS.   The resolver gets implemented just a small
number of times, how difficult each of those happens to be is pretty much
irrelevant in the grand scheme of things.

	o It is much harder to design timeout handling for the A6 reassembly.

FUD.

	o In the case of library resolver implementation, it is harder to deal
	  with exceptions (signals in UNIX case) for the large code fragment for
	  resolvers.

This basically says that writing resolvers isn't easy.    Nothing at all
related to A6 in this paragraph.  Just FUD.   There's nothing qualitatively
new in A6, as far as DNS lookups go - just perhaps more of it.   Nothing
specially new (in this area) is required to implement A6.

	o When A6 prefix length field is not multiple of 8, address suffix
	  portion needs to be shifted bitwise while A6 fragments are
	  reassembled. [...]

FUD.   "I can create coding bugs" ...   AAAA records are are 128 bits
long, but aren't aligned, in DNS packets, implementations might not
correctly align the data before using it, ....    Gibberish.

	In RFC2874, a suggestion is made to use limited number of fragments per
	an IPv6 address.  However, there is no protocol limitation defined.

This is true.   Perhaps we need to define a limit.   Or perhaps we don't.
We need some experience with what works and what doesn't.

	The lack makes it easier for malicious parties to impose DoS attacks
	using lots of A6 fragments (see the section on security consideration).

More FUD.   There are lots of ways to use the DNS to cause a remote node
to do more work than it would prefer to do.  Almost none of them have any
practical effect, A6 less than some others.  Nodes will only be doing A6
lookups when they have some reason to contact another node (like A).  Sure
you can arrange A6 to make it difficult or impossible for another node to
contact you, and to make it do a whole lot of extra work.  There are a zillion
other ways to make a node do a whole bunch of extra work when it tries to
contact you as well, both using the DNS, and via other means.

	With fragmented A6 records, in multi-prefix network configuration, it is
	not possible for us to limit the address on the DNS database to the
	specific set of records, like for load distribution purposes.  Consider
	the following example.  Even if we would like to advertise only
	2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible
	to do so.  It becomes mandatory for us to define the whole IPv6 address
	by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6
	(renumber friendliness) goes away.

This is simply not true.   All that is needed is more imaginative use of
the A6 records.   Eg;
	N.X.EXAMPLE. IN A6 40 ::11:1:1234:5678:9ABC:DEF0 A.NET.IP6.D.NET.

or, if there were other nodes on the same subnet that we wanted to do the
same thing to
	N.X.EXAMPLE. IN A6 64 ::1234:5678:9ABC:DEF0 A-D-ONLY
	A-D-ONLY     IN A6 40  0:0:0011:: A.NET.IP6.D.NET.

(and apologies if I got either of the details of those wrong, the details
aren't important here, so I didn't think about them much).

In either case, we still gain from not building in D.NET...'s prefix.
So the benefit of A6 (renumber friendliness) does not "go away".
Obviously though the more constraints we put on which addresses we
are willing to allow to be advertised, that is, the more we build in
addressing knowledge into our policy requirements, the more the DNS info
will be tied to out specific address blocks - that's unavoidable for this
kind of policy.  It is also comparatively rare.

The example at the top of page 7 is just more misguided configuration.

3.3	There are proposals to use non-fragmented A6 records in most of the
	places, like ``A6 0 <128bit>'', so that we would be able to switch to
	fragmented A6 records when we find a need for A6.

This hs been suggested as a first step, yes.   "In most of the places"
isn't what has been suggested though that I have seen.   Using A6 0 for
NS records (which isn't most of anything) has been suggested.  Using A6 0
as the first deployment step for A6 - before we have determined what
costs those potential extra round trips might be (ie: to avoid the FUD
relted to slower name resolution) has been suggested.

	From the packet format point of view, the approach has no benefit
	against AAAA.  Rather, there is a one-byte overhead to every
	(unfragmented) A6 record compared to a AAAA record.

It also has almost no cost.

	If the nameserver/resolver programs hardcode A6 processing to handle no
	fragments, there will be no future possibility for us to introduce
	fragmented A6 records.

Yes, but that isn't what is being suggested.

	When there is no need for A6 reassembly, there
	will be no code deployment, and even if the reassembly code gets
	deployed they will not be tested enough.

FUD.

We can always do testing.   Where lack of testing bites implementations
is with the stuff that no-one thought to test, either because it was
"obvious" that it would work, or because it was some wild case that no-one
ever thought would happen (or thought of at all).   A6 reassembly
cerainly is neither of those.   Testing it in the lab is trivial.
Getting the bugs out is almost as trivial.   How much it actually occurs
in the wild doesn't matter.

	The author believes that the
	``prepare for the future, use non-fragmented A6'' argument is not
	worthwhile.

I won't dispute that - but just be sure that the case in favour of it
is just to avoid the FUD that surrounds the extra queries that might be
needed - have people set up their zones with A6 0, and then they'll know
that they'll work just the same as AAAA would work, it is a safe option
which will cause no problems.

As the same time, braver souls can use more complex A6 setups.

	In the event of renumbering, non-fragmented A6 record has the same
	property as AAAA (the whole zone file has to be updated).

This is certainly true (just a re-statement of part of the A6 design).

3.4	At this moment, end hosts support AAAA records only.  Some people would
	like to see A6 deployment in DNS databases even with the lack of end
	hosts support.  To workaround the deployment issues of A6, the following
	approach is proposed in IETF50 dnsext working group slot.  It is called
	``AAAA synthesis'' [Austein, 2001] :

This is obviously a transiton method (or likely to be) - though having
stub resolvers that only ever do AAAA, much as we have stub resolvers with
no cache, and no way to do any kind of recursive lookups, with everything
in a back end resolver, is a possibility.

	o Deploy A6 DNS records worldwide.  The proposal was not specific about
	  whether we would deploy fragmented A6 records, or non-fragmented A6
	  records (``A6 0'').

It doesn't matter for this purpose.   That's back to how important avoiding
the FUD with the extra queries is seen to be.   There's no need for
everyone to adopt the same approach.

	o When a host queries AAAA record to a DNS server, the DNS server
	  queries A6 fragments, reassemble it, and respond with a AAAA record.

"DNS server" there should really be back end resolver.   It is for the
box near the stub resolver to do this, not the server for the zone.

	The approach needs to be diagnosed/specified in far more detail.

Perhaps.   It certainly wouldn't hurt, but I'm not sure it is needed either.
That is, this is really something of a local issue between the stub
resolver and its back end.  That could be standardised, but doesn't have
to be.

Just to show it can be done, I'll give some answers.   Not necessarily the
right answers all the time, but plausible ones I think.   That's to remove
the FUD that comes from giving a list of unanswered questions, which implies
that all this stuff must be difficult...

	o What is the DNS error code against AAAA querier, if the A6 reassembly
	  fails?

SERVFAIL, the same as when any DNS lookup fails.

	o What TTL should the synthesized AAAA record have?  [BIND 9.2.0snap
	  uses TTL=0]

It almost certainly doesn't matter, stub resolvers tend to have no caches
anyway (whatever the TTL is, it is ignored).   But anything between 0 and
the minimum TTL from the A6 fragments combined would work.  One of those
two extremes would be most likely.

	o Which nameserver should synthesize the AAAA record, in the DNS
	  recursize query chain?  Is the synthesis mandatory for every DNS
	  server implementation?

The first one queried - the same one that does the recursive query work
for the stub resolver.   And no, of course not, it is only needed if you
deply stub resolvers that need it (just the same as implementing resursive
lookups in a server).

	o What should we do if the A6 reassembly takes too much time?

Same as if chasing CNAME records takes too much time, or NS's don't
respond soon enough, or ...   Nothing even slightly new here.

	o What should we do about DNSSEC signatures?

Most likely verify them in the back end resolver, and then (most likely
using TSIG) indicate to the stub resolver that the data is OK.   If we
ever get stub resolvers that are doing their own signature validation,
then I think they can be doing their own A6 resolution as well - dnssec
is certainly lots more work than A6...

	o What if the resolver wants no synthesis?  Do we want to have a flag
	  bit in DNS packet, to enable/disable AAAA synthesis?

It just queries for A6 records instead of AAAA.   This whole scheme only
makes sense if A6 records are to be the ones selected to be used.  That is,
there are no AAAA records in the wild any more.  The only sense to ever
query for AAAA is if you are requesting AAAA synthesis.   (Of course, in
the short term, you might actually get an original AAAA record, but that's
just a transitional artifact).

	o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query
	  timeouts, and other timeout parameters?

This looks to be some (most) of the above points, simply restated more
briefly.

	The approach seems to be vulnerable against DoS attacks, because the
	nameserver reassembles A6 fragments on behalf of the AAAA querier.

FUD.   There is nothing different here from any case where a back end resolver
does all the work and then hands the final result of the query back to the
stub resolver.

3.5.	Issues in keeping both AAAA and A6

Did anyone actually suggest doing that?   It makes no sense at all.  If we
adopt A6, then anyone who prefers the AAAA style, simply uses A6 0, that
gives them all they would ever get from AAAA (at the cost of 1 byte per
A6 0 record returned).

	If we are to keep both AAAA and A6 records onto the worldwide DNS
	database, it would impose more query delays to the client resolvers.

It might indeed, if we were to do that nonsense thing, and do it in a
naïve way.  If for some strange reason we did decide that keeping both
A6 and AAAA made some kind of sense, then the obvious thing to do would
be to invent a "meta-A" query (ANYA) which would return both AAAA and
A6 records.  It might be worth doing that anyway, and have it return A
records as well - make it easier for dual stack implementations to
discover all v4 and v6 addresses in a single query (could even have it
return all the other address forms that we currently know of, for all
those nodes in the internet with X.25 and NSAP and such records defined...)

The rest of section 3.5 is just more FUD induced by not suggesting a
more sensible method of dealing with an environment that will never
exist (other than for a shortish transition period) anyway.

4	Some says that there will be more frequent renumbers in IPv6 network
	operation, and A6 is necessary to reduce the zone modification cost as
	well as zone signing costs on renumber operation.

That is an argument, yes.

	It is not clear if we really want to renumber that frequently.

How often we want to renumber is not really relevant.   We don't want to
renumber at all.   What matters is how often we need to.  We don't know.
We might not know for another 20 years.

	With
	IPv6, it should be easier for ISPs to assign addresses statically to the
	downstream customers, rather than dynamically like we do in IPv4 dialup
	connectivity today.

Probably true, as there are more IPv6 addresses (plenty) and so there should
be much less need to share addresses.

However, many ISPs seem to want to shuffle addresses not because of address
shortage (ie: they switch addresses from A to B even while the client is
connected, so the number of addresses assigned isn't altering), and is
more to discourage the client from running servers than from any other
cause (if the client can't advertise a stable address, then it is almost
impossible for them to run any kind of server).

But this kind of renumbering has never been what we're trying to deal with
(or not very much) - nodes that only get dynamic addresses when they dial
up are almost never in the DNS to start with - A6 affects only renumbering
the DNS, so those nodes/sites aren't the ones of interest.

So, this whole line of argument is achieving nothing at all.  The rest of
this paragraph adds nothing.

	It is questionable if it is possible to renumber IPv6 networks more
	frequently than with IPv4.

FUD.

In any case what counts here isn't what is possible right now, but what
we should be aiming at producing.   What would be the ideal outcome?

	Router renumbering protocol [Crawford, 2000]
	, IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998]
	can help us renumber the IPv6 network, however, network renumbering
	itself is not an easy task.

FUD.   But it even contradicts the previous paragraph, all of that stuff
from the first 2 lines makes IPv6 renumbering easier than IPv4, and if it
is easier it can (not necessarily will) be done more often.

	If you would like to maintain reachability
	from the outside world, a site administrator needs to carefully
	coordinate site renumber.

True.  So?

	The minimal interval between renumber is
	restricted by DNS record timeouts, as DNS records will be cached around
	the world

True, which is why working on the DNS wrt renumbering is relevant in the
first place.   That is, to enable frequent renumbering we need to keep the
DNS TTL low.   But a low TTL has negative effects on caching.   That's where
A6 has benefits - the low TTL can be on just the few A6 records at the
higher level (the upper bits of the addresses).  Lower bits change rarely,
and can have much longer TTLs.   Whether this is 1 day and 1 month, or
1 hour and 1 day, or 1 minute and 1 hour (or 1 minute and 1 month) doesn't
matter.

What the costs and benefits of this will be we don't know yet - no-one that
I know of has actually measured them.

Most of the rest of section 4 is just more on how hard renumbering can be.
That's not disputed.   It is also no excuse for giving up, claiming it is
too hard to ever be solved, and hence not worth doing anything that might
help.

	A6 was designed to help administators update zone files during network
	renumbering events.  Even with AAAA, zone file modification itself is
	easy; you can just query-replace the addresses in the zone files.  The
	difficulty of network renumber comes from elsewhere.

That's certainly true.   But if you're thinking of A6 as some kind of
weird macro processor for the zone file, then it is no wonder that you
don't think of it as being useful.   That is certainly not where its
benefit lies.

	With AAAA, we need to sign the whole zone again with DNSSEC keys, after
	renumbering the network.  With A6, we need to sign upper bits only with
	DNSSEC keys.  Therefore, A6 will impose less zone signing cost on the
	event of network renumbering.

Yes, this is one (comparatively minor really) A6 benefit.

The DNSSEC issue of greater import is that only those parts of an organisation
concerned with the renumbering need to go update their records, and re-sign
them.   Eg: if a university gets a new link, and adds a new prefix, then the
university prefix A6 record would be updated, and all of the departments would
get that new prefix applied to all of their addresses in the DNS, without
any of them having to re-generate anything at all.   That's where the benefits
really start to acrue, not in the saving of a few hours of CPU time (though
that's not completely irrelevant either - if it takes too long to sign a
zone file, sites won't do it, or won't do it in a secure manner).

	As seen above, it is questionable if we
	renumber network that often, so it is questionable if A6 brings us an
	overall benefit.

FUD.

	Note, however, even if we use A6 to facilitate more
	frequent renumbering and lower signing cost, all glue records has to be
	installed as non-fragmented A6 records (``A6 0''), and required to be
	signed again on renumbering events.

This is very likely true, though I haven't actually done the analysis to
prove it is actually necessary - but in any case, there are small handfuls
of such things (the University of Melbourne probably has about 20 glue A
records for the whole institution...)

5.	Security consideration

Sect 5 before 5.1 is a simple restatement of stuff already covered.
I won't go through that again.  Essentially all FUD.

5.1 explores one particular attack that could be mounted.   It isn't a
very effective attack, as all the attacker really achieves is preventing
the client from accessing the attacker's own systems, and doing a bunch of
extra packet sending/receiving while that is happening.   The client would
keep on doing other stuff while all this is happening, probably wihout even
noticing (just as it does while any other problematic DNS lookup is being
done - and if you don't know that those happen all the time, you should spend
some time watching what any large mail server spends most of its time
doing today - yet mail still gets through just fine to all the systems whose
DNS isn't totally hosed).

It is quite possible that a totally hopeless implementation could get itself
stuck attempting to resolve a name forever, but when we start to base
decisions on what trash implementations might do, we're really delving the
depths of poor decision making.

	Note, however, this problem could be considered as a problem in
	recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA
	synthesis makes the problem more apparent, and more complex to diagnose.

The first clause there is true, I'd like to see some evidence for the
second one, without that it is just more FUD.

	To remedy this problem, we have a couple of solutions:

	(1) Deprecate A6 and deploy AAAA worldwide.  If we do not have A6, the
	    problem goes away.

No it doesn't, only this particular way of causing it.

	(2) Even if we use A6, do not configure nameservers for AAAA synthesis.
	    Deployment issues with existing IPv6 hosts get much harder.

Something still has to build the 128 bit address out of the A6 fragments,
if we're using A6.   That can be called "AAAA synthesis" (the work is all
identical) regardless of whether a RR with the AAAA type is ever actually
produced.   Thus this would make no difference at all - there's no benefit
at all to be gained by prohibiting back end resolvers from doing AAAA
generation for their stub resolvers from this line of argument.

	(3) Impose a protocol limitation to the number of A6 fragments.

This might be a good thing to do.   But even if we don't, any rational
implementaton is going to do it anyway.

	(4) Do not query the expired records in A6 chain again.  In other words,
	    implement resolvers that ignore TTL on DNS records.  Not sure if it
	    is the right thing to do.

This is not "ignore" but "treat differently than you were thinking".
This is actually no different than what everyone does with the TTLs we
have no anyway - they're only ever used for deciding whether a record that
is in a cache is still valid.  No-one does an A lookup, sees that the TTL
returned is 1, thinks to himself "it was a second ago that I did that lookup,
so this A record is invalid now, I'd better go do it again".  Nothing like
that at all - the old gethostbyname() inteface doesn't even return the TTL
to the application, so it has no idea at all how long the data it just
fetched is valid.   What is done everywere now, and would be perfectly
reasonable (or at the very least, not at all worse) is to ignore the TTLs
from the records being used to build the answer (this includes NS records,
CNAME records, and any others, including A6, that we need to fetch to
eventually get the result we want) - excepting in the one case that we're
fetching a result from a cache from some earlier result, in which case if
the TTL has expired, then we have to go get it again.

This has some perhaps unusual effects when we have TTL's that are very
small, but that's OK.   After all, if you're worried about records with
TTL 1 expiring before the rest of the answer is obtained, how do you
justify dealing with records with TTL 0 at all?   Those would be nominally
expired while the packet that contains them is en route to the resolver
(no matter how close it is).   Thus, by this theory, the trivial
infinite loop DNS DoS attack would be

	www	0	IN	A	1.2.3.4

as soon as the resolver gets that, it sees it has expired, and so has to
go fetch it again...    This one bothers no-one, nor will the A6 cases.

6	Conclusion

Since there is nothing in the doc that actually provides any real information,
other than FUD, drawing conclusions from it isn't going to be easy.

	A6/AAAA discussion has been an obstacle for IPv6 deployment, as the
	deployment of IPv6 NS recodrs have been deferred because of the
	discussion. 

This one I can't dispute - the discussion might very well be delaying
deployment in some places.   We still need to get it right, this really
isn't a case where any answer will do, even the wrong one.   Tossing a
coin isn't a good solution here.   We need more experience, and at
least some data.

	The author do not see benefit in keeping both AAAA and A6 records

No, nor do I (except perhaps for stub-resolvers - ie: keep the RR type,
but deprecate its use in zone files).

	Given the unlikeliness of frequent network renumbering

There's no evidence for that.  Only for renumbering being difficult
to achieve.   That something is hard doesn't mean that we won't be
forced to do it.

	the author believes that the A6's benefit in lower zone signing
	cost is not significant.

I think it is significant, I'm not sure that it alone would be compelling.
But the stright CPU costs to sign zones are only one of the issues.

	From the above discussions, the author suggests to keep AAAA and
	deprecate A6 (move A6 document to historic state).

That's OK, that's just an opinion (as the note at the beginning of
the section makes clear).

	The author believes
	that A6 can cause a lot of problem than the benefits it may have.

That this is believed is quite likely correct.  But before we take any
notice, we really need some kind of evidence.

	A6 will make IPv6 DNS operation more complicated and vulnerable
	to attacks.

This is FUD.

	AAAA is proven to work right in our IPv6 network operation since 1996.
	AAAA has been working just fine in existing IPv6 networks, and the
	author believes that it will in the coming days.

And this is the warm fuzzy alternative.

Note: I am not claiming that anything in this analysis is an argument for
preferring A6 over AAAA, all this message sets out to achieve is to show
that this particular draft contains no useful arguments the other way.

We still need more data to provide some of the answers.   However urgent
it may seem to get this issue resolved, it is more important that we get it
right.

For something to do in the immediate future, invent the ANYA meta-query
record, have it return A AAAA and A6 records, get back end resolvers doing
that, and creating AAAA records for stub resolvers that do AAAA requests.
That way, either AAAA or A6 records can be deployed, which allows sites
to start sticking in A6, while not breaking those still doing AAAA lookups,
and without requiring everyone to do lookups of both (and throwing in
free IPv4 answers to the local cache as a side benefit).

Apologies for the length of this message, I hope not too many people have
reached this far in processing it (unless you skipped all the middle bit).
It really would have been better to not have needed to send it at all.

kre

---

From: [email-masked]
Date: Thu, 02 Aug 2001 15:55:29 +0900

>wasting your time.  If it isn't, then it will be the responses to this

	Now I can respond to your comments, I'm very happy.  First of all
	I would like to thank for all the comments for all the paragraphs
	(just for clarification - even if people don't agree with each other's
	opinion, it is Japanese custom to thank for the effort itself in
	the first place.  "thank you" does not mean that I agree with you).
	Please note that, in i-d, there could be issues with my English skills
	(like I'm asserting something I did not mean to assert, or I write
	"must" where I should have used "may").

	In short, I cannot believe how can you assert these problems as
	just "FUD".  This way there will be no progress.
	In your comment it seems that you are using the word "FUD" for
	"unanswered questions".  I don't understand your choice of word, and
	I really really object.
	Also, you are asking for evidence multiple times, for something noone
	can possibly prove.  This way of discussion is unfair, and I'd like
	to ask you to try to prove them by yourself while I think about
	them too.
	You also wrote some text that can be considered a FUD under your rule,
	which leds me to believe that you don't understand the issue and
	your objective is jut to object.

	I have tweaked the quotation marks (">") so that it gets more
	clearer which part is from the draft and which part is your comment.

itojun

---
>with an overly elaborate A6 setup for most people (especially for a net

I don't feel the need to put multiple addresses onto the example here,
since in the following sections we don't use them much.

>3.1 is how AAAA is familiar, we know it works, ... the beginnings of FUD.=
>>3.2

You cannot assert like this.  I have presented worries and issues
in the following texts, and the line summarizes these.  If you can
provide a better wording, I'd love to see that.

>should be "we might need to query".

do you include "A6 0" case into "fragmented A6 records"?  if so,
I can understand your wording change.  Otherwise, I don't get it.

>Not true, all non-trivial DNS lookups require multiple queries.  In parti=
>cular

How can you ignore part of my text ("of the address itself") and assert
the lines as "not true"?  This is totally unfair.  A6 is the only
resource record type that composes a single address itself from
multiple query results.  It is true.

>increase is, for a typical query) hasn't been measured.   ie: FUD.

Again, I did not include "A6 0" into "fragmented A6 records" case.

>Take a complex example and treat it as a common case ... create FUD.

This problem is not new but I believe it worth mentioning it.
If I do not mention it, readers would mistakenly think that it is
possible to parallelize the queries for A6 fragments.
Do you have problem with it?  If I cannot things that are not new
how can I write up an analysis document.

>related to A6 specifically at all.

With A6 the problem is more apparent as it is the only resource record
type which composes a single address out of multiple query results.
For example, you can get a completely different IPv6 address out of
multiple queries, if you get part of A6 chains swapped with other item.
Assuming that this one is correct:
	A6 64 ::t:u:v:w
	A6 48 ::s:0:0:0:0
	A6 0 p:q:r::
now if you get "A6 48 ::x:0:0:0:0", you will have a whole lot of fun.

The problem had not been obvious with other resource record types.
For other record types, we would get a completely correct answer,
or completely hosed answer.  With A6 we would get a partially
correct answer (incorrect bits within a part of 128bit address).

>something that you trust, or the data is unsecured.  Nothing new for A6. 

No, this is not a FUD.  You are mixing up two different issues.
Because A6 is the only resource record type which composes a single
address out of multiple query results:
- for other record types, the result is binary - completely believable
  or not.
- for A6, the result is not binary - part of bits can be believable,
  part of bits can be not believable.

>irrelevant in the grand scheme of things.

This is from our implementation experiences.  There are very few
people out there (I believe) who have actually implemented A6
reassembly/decoding code, so I believe it worth mentioning.  Try it
by yourself and see how many mistakes you will make due to the
bitwise manipulations.

>>    o It is much harder to design timeout handling for the A6 reassembly.

No.  See the above.

>related to A6 in this paragraph.  Just FUD.   There's nothing qualitative=
>ly

No.  Try to implement it into libc resolver (like BIND8) and
experience the pain we had.

>correctly align the data before using it, ....    Gibberish.

Bitwise operations are so much more painful than 8-bit boundary
operations.

>We need some experience with what works and what doesn't.

But how can you enforce that?  Resolver side can protect themselves
by using the upper-limit, however, it is not possible to avoid
longer-than-limit A6 chains be placed onto the DNS zone files.
A6 fragments are likely to be maintained by different administrative
domains.  It is not likely that a single admin to control over the
whole A6 chain (otherwise, there's no benefit of A6 chain).
If you have some proposal for the enforcement please let me know.

>contact you as well, both using the DNS, and via other means.

I agree this is not just a problem of A6, however, A6 makes the problem
much more easier to exploit.

>or, if there were other nodes on the same subnet that we wanted to do the=
>same thing to

If you define upper bits (than the part that have assigned to you,
like less than /48) you become less ready to renumber events.
Therefore, the former one in your example will jeopardize the
renumbering benefits of A6.  The latter one is better, however, I don't
think it manageable (can you prove it is manageable for random dumb
admins like me?).

>relted to slower name resolution) has been suggested.

My text describes what I got from the past IETF presentations and
slides.  Maybe you right, maybe I'm right.

>in the wild doesn't matter.

If we take "A6 0" route, it is highly likely that vendors do not
bother to implement A6 chain chasing, or with a buggy reassembly
support.  These systems will be deployed into the real world,
and we will never be able to enable fragmented A6 usage.  Therefore,
I consider "A6 0" approach be a complete waste of 1 byte per an
IPv6 record (you can never transition to fragmented A6 situation
so there's no benefit against AAAA).  This is not a FUD.  If there's no
operational needs, people won't bother to implement them.

>in a back end resolver, is a possibility.

Now, can you predict how many people will have cache in stub resolvers
in year 2005?  In this year, as BIND4/8 resolvers and other non-caching
resolver are around, cache deployment in the stub resolver (say, 
for UNIX and Windows systems) is almost equal to zero.  There could be
one-entry caching with very short lifetime implemented in some of them,
or bad caching mechanisms in applications without TTL handling, that's
all.  With deployment of PDAs and smaller devices, it is unlikely to
see the change of ratio between caching stub resolvers and non-chacing
ones.  How long did you wait for this?  I'm equally worried about A6
fragment reassembly code deployment.

>everyone to adopt the same approach.

I mentioned "A6 0" and "A6 non-zero" this just for clarity.  How can
you assert it as a FUD?  It is not a FUD, you just did not understand
(or I did not describe it well).

>box near the stub resolver to do this, not the server for the zone.

Maybe correct.  However, when back end resolvers do not implement AAAA
synthesis, the AAAA queries will get propagated into servers for the zones.

>resolver and its back end.  That could be standardised, but doesn't have

My worry is that, the approach will hurt us if we deploy it without analyzing
it in detail before we do so.

>that all this stuff must be difficult...

So in your world unanswered questions are called "FUD"?
Did we have consensus for any of the following questions and answers?
These questions are left open as (1) it is an analysis draft (2) we
don't have consensus for ANY of them.  And then you call them FUD?
Nonsense.  Do we all need to obey your answers as you are the prophet of DNS?

>SERVFAIL, the same as when any DNS lookup fails.

Maybe, but I'm not sure.  I need to hear voice from others.

>two extremes would be most likely.

Now you are contradicting with yourself.  In the above you have mentioned
that there would be stub resolvers with caching, and now you are saying
that there will be no stub resolvers with caching.  Which one do you mean?

I agree that it has to be between 0 and min(TTL of A6 fragments), but
for the choice of the value, there's no consensus.

>deply stub resolvers that need it (just the same as implementing resursive

There's no mention in Rob's presentation nor Rob's draft.  AAAA queries
can get propagated into non-first nameservers at ease, when the first
one does not have AAAA synthesis.  Given that there are whole lot of DNS
servers (1) with AAAA support (2) no A6 support and (3) no AAAA synthesis,
it is highly likely that AAAA queries will be propagaged.  You cannot blame
people for propagating them (or you will blame everyone running BIND < 9.2).

>respond soon enough, or ...   Nothing even slightly new here.

Okay, that is one possiblity.

>is certainly lots more work than A6...

The problem here is, again, with A6 there can be certified bits
and uncertified bits within a single 128bit IPv6 address, and it
is difficult for us to decide whether the synthesized AAAA record is
really trustable or not.  The above is just your proposal, not the consensus.

>just a transitional artifact).

This part you don't have a concrete answer so I'll wait for others to
add more opinions.

>This looks to be some (most) of the above points, simply restated more

Without an answer/consensus we cannot implement AAAA synthesis right.

>does all the work and then hands the final result of the query back to the

This is not a FUD.  A6 makes the problem more apparent, and is slightly
different from other resource record types.

>gives them all they would ever get from AAAA (at the cost of 1 byte per
(snip)
>exist (other than for a shortish transition period) anyway.

Yes there is such an approach proposed.  Rob Austin's transitional approach
(endnode resolvers use AAAA and DNS servers use A6) is one of them.
You just did not understand the problem and asserting it as a FUD.  Not fair.

>We might not know for another 20 years.

Thanks for wording pickiness, but I don't think the change is necessary.

>Probably true, as there are more IPv6 addresses (plenty) and so there sho=
>uld
(snip)
>(or not very much) - nodes that only get dynamic addresses when they dialup
are almost never in the DNS to start with - A6 affects only renumbering
>this paragraph adds nothing.

So you are objecting to write down something obvious to you?  Then what's
the point in compiling list of "host requirement" which has batch of duplicated
text from other RFCs?  I don't see your point.  Nonsense.

>we should be aiming at producing.   What would be the ideal outcome?

I don't agree that it is something we should be aiming.

>is easier it can (not necessarily will) be done more often.

Not a FUD.  The above statement is totally correct, and you are
asserting it a FUD.

>>    coordinate site renumber.

So again you are objecting to document something obvious to you.  Rediculous.

>1 hour and 1 day, or 1 minute and 1 hour (or 1 minute and 1 month) doesn't

I'm questioning if it is necessary to renumber that frequently, and introduce
very high complexity and overhead for normal case ("optimized for write").
Could you prove that we need higher frequency of renumber?

>don't think of it as being useful.   That is certainly not where its

Then what is A6 really?  Describe me in 10 words.  For me, after doing the
analysis, it is "overly complicated alternative of AAAA with less benefit".

>zone file, sites won't do it, or won't do it in a secure manner).

Yes it is a benefit of A6, however, from the experiment result from Bill
Sommerfeld and othres, I believe it is not big enough to amend the complexity
of A6.

>>    renumber network that often, so it is questionable if A6 brings us an

No.  Prove that we need to renumber so often that we can amend the complexity
of A6.

>records for the whole institution...)

Prove it and drop me a note when you're done.

>I won't go through that again.  Essentially all FUD.

Because previous sections are not FUD, 5.1 is not a FUD too.

>second one, without that it is just more FUD.

I described them in the draft and you did not get it, and you assert it as
a FUD.  How nice.

>No it doesn't, only this particular way of causing it.

A6 makes the problem more apparent, so if we don't have A6, we have the
same amount of problems as today.  What are you trying to mean?

>generation for their stub resolvers from this line of argument.

You must give analysis to "A6 0 synthesis", otherwise your word is considered
a FUD under your rule.

>implementaton is going to do it anyway.

Okay.

>>	    is the right thing to do.
(snip)
>go fetch it again...    This one bothers no-one, nor will the A6 cases.

(4) maybe a leftover from the previous revision of the draft.  Sorry about it.

>other than FUD, drawing conclusions from it isn't going to be easy.

I presented real information and you just did not understand.
Also, it is a FUD to say "there is nothing in the doc" while you are agreeing
part of the document (see some of the comments *made by yourself*).

>>	discussion. =

Do you have an expected date to get more experiences and data?

>but deprecate its use in zone files).

So we should drop Rob's "AAAA synthesis" from the candidates.

>to achieve.   That something is hard doesn't mean that we won't be

I have already discussed, in the earlier part of the draft,
that the frequency of renumbering is not likely to be high.
I felt that the discussion should have been enough to lead to the
conclusion, so I did that.

Now, if you are asked to prove it, how can you prove this?
The way of discussion is not correct - you are asking for an evidence
for something noone can really prove, and because of that you are
asserting that the draft is a FUD.  Total nonsense.

>I think it is significant, I'm not sure that it alone would be compelling,

Now its my turn.  Can you prove that the signing cost difference is
significant?  For what kind of zone file structure?  For what kind of
situation?  Can you cover all the cases we would possibly encounter?

>the section makes clear).

Yes.

>notice, we really need some kind of evidence.

Agree in general, but I think I saw enough evidence from our
experimental operations as well as analysis (like this draft).
And you did not present any evidence either.

>And this is the warm fuzzy alternative.

No it is not FUD.  You cannot assert like this.  If you say "I did not
understnd this" or "I think this part is not correct", I can accept
those.  Asserting someone's draft a FUD is not fair and unproductive.

>free IPv4 answers to the local cache as a side benefit).

No new inventions, please please.  It can only hurt the deployment more.

>reached this far in processing it (unless you skipped all the middle bit),

Well, now you need to go through my comments again.  A bad day for you.

---

From: Robert Elz <[email-masked]>
Date: Thu, 02 Aug 2001 17:25:40 +0700

Date:        Thu, 02 Aug 2001 15:55:29 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	Now I can respond to your comments, I'm very happy.  First of all
  | 	I would like to thank for all the comments for all the paragraphs
  | 	(just for clarification - even if people don't agree with each other's
  | 	opinion, it is Japanese custom to thank for the effort itself in
  | 	the first place.  "thank you" does not mean that I agree with you).

OK, and thank you for the response.

  | 	Please note that, in i-d, there could be issues with my English skills
  | 	(like I'm asserting something I did not mean to assert, or I write
  | 	"must" where I should have used "may").

I think I understood it all OK, and I am pretty sure that none of my
comments related to the wording (alone).

  | 	In short, I cannot believe how can you assert these problems as
  | 	just "FUD".  This way there will be no progress.

Not from that doc (nor from my response), that's true.  That's why I
really didn't want to go through all of this line by line - there's almost
nothing of value to be gained from it.

  | 	In your comment it seems that you are using the word "FUD" for
  | 	"unanswered questions".  I don't understand your choice of word, and
  | 	I really really object.

Oh.   "FUD" is "Fear Uncertainty and Doubt".   Unanswered questions are
uncertainty - one of the principal attributes of FUD.   That is, "here
are all these things we don't know (uncertainty), all kinds of things
might go wrong (fear), we aren't sure this is right (doubt)".   That's
exactly what FUD is.   I should have made that clear before, sorry.

That is, FUD is an argument which goes along the lines of "we don't really
understand this, so let's not do it".

  | 	Also, you are asking for evidence multiple times, for something noone
  | 	can possibly prove.

I don't think that's so.   I think that evidence can be collected.

  |  This way of discussion is unfair, and I'd like
  | 	to ask you to try to prove them by yourself while I think about
  | 	them too.

Yes, that is what I want to do.   As I said, my response doesn't add anything
to the debate about which of A6 and AAAA is best to use - all it was intended
to do was to point out that your draft doesn't either.   That's why I really
didn't want to waste everyone's time with a lengthy message.

  | 	You also wrote some text that can be considered a FUD under your rule,

That might be true too.

  | I don't feel the need to put multiple addresses onto the example here,
  | since in the following sections we don't use them much.

Yes, I understand ... but also since it isn't used much, you could also
have given a much simpler example - more along the lines of what a net
with just a few nodes would actually use.   Not that this matters much.

  | >>    If we are to resolve IPv6 addresses using fragmented A6 records, we
  | >>    need to query DNS multiple times to resolve a single DNS name into
  | >>    an IPv6 address.
  | >should be "we might need to query".
  | 
  | do you include "A6 0" case into "fragmented A6 records"?  if so,
  | I can understand your wording change.  Otherwise, I don't get it.

No, I mean a response like

	A.MY.EXAMPLE.	IN	A6 64 <i-d> B.MY.EXAMPLE.
	B.MY.EXAMPLE.	IN	A6 48 <subnet> C.MY.EXAMPLE.
	C.MY.EXAMPLE.	IN	A6 0 <prefix> .

That is, we still have fragmented A6 records, but they're all from the
same zone, and hence all can be included in the same response packet.
No extra queries, no extra delay, and a packet that might be bigger and
might be smaller, depending upon just what data is being included (or
if you like, how many RRs actually exist in the RRsets for each of the
3 names above).

This is the kind of usage I'd actually expect A6 to see - rather than
having the domain names sprayed around all over the place, which is
theoretically possible, but not really very likely in practice.

  | How can you ignore part of my text ("of the address itself") and assert
  | the lines as "not true"?  This is totally unfair.  A6 is the only
  | resource record type that composes a single address itself from
  | multiple query results.  It is true.

Yes, but it is irrelevant - it is just provoking fear.  The technique
of chasing DNS chains to get answers is as old as the DNS itself.

  | Again, I did not include "A6 0" into "fragmented A6 records" case.

Nor did I.

  | This problem is not new but I believe it worth mentioning it.
  | If I do not mention it, readers would mistakenly think that it is
  | possible to parallelize the queries for A6 fragments.

It is OK to say that, but you should also make it clear that it isn't new.
Otherwise readers might mistakenly believe that this is some new problem
that has never existed before.

  | Do you have problem with it?  If I cannot things that are not new
  | how can I write up an analysis document.

You need to make sure that you're not raising evils, which when investigated
turn out to be just the same as what we have already, and which when viewed
in that light don't look nearly as problematic.

That is, almost all that you're worried about being possible with A6 is
just as possible with A6.   Yet in practice none of it actually bothers
anyone.  There should be a lesson in that.

  | With A6 the problem is more apparent as it is the only resource record
  | type which composes a single address out of multiple query results.

Apart from being new (fear, doubt...) what's supposed to be significant
about that?

  | For example, you can get a completely different IPv6 address out of
  | multiple queries, if you get part of A6 chains swapped with other item.
  | Assuming that this one is correct:
  | 	A6 64 ::t:u:v:w
  | 	A6 48 ::s:0:0:0:0
  | 	A6 0 p:q:r::
  | now if you get "A6 48 ::x:0:0:0:0", you will have a whole lot of fun.

This is djb's argument - it is possible to configure A6 and blow yourself
away.  This is also not new to A6.  It applies to lots of the DNS.

Step back and look at your arguments more carefully, and you'll see that
almost all of them could be made against using the DNS at all - except
that the DNS is now familiar, everyone is used to it, and that it generally
works pretty well, so it is much harder to be worried by anyone showing
that in theory all kinds of things could go wrong.

  | The problem had not been obvious with other resource record types.
  | For other record types, we would get a completely correct answer,
  | or completely hosed answer.  With A6 we would get a partially
  | correct answer (incorrect bits within a part of 128bit address).

That's a completely hosed answer.   This is no different than a CNAME
chain that is accidentally pointed at the wrong place somewhere in the
middle.   That in the A6 case the bits returned happen to be built out
of pieces returned from different records is really irrelevant - other
than that it is new (fear of the unknown).

  | No, this is not a FUD.  You are mixing up two different issues.
  | Because A6 is the only resource record type which composes a single
  | address out of multiple query results:
  | - for other record types, the result is binary - completely believable
  |   or not.
  | - for A6, the result is not binary - part of bits can be believable,
  |   part of bits can be not believable.

No, this is nonsense.  Either you get the right answer, or you have
the wrong one.   However many bits of the wrong one would have been
correct under other circumstances is irrelevant.

  | This is from our implementation experiences.  There are very few
  | people out there (I believe) who have actually implemented A6
  | reassembly/decoding code, so I believe it worth mentioning.  Try it
  | by yourself and see how many mistakes you will make due to the
  | bitwise manipulations.

I didn't ever say that the code was easy to get right.   What I said
was that this is irrelevant.   This code will only be written a handful
of times through eternity.  And while it might take a while to get right
those few times, in the overall scheme of things, it simply doesn't
matter.   I have faith in your ability to debug the code, and to get
it right...

  | No.  Try to implement it into libc resolver (like BIND8) and
  | experience the pain we had.

It isn't clear to me that a dumb resolver (like the libc one) should
ever be doing this, or doing DNSSEC validation, or anything else like
that.   The very existence of such a thing is really an accident of
history.   The bind9 lwresd approach (in one form or another) was what
was envisaged when the DNS was designed (a resolver/cache that all
applications would share, rather than one that exists just for the
purpose of a single name lookup, or two, after which it vanishes leaving
no history).

  | Bitwise operations are so much more painful than 8-bit boundary
  | operations.

Sure, but you do them, get them right, and forget them.

  | But how can you enforce that?  Resolver side can protect themselves
  | by using the upper-limit, however, it is not possible to avoid
  | longer-than-limit A6 chains be placed onto the DNS zone files.

No, it isn't.   Nor is it possible to prevent CNAME chains that loop
forever in the DNS zone files, or NS record chains that go on forever
(consider a set of NS records each of which is 63 levels down some
completely unrelated tree...)

The point is that none of this is new - it is not something that we
need to worry about specifically - we can already see from operational
experience that it is perfectly possible to define things in such a way
that they do work.

Now if you were able to point to something in the A6 spec which guaranteed
that these kinds of problems must occur, then you'd have a valid point.
But just saying that it is possible for people to create stupid
configurations is just causing fear - what matters is that it is possible
to create configurations that have no problems.

Or, if the point was that it is possible to create configurations that
others could never escape from (ie: that it really is possible to
create new DoS attacks) that would also be a valid point - but as you
concede above, resolvers can easily protect themselves from this.

  | A6 fragments are likely to be maintained by different administrative
  | domains.

"Likely"?  Says who?

  | It is not likely that a single admin to control over the
  | whole A6 chain (otherwise, there's no benefit of A6 chain).

Actually, I think it is likely, and there's lots of benefit from that.
There are other possible benefits from allowing others to control the
upper parts, but there are also costs in doing that.

Until we get some operational experience with this, we simply don't
know what is going to be reasonable to do, and what isn't.

  | If you define upper bits (than the part that have assigned to you,
  | like less than /48) you become less ready to renumber events.

Of course.   But that's what the policy that you postulated mandated.
There are plenty of other ways to set things up to avoid that, and
still keep A6, and still avoid building in addresses, what is going to
be good to use in any particular case will depend upon the particular
circumstances.

  | Therefore, the former one in your example will jeopardize the
  | renumbering benefits of A6.  The latter one is better, however, I don't
  | think it manageable (can you prove it is manageable for random dumb
  | admins like me?).

No, and even ignoring the "random dumb admin" comment, which I don't
think applies to you at all, if you're not happy with configuring A6
fragments in a way that will work for you, for any reason at all, then
you can just use A6 0, and you have essentially the same as you would
if AAAA was all that was used.

What this argument essentially amounts to is "I don't see the need for
A6 for myself, I don't think I could use it, therefore you aren't allowed
to use it either".

I don't think I'll have any trouble at all configuring A6 in a way
that will work just fine for me, and unless you can show some problem
that I will cause to you by so doing, I'd appreciate it if you'd just
allow me to do that.

  | If we take "A6 0" route, it is highly likely that vendors do not
  | bother to implement A6 chain chasing, or with a buggy reassembly
  | support.

We just do some interop testing.   Just as we have done for lots of
other stuff in IPv6 (and elsewhere) which isn't really all that likely
to be deployed in the real world very much (or not immediately).
There's nothing new about this - there was a bunch of interop testing
done for DNS dynamic updates for example, which uncovered a whole host
of bugs in various implementations, long before anyone in the outside
world was going anywhere near dynamic DNS.

  | These systems will be deployed into the real world,
  | and we will never be able to enable fragmented A6 usage.  Therefore,
  | I consider "A6 0" approach be a complete waste of 1 byte per an
  | IPv6 record (you can never transition to fragmented A6 situation
  | so there's no benefit against AAAA).  This is not a FUD.  If there's no
  | operational needs, people won't bother to implement them.

I still think you're misinterpreting the "A6 0" approach.   It isn't
that we tell everyone that they must use only "A6 0", and hence
implementors need implement only that - it is that we tell people that
they can use "A6 0", it will work 100% identically to AAAA (once A6
resolvers exist at all), and hence is perfectly safe to do.  No-one will
be melting down the internet with all the extra queries, or setting up
names that no-one else will be able to use, or ...

But anyone who wants to try it will still be able to use A6 n.

  | Now, can you predict how many people will have cache in stub resolvers
  | in year 2005?

No, but that's also so near term as to barely be worth it anyway.

(But my definition of a stub resolver is one that doesn't have cache,
or recursive abilities, etc, anyway, so perhaps I can predict 0 as
the answer using that definition.)

  | In this year, as BIND4/8 resolvers and other non-caching
  | resolver are around, cache deployment in the stub resolver (say, 
  | for UNIX and Windows systems) is almost equal to zero.

Yes.   This was exactly my point in my response to your fears about
what happens to people who define their A6 records with minute TTLs.

  | How long did you wait for this?

No idea.  Perhaps forever - it could be that we always have dumb stub
resolvers, and back end resolvers.  That might mean AAAA synthesis
at that level forever.   But so what?  Who cares where it is done, the
128 bits of address have to be collected together somewhere.

  | I'm equally worried about A6 fragment reassembly code deployment.

ie: I don't know that it is going to happen, hence we can't rely upon it.
That's FUD.   If you could show some reason why it will not happen, that
would be different, but you can't (or aren't) - only that you aren't sure
that it will.

  | I mentioned "A6 0" and "A6 non-zero" this just for clarity.  How can
  | you assert it as a FUD?  It is not a FUD, you just did not understand
  | (or I did not describe it well).

Whether with AAAA synthesis the A6 records collected are A6 0 or A6 n
makes no difference at all.   But raising points of uncertainty makes
the proposal look flawed.   It isn't when the answer simply doesn't
matter.   That is, the only point for mentioning this is to increase
the fear.   That may not have been what you intended, but it is the outcome.

  | Maybe correct.  However, when back end resolvers do not implement AAAA
  | synthesis, the AAAA queries will get propagated into servers for the zones.

Yes, that's true.

Most likely, to handle this, in the near term, sites will include both
AAAA and A6 records for any names that they expect to be looked up by
random others, where it isn't clear whether an AAAA or A6 query will
arrive.   That is, I'd do that for my mail server, FTP server, web server,
etc - but I wouldn't bother for all my workstations, etc, as the only
people I care about being able to find their addresses are local, and
locally I know (or will know) that A6 records will work.

This is just the same as what happened when MX records were introduced.
Initially, everyone had to have A records for their mail domain as well
as an MX record that indicted the server (and which would have had an A
record).   That was because mail servers (SMTP clients) were used to
simply looking up the A record, and the simple deployment of MX records
wasn't going to change that overnight.

Today however, MX records exist all the time with no A record for the
same name - and even worse, which will not have an analogy with AAAA->A6,
there can be an A record at the same node as an MX record, where the
address given has no idea how to handle mail for the domain.  That is,
all the SMTP clients that only do A lookups rather than MX, have been
delegated to the dust heap, if any still exist anywhere, they're so
locked down as to be completely irrelevant to anyone.

  | My worry is that, the approach will hurt us if we deploy it without
  | analyzing it in detail before we do so.

I have no problem with that - I believe more work needs to be done on
analysing A6 setups, and how well they will work.    However, there's no
point at all doing that if before it is finished, someone (some group,
even the wrong group, like ngtrans) decides not to bother waiting for the
analysis, but to simply abandon A6 and keep AAAA, because it is the safe
familiar way.   What would be the point of even starting collecting any
data if that is likely to be the result?

  | So in your world unanswered questions are called "FUD"?

No, just unanswered questions whose point is to remain unanswered, and
thus just raise the fear of the unknown.

  | Did we have consensus for any of the following questions and answers?

No, of not that I know of - all I gave were some plausible answers, not
necessarily the right ones.  I thought I made that clear in my message.
That is, my objective was to remove some of the fear (no more than that).

  | These questions are left open as (1) it is an analysis draft (2) we
  | don't have consensus for ANY of them.  And then you call them FUD?

Yes, when the result of them being left as open questions is "suggest
that A6 be abandoned".

If your point had simply been that we still have things to do before we
can deploy A6, then I wouldn't be objecting, I'd be agreeing.   But that
wasn't your point - it was to have A6 made historic (it's there in the
draft...)

  | Do we all need to obey your answers as you are the prophet of DNS?

Of course not, we need to get answers.   But for that to make sense, A6
needs to still remain as the DNS record intended to be used.  That is,
there has to be some point to bother finding the answers.

  | Now you are contradicting with yourself.  In the above you have mentioned
  | that there would be stub resolvers with caching, and now you are saying
  | that there will be no stub resolvers with caching.  Which one do you mean?

stub resolvers are the dumb things with no caches.   If I ever said
anything different to that, it was an accident.

  | I agree that it has to be between 0 and min(TTL of A6 fragments), but
  | for the choice of the value, there's no consensus.

My point was that it simply doesn't matter.   DNS implementations have
always been free to send any value as the TTL smaller than the max
permitted.  Older versions of BIND actually used to multiply the TTL
left by some constant (I forget what, for this, assume 0.8 or something)
whenever an RR was taken from the cache.   That was perfectly legal.
It resulted in decreased cache effectiveness of course, but also make it
easy to get rid of bad data from someone's cache (just query it lots of
times and the TTL would quickly reduce to 0).

The same is true here, you can use any TTL you like, up to the max that
makes sense, there doesn't need to be a consensus.   And that's without
relying on the stub resolvers ignoring the TTL you send anyway (which
would not be good to rely on, even though it is most likely true).

  | There's no mention in Rob's presentation nor Rob's draft.

Rob's draft (assuming you mean the one which is on the agenda for this
discussion) is a bunch of open issues.   I didn't hear the presentation.
So, that's no surprise.

  | AAAA queries
  | can get propagated into non-first nameservers at ease, when the first
  | one does not have AAAA synthesis.  Given that there are whole lot of DNS
  | servers (1) with AAAA support (2) no A6 support and (3) no AAAA synthesis,
  | it is highly likely that AAAA queries will be propagaged.  You cannot blame
  | people for propagating them (or you will blame everyone running BIND < 9.2).

I think this is the same thing I answered above.   Of course I don't blame
anyone - but please be clear to separate out the two issues here.  The first
is the way that IPv6 records ought to be looked up in the ideal IPv6
internet.  And the second is how we get to there from where we are now.
Only if the second one says "no way, impossible" should we take much notice
of that when answering the first question.

  | The problem here is, again, with A6 there can be certified bits
  | and uncertified bits within a single 128bit IPv6 address, and it
  | is difficult for us to decide whether the synthesized AAAA record is
  | really trustable or not.

No, if any of it isn't trustworthy (authenticated) then all of it is
unauthenticated.   That much is certain.

  | The above is just your proposal, not the consensus.

As I said (in the first reply, and again this time), that is absolutely
correct.  "Just a few plausible answers".

  | Without an answer/consensus we cannot implement AAAA synthesis right.

No, that isn't correct.   That would be saying that we can't implement
A6 correctly, and that simply isn't correct.   The only extra parts with
AAAA synthesis are the TTL (which as long as it is within bounds is correct,
whatever value is picked) and DNSSEC.   The latter is simply impossible,
the resolver inventing the AAAA record out of pieces can't possibly also
invent a SIG record for it (no matter whether or not it gets and verifies
SIG records for all of the A6 fragments).   If the stub resolver really
wanted the SIGs so it could do its own validation of the answers, then it
is really going to have to get the A6 fragments and validate those.  But
as A6 handling is certainly easier than DNSSEC, that shouldn't pose too
much of a problem.

Where the back end resolver is telling the stub resolver that the data is
authenticated in some other way than sending a SIG record (eg: if it is
using TSIG) then it say say "authenticated" the same way it would in any
other answer (but only if *all* the A6 fragments were authenticated of
course).

  | This is not a FUD.  A6 makes the problem more apparent, and is slightly
  | different from other resource record types.

No it isn't.   It is all just the same.   The only difference is that
you're looking for evidence against A6, and we don't get have any
operational experience that says that this matters no more to A6 than
it does to anything else - so it is a good way to raise the fear levels.

  | Yes there is such an approach proposed.  Rob Austin's transitional approach
  | (endnode resolvers use AAAA and DNS servers use A6) is one of them.

No, that's a different thing entirely.   We can keep AAAA queries, without
keeping AAAA RRs in the zone files.

What makes no sense is to keep AAAA in the zone files, and also allow A6 0.
(Of course, as a transitional aid, servers could read "AAAA" in a zone file
and build "A6 0" out of it, provided that the zone signer does the same
thing, where dnssec is in use).

  | Thanks for wording pickiness, but I don't think the change is necessary.

This one isn't just working pickiness - it is a fundamental point.
How often we'd like to have to renumber, and how often we actually
will have to renumber are not necessarily the same thing, or even
related.

What we're supposed to be doing (what we set out to do way back when
ipng first started) is to remove as many impediments to easy renumbering
as possible.   That is, every time we find something that looks like it
will cause problems, we look for a solution that will allow those
problems to be avoided.

We don't simply say "there's this other problem that isn't solved yet,
so there's no point doing anything about this one" - that's defeatism.

We can do better than that - but we have to keep working on each problem,
each little obstacle to renumbering, as we find it.

  | So you are objecting to write down something obvious to you?

No.   I'm objecting to using something which is obvious, but
irrelevant, as an argument.

  | >In any case what counts here isn't what is possible right now, but what
  | >we should be aiming at producing.   What would be the ideal outcome?
  | 
  | I don't agree that it is something we should be aiming.

You mean that we should simply give up on making renumbering easier?

  | Not a FUD.  The above statement is totally correct, and you are
  | asserting it a FUD.

Yes.   Most FUD is correct.  That's how it works.   What it is,
when analysed, is irrelevant.   That's what that was.

  | So again you are objecting to document something obvious to you.

No, again, just to its use in an argument where it carries no force.

This is more bad style - throw in all kinds of stuff that everyone
agrees with, in the hope that they'll just go on agreeing when you get
to the issues which aren't so clear.   Its a standard trick.

  | I'm questioning if it is necessary to renumber that frequently,

My point is that we don't know.   And we won't know, for ages.
20 years ago we would have said it was never necessary (for external
reasons) to renumber an IPv4 net.   But things have changed since...

What we need to be doing now is planning for the possibility that you
might be wrong.   If you're right, the cost will have been small (or
that's the way it looks to me at the minute - we still need data to
determine that one way or the other).   On the other hand, if you're wrong,
and we go your way and assume that you're right, the cost might be huge.

  | and introduce
  | very high complexity and overhead for normal case ("optimized for write").

I disagree with the complexity and overheads - but just like you, I have
no data to back up my guesses.   But I am planning to collect some data.

  | Could you prove that we need higher frequency of renumber?

No, of course not.   Nor can I (or you) prove that we won't need it.

I prefer to plan now for the possibility, so it it happens we'll be able
to cope without years more of deployment effort.   Or at least, as much as
can be done without huge costs.

  | Then what is A6 really?  Describe me in 10 words.  For me, after doing the
  | analysis, it is "overly complicated alternative of AAAA with less benefit".

It is v6 addresses with increased notational and operational flexibility.

  | Yes it is a benefit of A6, however, from the experiment result from Bill
  | Sommerfeld and othres,

That concentrated only on the CPU overheads, you ignored the operational
overheads.

  | I believe it is not big enough to amend the complexity of A6.

I don't believe that A6 needs to be complex.   It is certainly simpler
(though different) than the DNS SRV record (which has weights, and
probabilities, and references to other names, ...) but which is being
deployed now.

You can certainly make it complex, and you can dream up all kinds of
foul looking configurations that no-one will ever understand.  I don't
care.   I can do a clean A6 config for my environment, that's all that
matters to me.

  | Prove that we need to renumber so often that we can amend the complexity
  | of A6.

As above, I can't prove we need to renumber, nor can you prove that
we won't (ever).  But I can, and intend to, measure the complexity
and overheads of A6 (the necessary complexity in particular).

  | Prove it and drop me a note when you're done.

You mean prove that the University of Melbourne only has a small handful
of glue records?   I could do that easily enough, but what would be the
point?

  | >The first clause there is true, I'd like to see some evidence for the
  | >second one, without that it is just more FUD.
  | 
  | I described them in the draft and you did not get it, and you assert it as
  | a FUD.  How nice.

There was no evidence in the draft that
	A6 and AAAA synthesis makes the problem more apparent,
	and more complex to diagnose.
which was the 2nd clause referred to.   Just the assertion of that.
As you keep asking me -- prove it.   Without the proof, or even any
suggestion of some evidence to suggest it, all you're doing is raising
the fear level.   ie: FUD.
	
  | >>	To remedy this problem, we have a couple of solutions:
  | >>	(1) Deprecate A6 and deploy AAAA worldwide.  If we do not have A6, the
  | >>	    problem goes away.
  | >No it doesn't, only this particular way of causing it.
  | 
  | A6 makes the problem more apparent, so if we don't have A6, we have the
  | same amount of problems as today.  What are you trying to mean?

You said "the problem goes away."  What I meant was that no, it doesn't.

Sure, if we had no A6 then there'd be one less way to cause it.  If we
had no CNAME, there'd be another way less.  If we had no MX, there'd be
another way less, if we had no NS, there'd be another way less.

Let's just rid ourselves of the DNS completely, then this problem is
really gone ...

Is that seriously the argument?

  | >>	(2) Even if we use A6, do not configure nameservers for AAAA synthesis.
  | >>	    Deployment issues with existing IPv6 hosts get much harder.
  | >Something still has to build the 128 bit address out of the A6 fragments,
  | >if we're using A6.   That can be called "AAAA synthesis" (the work is all
  | >identical) regardless of whether a RR with the AAAA type is ever actually
  | >produced.   Thus this would make no difference at all - there's no benefit
  | >at all to be gained by prohibiting back end resolvers from doing AAAA
  | >generation for their stub resolvers from this line of argument.
  | 
  | You must give analysis to "A6 0 synthesis", otherwise your word is
  | considered a FUD under your rule.

I'm not sure what you're getting at there, but perhaps I can try to
be clearer.   Note that what I am trying to do is to allay the fear,
so I seriously hope that my statements aren't FUD...

But also note, nothing in this message, or the previous one, in an
argument in favour of keeping A6, or that's not how the messages are
intended - which is why there's almost no point in anyone reading them,
there is very little affirmative point here (which is why I didn't want
to start this in the first place).

My only point is to show that your draft is not a valid argument against A6.

There might be others, and AAAA might still turn out to be the answer,
but your draft does nothing to advance that case.

But, your point above was that one way to avoid the DoS problem would be
to not do AAAA synthesis (and then, from that, to show that no-one would
be able to use A6 anytime soon without it, and so deploying A6 would be
useless).

The fallacy is in assuming that AAAA synthesis has anything to do with the
DoS attack you're describing at all (that is AAAA synthesis in the way
proposed, which is so dumb stub resolvers don't have to learn about A6
records).   That's simply false - something has to compose the 128 bit
address out of the A6 fragments, any DoS attack that was available against
the back end resolver doing AAAA synthesis would be available in exactly
the same way against any smart A6 capable resolver.  Adding in the back
end resolver doing AAAA synthesis doesn't change a thing.  Hence eliminating
that also doesn't fix anything, hence there's no reason to eliminate the
back end resolver, and thus, that stub resolvers only know AAAA today,
and need to get back AAAA, doesn't matter - AAAA synthesis can happen.

I have no idea what "A6 0 synthesis" is supposed to refer to.

  | I presented real information and you just did not understand.

I think I understand it all.

  | Also, it is a FUD to say "there is nothing in the doc" while you are
  | agreeing part of the document (see some of the comments *made by yourself*).

There's lots of truth in the doc, there always is in an argument based
upon FUD.   What there isn't is any connection between the truth and the
conclusion reached.   That all relies on the fear of the unknown.

  | Do you have an expected date to get more experiences and data?

No, but soon.   I had hoped to have a draft written for London (the
current IETF), but it just didn't happen.   A few months would be
about the limit though (I hope).   I have some resources to devote to
doing this, but not huge amounts.

Of course, anyone else is welcome to go actually do some tests, and
collect the data as well...

  | >>    The author do not see benefit in keeping both AAAA and A6 records
  | >No, nor do I (except perhaps for stub-resolvers - ie: keep the RR type,
  | >but deprecate its use in zone files).
  | 
  | So we should drop Rob's "AAAA synthesis" from the candidates.

no, you didn't read what I said.   What I said was "deprecate its
use in zone files" (it being AAAA).   That is, still allow AAAA
queries, and AAAA responses, but all the data in AAAA responses
(after a transition period, of course) will have come from AAAA
synthesis.

  | >>    Given the unlikeliness of frequent network renumbering
  | >There's no evidence for that.  Only for renumbering being difficult
  | >to achieve.   That something is hard doesn't mean that we won't be
  | >forced to do it.
  | 
  | I have already discussed, in the earlier part of the draft,
  | that the frequency of renumbering is not likely to be high.

You asserted that.   You hope that it will be true.   But we simply
have no way to know what will happen in the future, do we?  That's
my point, that we don't know (and yes, there's some FUD in this).

  | Now, if you are asked to prove it, how can you prove this?
  | The way of discussion is not correct - you are asking for an evidence
  | for something noone can really prove,

I am asking for evidence before you rely on it to prove a point, yes.
If you can't collect the evidence, then neither can you rely upon the
conclusion.

  | and because of that you are
  | asserting that the draft is a FUD.  Total nonsense.

Yes, you're speculating on how complex A6 must be (using the worst
case scenarios) and speculating on how little benefit it will be
(assuming the best possible scenarios), and from that concluding
that A6 isn't needed.

  | Now its my turn.  Can you prove that the signing cost difference is
  | significant?

I thought that had been done already...   But if you like, I can take
one of the zones I serve (it has something like 200K names in it, I
don't know how many RRs that translates into) and run the bind 9 signer
on it on one of my DNS servers (that's a SS5 85MHz incidentally - NetBSD)
and after however long it takes, post the numbers.   Do I really have
to do that?   What would it achieve?  Everyone already knows that it is
going to be a big number...

  | For what kind of zone file structure?  For what kind of
  | situation?  Can you cover all the cases we would possibly encounter?

These would be valid questions if you were treating my message as one in
favour of keeping A6.   Once again, that isn't what it was.   All it was
was showing that your draft isn't much of an excuse to deprecate A6.

  | Agree in general, but I think I saw enough evidence from our
  | experimental operations as well as analysis (like this draft).

What experimental operations?   The draft doesn't mention any.  It clearly
implies some investigation of the code, but doesn't give any hint that
you have actually set up some zones containing A6 record and measured the
extra delays, the extra round trips, ...    If you've done that, you ought
to be publishing that data, that would be valuable (that includes the
zone file configurations, costs observed, ...)

  | And you did not present any evidence either.

no, because all I'm doing is analysing your draft - and that only because
you asked me to.   Initially I rejected this approach, and instead just
pointed out that in my opinion your draft had nothing to offer (which
anyone could conclude after reading it).

Eventually I hope to have some evidence to present, when that happens,
the conclusion might be in favour of A6, or might be in favour of AAAA.
The whole point of collecting data is to provide some basis for making
a decision - making the decision before the data is collected seems
backwards to me.

  | No it is not FUD.  You cannot assert like this.  If you say "I did not
  | understnd this" or "I think this part is not correct", I can accept
  | those.  Asserting someone's draft a FUD is not fair and unproductive.

It is fair, if that is what the draft is - its that alone, to justify
my assertion in the first message, that caused me to send the second one
(the previous long one) and then this one.

To rebut my assertion all you need to do is produce the evidence that
backs up your opinions - actually provide some facts rather than
simple assertions.   And facts which actually lead to some relevant
conclusion, rather than irrelevant ones.  That is, you could easily
show that the ASCII code for 'A' is 65, and spend pages proving that,
and from that show that there are indeed proven facts in the draft
(or some later one) - but that doesn't add anything to the actual
conclusion reached.

  | No new inventions, please please.  It can only hurt the deployment more.

Yes, I understand that a major concern is deployment as fast as
possible.   I have some sympathy for that.  But I'm not willing
to sacrifice IPv6's potential to achieve it a month, or a year,
faster.   It may be that events will overtake us all, and that
the decision will be made in the field before the right amount of
data has been collected to allow it to be made well - I hope not,
but that's a possibility.   But I really don't want the IETF to
go rushing headlong into a decision only because there's some
feeling that any decision is better than none, right now.

This is going to be the last long message I send on this topic.
I'd prefer to do something that's actually productive.

kre

---

From: [email-masked]
Date: Thu, 02 Aug 2001 20:03:36 +0900

One last comment - you and I are not agreeing on the urgency of this.
	If we don't pick AAAA or A6 right now, we cannot deploy IPv6 NS
	records and/or IPv6 MX records, we cannot convince gTLDs/ccTLDs to
	accept IPv6 NS record registrations.  The deadline for picking them up
	is at the London IETF.  We wanted the choice like a couple of years ago.

	We operate commercial IPv6 backbone and selling services to customers
	since the summer of 1999.  And we don't have an official choice of
	IPv6 DNS records?  The situation is like a very very bad joke.
	We cannot wait forever.  This way we can never deploy IPv6.
	(btw, I'm using no IPv4 from my laptop as I type this!)

	I appreciate your intent to do the analysis, but I cannot wait forever.
	We did the analysis and test operations, and the result is in my draft.
	I did my homework.

>thus just raise the fear of the unknown.

	The open questions in my drafts are intended to be answered, or get
	the consensus among people.  This is not intended to be left
	ununsewered (What suggested you like that?  Did I tell you so?
	how can can you assert like that without checking with me?).

itojun

---

From: Robert Elz <[email-masked]>
Date: Thu, 02 Aug 2001 18:33:30 +0700

Date:        Thu, 02 Aug 2001 20:03:36 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	One last comment - you and I are not agreeing on the urgency of this.

Perhaps not, though I don't think we're that far apart on that.

  | 	If we don't pick AAAA or A6 right now, we cannot deploy IPv6 NS
  | 	records and/or IPv6 MX records, we cannot convince gTLDs/ccTLDs to
  | 	accept IPv6 NS record registrations.  The deadline for picking them up
  | 	is at the London IETF.  We wanted the choice like a couple of years ago.

A couple of years ago we made the choice.   That was A6.   It has taken
since then until about now (or even a bit beyond now) to get to the point
where A6 can be deployed (when the implementations exist, etc).

This isn't a case where we have 2 competing proposals on a more
or less equal footing, and want to choose one, its a case where we
have an IETF consensus doc, and are now considering deprecating it,
before it has even had a reasonable chance to be tested, and without
doing any actual testing (that has been reported anyway) to suggest
that it won't work.

  | 	We operate commercial IPv6 backbone and selling services to customers
  | 	since the summer of 1999.  And we don't have an official choice of
  | 	IPv6 DNS records?

We do, that is A6.   What we don't have is those actually deployed yet.

  | 	We did the analysis and test operations, and the result is in my draft.

Maybe the draft is just lacking the necessary information, but I see
nothing in it that is more than speculation, and fear of the unknown.

  | 	The open questions in my drafts are intended to be answered, or get
  | 	the consensus among people.  This is not intended to be left
  | 	ununsewered (What suggested you like that?  Did I tell you so?
  | 	how can can you assert like that without checking with me?).

That's from the conclusion of the draft.   It makes no sense to want
answers to questions that are only relevant if A6 is to be used, if the
answer is to deprecate A6.   You say that A6 should be deprecated.  In
that case, it can't possibly be interesting to find the answers to
questions that are only relevant if A6 is to be used...

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Aug 2001 12:02:46 -0000

Robert Elz writes:
> before it has even had a reasonable chance to be tested

We're saying ``deployment will be a disaster, and here's why.'' You're
saying ``let's deploy it and see what happens.'' That's unacceptable.
A6 and DNAME need to be killed _before_ people start relying on them.

---Dan

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Aug 2001 12:16:09 -0400

My main fear about A6 is documentation: it seems too complicated, and the failure
cases for it seem very hard to explain to muggles.

  Muggles have enough time maintaining IPv4 DNS records without DNSSEC.

  I am not certain if DJB is correct about the technical argument about
signatures. I do not have a problem resigning my zones every day. I think
that I have enough CPU. Maybe this won't be true for ccTLDs, etc.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Dancer Vesperman <[email-masked]>
Date: Fri, 03 Aug 2001 11:57:51 +1000

> A6 and DNAME need to be killed _before_ people start relying on them.

You know, I seem to recall that I said the same about HTTP, way back when...

I get the impression that it's too late to deploy something that isn't 
already ready.

I agree with itojun (It's true that I spend a lot of time doing this): 
There is no time. A broken thing is probably better than no thing.

IT people tend to laugh at IPv6 as vaporware these days. Personally, I 
don't much _CARE_ if it's possible for a DNS administrator to get things 
Horribly Wrong(tm) with A6 records. They _already_ get things Horribly 
Wrong(tm) with A records, NS records, MX records, SOA records and CNAME 
records....screwing up their domains with yet another record type would 
merely be continuing a grand tradition.

Dan: You have a point. Maybe a good one. Personally, I don't think it's 
quite good enough given the apparent time-frames. Fait accompli and all 
that.

D

---

From: Pekka Savola <[email-masked]>
Date: Sat, 4 Aug 2001 15:14:43 +0300 (EEST)

Let's continue the renumbering debate only in ipng@; please strip ngtrans
from Cc: if replying.

On Thu, 2 Aug 2001, Robert Elz wrote:
[snip]
> each little obstacle to renumbering, as we find it.

I have a pragmatic (as probably most others) approach toward renumbering.
Getting it working is completely is probably at least as difficult problem
as working public key infrastructure problem (not that these have to be
necessarily related, but the biggest problems aren't necessarily technical
in nature).

I'm not going into automatic router renumbering itself. But "site
renumbering", a manual operation, can be made to "kinda work", I think.

The most important issue is getting all hosts (or 99.5%) autoconfigured.
If this can't be assumed, we've already lost the battle against
scalability.  1, 10, even 30 routers or very important servers can be
manually reconfigured in an acceptable amount of time, but if all servers,
much less end-nodes, were to be reconfigured manually too.. not nice.

Therefore, in practise, we should remove impediments to using
autoconfiguration and having to manually specify network settings even if
you do (e.g.  DNS) if those come up.

If this is agreed upon, the issues here are:

 1) accept the fact that if there is no DNS service (e.g your network
cable breaks and you reboot, the computer may get stuck at boot more or
less indefinitely), you're on your own.

(this could be worked around by vendors' some automated mechanism of
copying the "last-known" addresses needed at boot to hosts.txt or
something)

 2) implement auto-discovery of dns servers e.g. with anycast (work
already in full swing)

 3) implement a mechanism to assign other than EUI64 suffixes
automatically.  IMO, this is required for servers -- having EUI64
identifier in DNS for a server is IMO unacceptable. I want my servers to
be like PRFX::1, PRFX:1::10 etc. -- short, stable and easily remembered.

(not that there is need for anything from IETF here -- this is just an
approach vendors could use, as the autoconfigured prefix is already
known).

 Any others?

Practically, now renumbering sites would be _much easier_ already (ie.
doable) if these were to be achieved.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Matt Crawford <[email-masked]>
Date: Mon, 06 Aug 2001 16:57:13 -0500

(Gee, I almost wish there had been time to catch up on mail before today...)

> Even if it is only a few records a couple of times a year, the
> customers will quickly bail and find a provider that can deal
> with the entropy. This is just another case of the point of pain
> not matching with the gain, so it simply won't happen.

These customers that bolt to avoid renumbering -- they will take their
portable IPv6 address blocks with them?

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 2 Aug 2001 13:37:24 +0100

Robert Elz wrote:

> A couple of years ago we made the choice.   That was A6.   
> It has taken since then until about now (or even a bit 
> beyond now) to get to the point where A6 can be deployed 
>(when the implementations exist, etc).

> This isn't a case where we have 2 competing proposals on 
> a more or less equal footing, and want to choose one, its 
> a case where we have an IETF consensus doc, and are now 
> considering deprecating it, before it has even had a 
> reasonable chance to be tested, and without doing any actual 
> testing (that has been reported anyway) to suggest that 
> it won't work.

I have no doubt we could figure out how to make A6 work, and with a few guidelines written up even keep it from being noticeably different. My concern is that the basic premise for its need is explicitly contradictory to economic realities. As much as people claim they need to renumber their customers to compress the routing table, how many will really tell the people paying them that to continue being a customer they have to go through some level of routine pain? Even if it is only a few records a couple of times a year, the customers will quickly bail and find a provider that can deal with the entropy. This is just another case of the point of pain not matching with the gain, so it simply won't happen.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 7 Aug 2001 15:07:40 +0100

Matt Crawford wrote:

> These customers that bolt to avoid renumbering -- they will take 
> their portable IPv6 address blocks with them?

The point was simply they would find a way to avoid recurring pain. 

Tony

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 07 Aug 2001 07:21:31 -0700

> > their portable IPv6 address blocks with them?

Portable IPv6 address blocks?  Interesting concept.

>The point was simply they would find a way to avoid recurring pain.

Yeah.  Like NAT.

Rgds,
-drc