Subject: Re: I-D ACTION:draft-ietf-dnsop-v6-name-space-fragmentation-00.txt

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 12:44:37 +0200 (EET)

I'm not on the list, so please keep Cc:.

On Thu, 24 Jan 2002 [email-masked] wrote:
> 	Title		: IPv4-to-IPv6 migration and DNS name space 
>                           fragmentation
> 	Author(s)	: J. Ihren
> 	Filename	: draft-ietf-dnsop-v6-name-space-fragmentation-00.txt
> 	Pages		: 
> 	Date		: 23-Jan-02
> 	
> This memo documents some problems forseen in transitioning from a
> IPv4-only DNS hierarchy via a long period of mixture to an
> IPv6-mostly situation sometime in the future. The mixture period is
> expected to be very long, and hence design choices should very much
> take this into account, rather than just regard the transition as a
> relatively short period of pain.

A few comments.

2. Introduction to the problem of name space fragmentation

   With all DNS data only available over IPv4 transport everything is
   simple. IPv4 resolvers can use the intended mechanism of following
   referrals from the root and down while IPv6 resolvers have to work
   through a "translator", i.e. they have to use a second name server
   on a so-called "dual stack" host as a "forwarder" since they cannot
   access the DNS data directly. This is not a scalable solution.    

==> The last sentence is completely false; the truth is exactly the
opposite.  This makes an assumption that there would be only a few
"forwarding" servers: IMO, _every ISP_ providing IPv6-only service should
provide this capability.  This is very scalable.

4. Policy based avoidance of name space fragmentation.

   Today there are only a few DNS "zones" on the public Internet that 
   are only available over v6 transport, and they can mostly be  
   regarded as "experimental". However, as soon as there is a root
   name server available over v6 transport it is reasonable to expect
   that it will become more common with v6-only zones over time.

==> wrong assumption: I don't believe making root v6-enabled makes
v6-_only_ zones any more common.  People can shoot themselves in the foot
now, and could then too, of course.

4.2. Zone validation for non-recursive servers.

   Non-recursive authoritative servers are name servers that run
   without ever asking questions. A change in the zone validation
   requirements that force them to query for the addresses of name
   servers that are part of delegations in the zone change this, since
   they now have to query for these addresses. 

   However, the main reason that it is important to be able to run
   without asking questions is to avoid "caching" possibly bogus  
   answers. This need can be managed by requiring that a non recursive
   name server throw away the looked up address information after
   having used it for validation of the delegations in the zone. 

==> validation needs only be done when zone is loaded: this does not mean 
the records queried (for this specific purpose) will have to be cached -- 
so I don't see problems here.

4.3. Future requirement of IPv6 address for at least one name server.

   The immediate need for clarified policies for delegation is to 
   ensure that IPv4 name space does not start to fragment. Over time, 
   however, it is reasonable to expect that it may become important to
   add a similar requirement to IPv6 name space.

   I.e. an even more refined policy possible at some point in the 
   future would be:

        "Every delegation point should have at least one name server
	for the child zone reachable over IPv4 transport (i.e. should
        have an A record) and at least one name server reachable over
	IPv6 transport (i.e. should have an AAAA record)".

==> in (far) future, I'll expect there will have to be similar kind of 
forwarders as now with IPv6; no big deal.

==> I support AAAA records myself but is it sensible to make a "political 
statement" here ? :-)

5. Overview of suggested transition method.

   By following the steps outlined below it will be possible to
   transition without outages or lack of service.

==> this seems to destroy the credibility of this "comparison".

6. How to deploy DNS hierarchy in v6 space.
[...]
   c) a way of verififying the correctness of the resulting configuration

==> this was not covered in this draft any further(others were) -- as this 
intentional?

6.2. How to deploy DNS data.
[...]
   a) identify all name servers that will serve the DNS domain, with
   their IPv4 and/or IPv6 addresses

   b) arrange for a suitable method of zone synchronization

