Date: Thu, 02 Aug 2001 15:55:29 +0900
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| 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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
