On 17-apr-04, at 16:04, Pekka Savola wrote:

Since there are no services that are inherently only possible over
IPv6, the existence of services that are only available over IPv6 means
that someone is running (effectively) IPv6-only. If they were fully
dual-stack then the service would also be available over IPv4. So
usefulness of IPv6 == usefulness of IPv6-only.

Pretty much everything can be plugged to v4 with a lot of effort.  But
at some point someone might actually figure out that doing that makes
no sense.

One of the things that makes no sense is to keep using v4 for stuff such as DNS lookups and thereby forcing people to keep v4 in their network.


In a
large network, having to run IPv4 everywhere just for the DNS is NOT
cool, as this means having DHCP servers, worrying about subnet sizes
and everything else.

If we needed to design v6-only systems, I don't think DNS discovery is
coming even close to top of the list of problems we'd need to solve.

What would this list be then? Feel free to reply privately for this.


In an environment where the set of applications is
limited (I for one only need SSH and HTTP 98% of the time) running
v6-only internally and use proxying to talk to the v4 world is rapidly
becoming an interesting option.

And for the rest, 2%?  That's the gritty part here.  (As well as
deploying the infrastructure for the proxies etc.)

DNS discovery is most relevant to mobile systems. (It's also very useful for non-mobile systems but manual configuration is much more doable for those.) So if I only need v4 2% of the time I can easily solve this by making sure I connect to a v4-only or dual stack network part of the time, while running v6-only some of the time.


In order to be really useful, IPv6 needs to be able to function regardless
of the IPv4 status du jour. Example: a couple of RIPE meetings ago they
had lots of troubles with the DHCP server. Now I was happily logged in
to my server over SSH and tunneling email back and forth, but I was
completely unable to access any web pages, even the ones on my own box,
because I couldn't access the DNS: I had no IPv4 address, and MacOS
didn't support DNS transport over IPv6 at that time. Now if I can run
into this kind of trouble without actively looking for it, how are the
chances that something similar will happen at times to the ontold
millions whom IPv6 will be bestowed upon in the future?

Sure, this will happen.  But it will be no worse to the mainstream use
as IPv4 won't work in any case, so there's little difference.

I honestly don't understand how you can say something like this. Obviously not having v4 is nearly always a big problem, but if we can make sure people still get to use IPv6 in those cases, this would be extremely helpful in many cases, even today, for instance in the case where the user can access her email over IPv6.


And it provides an incentive to people to deploy dual stack.

I'm not arguing that we should delay or avoid specifying DNS
discovery; I'm just saying that it isn't our top priority, and folks
who think it is are probably thinking of IPv6 deployment in different
kind of terms.

I'm not privvy to your personal priority list. The only thing I know is that we are discussing IPv6 DNS resolver discovery *now* so we need to do a goot job at it.


It's not a question of going away. And how many people are still
running Windows 98? Or even 95 for that matter? Old stuff just doesn't
go away.

Such old stuff (of today, say Windows 2003) is very unlikely even
supposed to function properly in IPv6-only operation.

That's exactly my point. If a simple, but useful DNS discovery method had been specified several years ago, Windows 2003 might have included it and be able to run v6-only.


Let me ask you a question: suppose that someone wants to make a full IPv6 implementation, one that can be expected to work for the next 10 years or so. At which point in time were (or will be) the IPv6 specifications mature enough to base such an implementation on?

Note that in the absense of DNS resolvers reachable over IPv6, either
due to failed discovery and/or lack of configuration, DNS resolvers
reachable over IPv4 may be used, if available.

This document is not meant as a lever that can be used to show the
vendors, "see, we need IPv6 DNS discovery!"; we need
truth-in-advertising and the earlier statement is fully correct here:

   Note that IPv6 DNS resolver discovery is not required for dual-stack
   nodes in dual-stack networks as IPv6 DNS records can be queried over
   IPv4 as well as IPv6.

I'm sorry, but I disagree. This text assumes there are nodes which are inherently dual-stack. That is an assumption we can't make. Even the implementor can't make this decision: whether a node runs v4-only, v6-only or dual stack is, and should be, up to the person running the box. If implementors don't want to build a stack that doesn't provide full functionality in a v6-only setup, that's of course their choice, but we should certainly not encourage them to do so. So if you want to keep your text, I think we should add:


However, IPv6 DNS resolver discovery or manual configuration is necessary
for a node to operate in the absense of reachable IPv4 DNS resolvers,
either because of an outage or because the node is configured for IPv6
operation only.


Teasing apart two major points:

 1) DNS resolver discovery is not *required* (in specific scenarios),
but it does not hurt either.

Which is a moot point, because:


1. This isn't a standards document
2. The specific scenario the node operates under depends on the operator

 2) you can only omit DNS resolver discovery if you're in a dual stack
network and you're a dual stack node (if you have v6-only scenario in
mind, you need it in any case).

In other words, this says "In specific, common scenarios, IPv6 DNS
resolver discovery is not required", while your suggestion says "If
DNS resolver discovery doesn't work or doesn't exist, you can fall
back to v4 as well if that works for you".

The former is IMHO much more accurate,

They're both accurate, the question is what kind of advice implementors are going to read into it. You seem to be saying "it's ok to require IPv4 to be present" while I want to get across "be careful not to unintentionally assume the presence of IPv4". (I would like to go much futher than that, though...)


but I think the "required" part
could be expanded to include a recommendation as well, like:

   Note that even though IPv6 DNS resolver discovery is a recommended
   procedure, it is not required for dual-stack nodes in dual-stack
   networks as IPv6 DNS records can be queried over IPv4 as well as
   IPv6.

Would that alleviate your concern?

No. See above. Any "not required" reads as "don't bother to include this part".


.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

Reply via email to