==> does one need to "dramatize" master/slave zone transfers?

   It is recommended that the name servers run on single stack
   machines, i.e. machines that are only able to utilize either IPv4
   transport or IPv6 transport, but not both.

==> more elaboration why this is good would be nice.

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

---

From: Johan Ihren <[email-masked]>
Date: 09 Feb 2002 18:36:14 +0100

Pekka Savola <[email-masked]> writes:

Hi Pekka,

> provide this capability.  This is very scalable.

Well, that's not the entire problem. "Forwarding" is something you
configure statically to get help from someone else with resolution.
Because of this (and other reasons) you configure your forwarder as an
IP address, not a name.

Over time we expect to have hundreds of thousands (or more) of caching
resolvers on v6 transport. Given a traditional forwarding solution all
of them will then need statically configured v6 addresses to the ISP
forwarding services. This will have to be maintained over a very long
term (tens of years), with ISPs coming and going, ISPs having to
restructure their services (i.e. moving the forwarders), etc, etc. 

Deploying a few forwarders to be used by a few caching resolvers for a
few months is easy. Deploying massive numbers of forwarders to be used
by even larger numbers of clients for tens of years *with no location
mechanism* is definitely a problem.

Since it becomes a problem as we scale it up I see it as a scalability
problem. That is not to say that it is a *performance* problem. It is
a *maintenance* problem that does not scale.

Please see draft-ietf-ngtrans-dns-ops-req-03.txt for more discussion
about this.

> v6-_only_ zones any more common.  People can shoot themselves in the
> foot now, and could then too, of course.

Look at this in a really long term perspective: today we have all the
zones available over v4 transport and (in practice) zero over *only*
v6 transport. At some point in the future we expect the Internet to be
mostly v6, with large portions of the net in all likelihood v6-only.

For domainholders in these future v6-only parts only deploying over v6
transport is not so much a question of shooting at one's feet as it is
a quistion of optimizing for local needs at the expense of global. And
such things will happen.

> so I don't see problems here.

Exactly.

The real problem is of course that validation is costly, and that
large, delegation-dense zones would have immense problems doing
validation at all. But for smaller zones it would work, and may be a
useful tool to sites further down in the hierarchy.

> forwarders as now with IPv6; no big deal.

Hmm. I don't understand this comment. Can you elaborate?

> ==> I support AAAA records myself but is it sensible to make a "political 

Well, I'm in favour of A6 myself, but that doesn't matter much
here. The AAAA is the standards track mechanism for v6 name-to-address
mapping and I see no political controversy in using it. Should the
tides at some point in the future go in another direction we'll have
to update.
 
> ==> this seems to destroy the credibility of this "comparison".

Please elaborate.

> ==> does one need to "dramatize" master/slave zone transfers?

Well, you probably know as well as I do that surprising numbers of
zones manage to botch zone transfers when master and slave share
transport. I think it is a safe guess that this will increase when the
master and slave does not share any transport.

> ==> more elaboration why this is good would be nice.

Yes, but that will have to be a topic for some other document.

Thanks,

Johan Ihren

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Feb 2002 20:37:38 +0200 (EET)

> restructure their services (i.e. moving the forwarders), etc, etc. 

This seems to be no different from having to renumber your site; if you 
have to renumber, I suspect changing this also is not all that fatal thing 
to do.
 
> a *maintenance* problem that does not scale.

Nothing prevents defining e.g. IPv6 anycast addresses to be (also) used
for this specific purpose (or well known addresses, in IPv4 anycast
-style), to be deployed everywhere in the world.  This avoids the
maintenance problem.
 
> mostly v6, with large portions of the net in all likelihood v6-only.

I agree, but the text dramatizes this: v6-only servers would not happen
any time soon, at least from people who care.  The text seems to paint a
picture that v6-only servers would start popping up soon after v6 root.
 
> a quistion of optimizing for local needs at the expense of global. And

