> | 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.
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
---
>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).
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
>> If we are to use fragmented A6s (128bit splitted into multiple A6s),
>> we have a lot of issues/worries."
>FUD.
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.
>> 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.
>> 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 parti=
>cular
>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.
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.
>> 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.
Again, I did not include "A6 0" into "fragmented A6 records" case.
>> 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.
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.
>> 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.
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).
>> 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.
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.
>> 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.
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.
>FUD.
No. See the above.
>> 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 qualitative=
>ly
>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.
No. Try to implement it into libc resolver (like BIND8) and
experience the pain we had.
>> 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.
Bitwise operations are so much more painful than 8-bit boundary
operations.
>> 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.
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.
>> 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.
I agree this is not just a problem of A6, however, A6 makes the problem
much more easier to exploit.
>> 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).
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?).
>>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.
My text describes what I got from the past IETF presentations and
slides. Maybe you right, maybe I'm right.
>> 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.
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.
>>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.
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.
>> 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.
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).
>> 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.
Maybe correct. However, when back end resolvers do not implement AAAA
synthesis, the AAAA queries will get propagated into servers for the zones.
>> 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.
My worry is that, the approach will hurt us if we deploy it without analyzing
it in detail before we do so.
>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...
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?
>> o What is the DNS error code against AAAA querier, if the A6 reassembly
>> fails?
>SERVFAIL, the same as when any DNS lookup fails.
Maybe, but I'm not sure. I need to hear voice from others.
>> 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.
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.
>> 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).
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).
>> 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.
Okay, that is one possiblity.
>> 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...
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.
>> 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).
This part you don't have a concrete answer so I'll wait for others to
add more opinions.
>> 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.
Without an answer/consensus we cannot implement AAAA synthesis right.
>> 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.
This is not a FUD. A6 makes the problem more apparent, and is slightly
different from other resource record types.
>>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).
(snip)
>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.
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.
>>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.
Thanks for wording pickiness, but I don't think the change is necessary.
>> 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 sho=
>uld
>be much less need to share addresses.
(snip)
>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 dialup
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.
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.
>> 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?
I don't agree that it is something we should be aiming.
>> 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.
Not a FUD. The above statement is totally correct, and you are
asserting it a FUD.
>> If you would like to maintain reachability
>> from the outside world, a site administrator needs to carefully
>> coordinate site renumber.
>True. So?
So again you are objecting to document something obvious to you. Rediculous.
>> 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.
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?
>> 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.
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".
>> 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).
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.
>> As seen above, it is questionable if we
>> renumber network that often, so it is questionable if A6 brings us an
>> overall benefit.
>FUD.
No. Prove that we need to renumber so often that we can amend the complexity
of A6.
>> 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...)
Prove it and drop me a note when you're done.
>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.
Because previous sections are not FUD, 5.1 is not a FUD too.
>> 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.
I described them in the draft and you did not get it, and you assert it as
a FUD. How nice.
>> 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?
>> (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.
>> (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.
Okay.
>> (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.
(snip)
>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.
(4) maybe a leftover from the previous revision of the draft. Sorry about it.
>>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.
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*).
>> 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.
Do you have an expected date to get more experiences and 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).
So we should drop Rob's "AAAA synthesis" from the candidates.
>> 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.
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.
>> 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.
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?
>> 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).
Yes.
>> 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.
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.
>> 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.
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.
>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).
No new inventions, please please. It can only hurt the deployment more.
>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.
Well, now you need to go through my comments again. A bad day for you.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
