Date: Wed, 01 Aug 2001 23:03:11 +0900
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| 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
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