Those v6-only people who care at all about IPv4 world (I'd say about 
99.99% of them), will provide a secondary on IPv4-only transport for a 
long time, unless some BCP gives other reasons for this (see below).
 
> useful tool to sites further down in the hierarchy.

If you have so many delegations that it would matter (e.g. 1000's,
10.000's etc.) I'd expect the checks would be done externally, over time
(e.g. check this when zones are delegated, when appropriate records are
updated (this might be unnecessary), etc.), not immediately after loading
up the zone.

> Hmm. I don't understand this comment. Can you elaborate?

If, in 10 years, there would only be 1% of IPv4-only sites, we _could_
define a mechanism that they must configure a dual-stack server to act as
their forwarder (e.g. with IPv4 anycast address).  At this point, IPv4
_could_ probably also be removed from root (also forces the people to make
this change :-).

Or, this could be the mechanism for being able to query v6-only zones even 
though root and the delegation path would still be dual stack.

> tides at some point in the future go in another direction we'll have

RFC2874 is also Standards track, and even though it doesn't obsolete 
FC1886 it makes a few statements about A6 being used instead.
  
(note: I was only suggesting adding something like "e.g." where AAAA is 
mentioned.)

> > ==> this seems to destroy the credibility of this "comparison".

If you wish to compare two mechanisms, you should not slip in remarks that 
might be viewed as propaganda against the other mechanism.
 
> > ==> this was not covered in this draft any further(others were) -- as this 

Did you miss this ?
 
> master and slave does not share any transport.

This seems to mostly depend on the assumption that they don't share 
transport.

> Yes, but that will have to be a topic for some other document.

Yes, but this fact seems to be depended on in this draft, like above.

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Feb 2002 17:20:43 -0800

people, please listen carefully to johan.  he has thought a lot about this
problem, and it is a *very* difficult one, architecturally, operationally,
and even socially.  but we need to come up with an agreed approach.

randy

---

From: Johan Ihren <[email-masked]>
Date: 25 Feb 2002 15:08:31 +0100

Pekka,

First I'd like to apologize for the delayed response. Real work
intervened. Second, I want to be the first to admit that there are
inconsistencies of various kinds in the first draft and my only excuse
is that it was written in its entirety in a one-stretch 3h clock-chase
in a hotell lobby 3 hours and 5 minutes before draft cut-off. I'm
grateful for having all such mistakes pointed out so that I can fix
them.

> -style), to be deployed everywhere in the world.  This avoids the

This only works in one direction: v6 client to v4 server. But I
completely agree with you that given some sort of DNS transport
bridging service, locating the bridges on v6 anycast addresses is
probably the best solution to that sub-problem. And as you may know
there is a draft by Alain Durand proposing exactly that mechanism.

Then remains the question of whether we bridge should be a "forwarder"
(i.e. recursive, has to start over from the root, even if bridgning is
only needed for the last mile) or a "proxy" (non-recursive) and of
course the real headache (v4 client to v6 server).

> picture that v6-only servers would start popping up soon after v6 root.

Today it is very hard to operate on the Internet without ties to v4
for various services. Even if you are a single stack v6 box you still
need v4 services that you will access through various gateways and
bridges and the presently v4-only roots are an obvious example of
this. Every such service that becomes available natively on v6 weaken
these ties, and in the particular case of DNS the emergence of v6
roots are a very obvious example.

So the question is not exactly what will happen "soon", but rather
where we will find ourselves as these ties become weaker over
time. And I do not at all see it as unlikely that there will emerge
zones that are only available over v6 transport when that becmes
possible, especially from places that simply have no access to
available v4 address space.

Furthermore, the focus of the document is not the people "who care"
(and have resources). They do not usually have a problem, since they
in this case will simply ensure that their zones are reachable of both
transports. Foucus is rather on the people who either do not have
sufficient insight or not sufficient infrastructure to easily keep
their zones available over v4 transport. 

> long time, unless some BCP gives other reasons for this (see below).

I agree. The ones that *care* about v4 and have the means. However, I
do not think that will constitute 99.99% of them. Not even close. And
whatever number we use it is sure to *shrink* over time.

> updated (this might be unnecessary), etc.), not immediately after loading

Certainly. 

You have a span of measures for validation to choose from. At one end
it is integral to loading the zone, so that it is impossible to give a
referral that is not possible to follow over v4 transport. At the
other end you simply ask the child at the time of delegation to please
check out the "has v4 transport" box on the application or else the
delegation will not happen (but you do not validate yourself).

The strict validation will certainly keep the namespace reachable, but
carries other pains. The loose validation will not catch every
"non compliant" delegation, and that is also a kind of pain.

The sum of the pain is probably more or less constant and I don't
really want to judge where a certain parent should put its
painkillers, since that will be different for different parents.

But I simply do not agree that it is possible to de-couple validation
entirely from zone loading without thereby allowing for a higher
fraction of errors.

> If, in 10 years, there would only be 1% of IPv4-only sites, we
> _could_ define a mechanism that they must configure a dual-stack
> server to act as their forwarder (e.g. with IPv4 anycast address).
> At this point, IPv4 _could_ probably also be removed from root (also
> forces the people to make this change :-).
> 
> Or, this could be the mechanism for being able to query v6-only
> zones even though root and the delegation path would still be dual
> stack.

Ok. Well, I think there will be some debate on whether that is a "big
deal" or not. The problem with the v4 clients is basically the
proverbial "legacy problem".  They were deployed according to all
relevant standards at the time and have some sort of expectation of
being able to lookup names on the Internet. As soon as that is no
longer true their environment will have deteriorated since something
that was working no longer works. And it is simply not possible in all
cases to just ask them to "please upgrade", since that option may not
be available.

I've seen estimates that there are more than one million caching
resolvers on the public Internet today and reconfigure all of them
(even if we could find them, which we cannot) to utilize a forwarding
scheme is not trivial. It is in all likelihood not even possible. 

But whichever decision we arrive at will most definitely be a "big
deal", since it basically determines whether we will make a an
"upgrade" to the Internet without backwards compatibility that breaks
more than 99% of the installed base.

This is not a statement that we shouldn't do that. Perhaps we should.
But if, then the justification should be "there was no better
alternative", not "it was no big deal" ;-)

> (note: I was only suggesting adding something like "e.g." where AAAA is 

Oh, sure. No problem.

> might be viewed as propaganda against the other mechanism.

That is obvious. What is not obvious is that there is some sort of
comparison going on here. I cannot even find the word "comparison"
(that you have put within quotes) in the draft.

> > > ==> this was not covered in this draft any further(others were) -- as this 

Yes. Editorial error. Thanks for pointing it out.

> This seems to mostly depend on the assumption that they don't share

Of course. That's what I said.

> Yes, but this fact seems to be depended on in this draft, like above.

Since I'll remove the recommendation I will have to remove the
references to it also. Obviously.

Regards,

Johan Ihrén

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Feb 2002 15:12:04 +0200 (EET)

> > have to renumber, I suspect changing this also is not all that fatal thing 

You didn't comment on this one except with one line break, so I guess you 
forgot to do so.
 
> there is a draft by Alain Durand proposing exactly that mechanism.

I was not aware of that, but after checking, I found the draft and will 
read it at some point.
 
> course the real headache (v4 client to v6 server).

Note that the classification problem would go away if we could assume the
server would also be used for other lookups, it should always have cached
data for all but the last mile.

v4 client to v6 server is of course still a problem if you assume:
 - v4 client performs queries beginning from the root, not via a forwarder
 - v4 client would very much like to get DNS data from v6-only zones
   (I think the chances are very very low it'd find anything there.)
 - etc., as was mentioned below.

I think we should consider the sub-problems separately:
 1) v6-only -> v4-only
 2) v4-only -> v6-only

1) is, I think, the real issue at hand here, and MUST be solved somehow, 
and rather quickly.  A few mechanisms work, some more operational than 
others.

2) is a bit more academic exercise, and if an easy solution won't manifest 
itself, I think it should be handled by e.g. publishing a BCP "don't do 
that if you have any v4 records in your zone or your subzones".  Also, I 
don't think this MUST be solved today.. it would be nice to, but the focus 
should be on 1).

but I think we've discussed most of this already.

> their zones available over v4 transport. 

One could argue they don't very probably have any v4 records anyway.

[...]
> scheme is not trivial. It is in all likelihood not even possible. 

The number of v4-only caching resolvers in "10 years" (the time when v4 
removal could even be considered) would be much, much smaller.
 
> (that you have put within quotes) in the draft.

You introduce two alternative approaches and explore their seemed 
advantages/drawbacks.  I'd call that a comparison.

---

From: Johan Ihren <[email-masked]>
Date: 28 Feb 2002 17:59:59 +0100

Hi Pekka,

> You didn't comment on this one except with one line break, so I guess you 

Yes. Sorry. Can we let this one rest with just comparing it with the
taxman?  "This new tax is just a few more percent of your income.
Surely that will not be a problem for you to pay?"

I want see things without obvious future headaches while you seem to
argue that with one headache already raging, another one will not hurt
much. I think that switching away from A6/DNAME will increase future
pain when trying to solve the renumbering problem, but just because
that particular stone is already rolling we shouldn't just add to the
collective pain.

However, *if* the anycast trick turns out to work for the case v6
client --> v4 server, then this particular problem shrinks to
manageble size again.

> data for all but the last mile.

I think there's a teeny weeny bit too much of .com to cache all of it
these days... and then you're back to exactly the same recursive
lookup as starting over implies, since statistically no one has to hit
the roots for a normal lookup anyhow.

> I think we should consider the sub-problems separately:

I assume that you mean that the first is "v6 client --> v4 server" and
the second is "v4 client --> v6 server".

> and rather quickly.  A few mechanisms work, some more operational than 

1) is at least possible to solve, through the suggested anycast
   method. However, not everyone agrees that this is the real issue.

> 2) is a bit more academic exercise, and if an easy solution won't
> manifest itself, I think it should be handled by e.g. publishing a
> BCP "don't do that if you have any v4 records in your zone or your
> subzones".  Also, I don't think this MUST be solved today.. it would
> be nice to, but the focus should be on 1).

If you call this an "academic exercise" in Randys presence I cannot
take responsibility for the consequences ;-) But really, I do *not*
think this is an academic issue. This is a major issue, because we're
about to start destroying (in the sense of "eroding") the Internet
namespace, as seen from a v4 client.

For many years to come v4 clients will constitute the bulk of the
Internet. And destroying their namespace is not a thing to be taken
lightly. They may get annoyed at you ;-)

> but I think we've discussed most of this already.

Yes.

> One could argue they don't very probably have any v4 records anyway.

And what does that matter? We're not talking about reachability of
some app service, we're talking about maintaining the DNS
namespace. 

Let's assume that you're v6 only, couldn't care less about v4
etc. Then you delegate a subdomain to me. And I do care about v4. I do
make my webserver available over v4 transport. Do you see the problem?

> removal could even be considered) would be much, much smaller.

I think it is a bit premature to start discussing v4 removal. On the
contrary I think that a common mistake is to consider this to be a
migration from v4 to v6. A better view is as a migration from v4 to
(v4+v6).

> advantages/drawbacks.  I'd call that a comparison.

I do? Wow, I had no idea. Really, either I am really deeply asleep at
the wheel or you are reading the wrong document (my guess would
honestly be the former). We simply do not communicate here, so, since
this is probably not a really central part of the discussion I suggest
we either synchronize our watches offline or simply drop this part.

Regards,

Johan