Subject: (ngtrans) moving to IPv6

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Mar 2002 12:39:44 -0000

This is http://cr.yp.to/proto/ipv6.html, my current take on the IPv6
transition.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

The IPv4 address crunch

   Computers on the Internet talk to each other through IPv4, version 4
   of the Internet Protocol.
   
   Each computer on the Internet has its own IPv4 address, similar to a
   phone number: for example, 131.193.178.181. The target of each packet
   of data is identified by an IPv4 address.
   
   Problem: There are only a few billion possible IPv4 addresses. Many of
   those addresses have already been allocated. What happens when we run
   out of IPv4 addresses?
   
   Partial solution: Do all these computers really need to be on the
   Internet? A company with 20 computers browsing the web doesn't need to
   put all those computers on the Internet. It can have a single computer
   on the Internet (a ``proxy'') that retrieves data from the web on
   behalf of the other 19 computers.
   
   Most people agree, however, that proxies merely delay the inevitable.
   
   Long-term solution: IPv6, version 6 of the Internet protocol, has many
   more addresses. There are other improvements from IPv4 to IPv6, but we
   can survive without them; what's really important is the expansion of
   address space.
   
The magic moment

   Right now (March 2002), relying on IPv6 addresses for your Internet
   communication would be mind-bogglingly stupid. Millions of Internet
   clients won't connect to servers on IPv6 addresses. Millions of
   Internet servers won't accept connections from clients on IPv6
   addresses.
   
   The magic moment in the history of IPv6 will be the moment when this
   changes: the moment when people can start relying on IPv6 addresses
   for their Internet communication. That's when the Internet will no
   longer be threatened by the IPv4 address crunch.
   
   What do we need to do to reach the magic moment? The answer is
   obvious: we need to teach all Internet clients how to talk to servers
   on IPv6 addresses, and we need to teach all Internet servers how to
   talk to clients on IPv6 addresses.
   
Status of IPv6

   There are two parts to the IPv6 project. One part, which is fairly
   satisfactory though not completely settled, is a picture of how the
   Internet will look when everyone is using IPv6, after IPv4 has been
   thrown away.
   
   The other part, which is an incoherent mess, is a set of proposed
   transition plans from IPv4 to IPv6.
   
   Most of the transition plans are a waste of time, because they do not
   contribute to reaching the magic moment. For example:
     * Some transition plans merely replace IPv4 with IPv6 as a mechanism
       for computers that aren't on the Internet to talk to their local
       proxies. Wake up, folks: that isn't the problem we need to solve.
     * Some transition plans focus on building optional connections from
       the IPv4 Internet to a big new IPv6 network. (If you see
       discussion of how ``IPv6-only'' computers might talk to
       ``IPv4-only'' computers, you're looking at one of these plans.)
       Wake up, folks: we need every computer on the Internet to talk to
       the IPv6 network.
       
   There are a few transition plans that take helpful steps, but they
   typically declare success (``IPv6 support'') when the real problem
   still hasn't been solved. They require the system administrator to
   take extra time to have the computer actually talk to the IPv6
   network: running special network-configuration programs, providing
   extra configuration for various servers, setting up AAAA records, etc.
   
   Wake up, folks: before the magic moment, no sane site will rely on the
   IPv6 network, so talking to the IPv6 network won't provide any
   benefits. Unless it happens automatically, as part of regular
   software/hardware upgrades, most administrators simply aren't going to
   bother.
   
   I'm not going to waste time implementing half-baked transition plans.
   I want to see a plan that, if implemented and universally deployed,
   will produce the magic moment.
   
Making servers reachable

   Let's say an IPv6 client wants to reach a server running on the IPv4
   address 131.193.178.181. The IPv6 client might have obtained the
   address 131.193.178.181 from an A lookup in DNS, or from another
   protocol. (We don't want to pester the DNS administrator, and we don't
   control the other protocols, so we don't have any way to provide more
   information to the client.)
   
   The IPv6 client makes an IPv6 connection. What IPv6 address does it
   connect to? Everyone has to agree on an embedding of IPv4 address
   space into IPv6 address space: in particular, an IPv6 address for
   131.193.178.181.
   
   The leading candidate appears to be 6to4, described in RFC 3056.
   Unfortunately, 6to4 doesn't specify a single IPv6 address for each
   IPv4 address; it assigns a whole set of IPv6 addresses to each IPv4
   address. For example, 131.193.178.181, which is 83c1b2b5 in
   hexadecimal, is assigned all IPv6 addresses beginning with
   200283c1b2b5. Which address do we use?
   
   One of the RFC 3056 authors has suggested putting 1 on the end of the
   address: 200283c1b2b500000000000000000001. Fine: let's use that. (The
   RFC 2893 embedding would have worked too. What's important is to
   settle on a single global system.)
   
   The IPv6 client makes an IPv6 connection to
   200283c1b2b500000000000000000001. Of course, the server has to be
   listening on that address:
     * The operating system, having been told to accept packets for
       131.193.178.181, has to automatically accept packets for
       200283c1b2b500000000000000000001.
     * The operating system has to automatically handle IPv6 routing. RFC
       3056 explains how a 6to4 host can contact the rest of the IPv6
       network with no host configuration.
     * The server program, having been told to accept connections to
       131.193.178.181, has to automatically accept connections to
       200283c1b2b500000000000000000001 too.
       
   It would be convenient for the programmer at this point if a single
   socket bound to the IPv6 address 200283c1b2b500000000000000000001
   would also automatically accept connections to the IPv4 address
   131.193.178.181.
   
Making clients reachable

   Let's say a client on 131.193.178.181 wants to reach an IPv6 server.
   
   Whatever protocol the client uses to obtain the server address needs
   to be extended to handle IPv6 addresses. If the client does DNS
   lookups, for example, then it needs to try an AAAA lookup when its
   usual A lookup fails. (Some clients waste time by trying AAAA before
   A. Of course, a 16-byte option for A would have been eliminated this
   issue.)
   
   Once the client has the IPv6 address, it takes advantage of the
   automatic 6to4 configuration described above.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Mar 2002 15:20:36 +0100

>    IPv4 address; 

It's not unfortunate at all; you don't seem to understand the purpose of 6to4,
which is to provide an IPv6 site with an IPv6 prefix derived from the site's
border router's IPv4 address. Once this prefix is assigned, normal IPv6
address assignment mechanisms apply to all IPv6 hosts inside that site. 

Also, 6to4 isn't the leading candidate - it's one of several, and the principal
mechanism for initial rollout is more likely to be configured tunnels using
registry-allocated IPv6 prefixes.

  Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 18 Mar 2002 16:34:58 +0200 (EET)

>   will produce the magic moment.

You seem to assume that a single, Grand Unified Plan, would suit
everybody's needs.  I don't think that's a reasonable assumption.

>    space into IPv6 address space: in particular, an IPv6 address for

You seem to make an assumptions that every IPv4 node in the DNS would be
upgraded to IPv6, blindly decapsulate tunneled packets from everywhere, be
configured in identical topology with IPv4, have its applications ported
and provide the same services over IPv6.

All of these can be, more or less, assumed in limited scenarios, but on
the scale of the Internet, definitely not.

-- 
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: "Jeroen Massar" <[email-masked]>
Date: Mon, 18 Mar 2002 15:36:03 +0100

Dear mr Bernstein,

transition.

Let's do this story again...
Really isn't anything like it actually is; you are missing A LOT of
information there.

Check for a nice kiddo picture:
http://unfix.org/projects/ipv6/IPv6andIPv4.gif
(This one is missing Shipworm/Teredo though)

6to4 is for a host with an IPv6 stack, nothing ipv4-only there...
If you want to connect a IPv4 only host to an IPv6 only host it's either
nogo or:

Requiring only a IPv4 stack brings us to ::ffff:<ipv4> as seen from the
IPv6 world (and not the 2002:: 6to4 space you mentioned in your
document) <--- and no way are you going to connect those to IPv6 from
that IPv4 only host, there is no way one is going to fit 128bits in
32bits etc... it needs software/hardware support.
UNLESS you are using something like NAT-PT or socks (see picture)

requiring IPv6 stack (so you are doing IPv6 but over a tunnel or
something):
 - 6in4, the normal situation for people without native IPv6 as used by
many tunnelbrokers
(http://dmoz.org/Computers/Internet/Protocols/IP/IPng/IPv6_Access_Provid
ers/)
 - 6to4, this uses the 2002:<ipv4>: addies,
http://www.kfu.com/~nsayer/6to4/ reads:
8<------
6to4 uses a special IPv6 prefix: 2002::/16. The IANA has set aside this
address space just for 6to4. The 6to4 specification states that the 32
bits after 2002::/16 are the IPv4 address of the gateway machine for the
network in question. This is how the packets know to find their way to
your network -- the IPv4 address of your gateway is right in them! For
example, if your gateway machine's IPv4 address is 192.168.2.199 (it
obviously wouldn't be since that address is unroutable, but just for
example), your IPv6 prefix would be 2002:c0a8:2c7::/48. Inside of that
space, you have 80 bits of address space to do with as you please.
Normally each subnet gets a 2^64 netmask, so that leaves 16 bits of
site-local network addressing -- or 65,536 subnets.
------>8
 - Shipworm/Teredo, this will be using 2003::/16 if all goes well
(http://www.6bone.net/ngtrans/ngtrans_project-status.html#SHIPWORM)

The *real* big problem of when IPv6 breaking through is the fact that
there is limited support for native IPv6, eg through dailup/cable/adsl
ISP's.
When this starts to happen (and personally I hope quite soon ;) then
everything will move over to IPv6, for one thing the average enduser
doesn't
have a clue wether he/she/it/* is using IPv4 or IPv6, as WinXP for
example has builtin support (ipv6 install; done) for IPv6, most Linux
distro's support IPv6
and the majority of other OS's have support for it too, it's all only a
matter of time. The applications should be ready though, that's where
all the programmers
come in, and the hordes of patch suppliers. Now only the vendors should
support these patches and take them into their mainstream product and
all will be well.

Some people are already happily playing Quake 1 and 2 thanks to the
Viagenie guys&gals, and many common things like apache,sendmail,postfix
and the likes are also already ported long times ago... it's just a
matter of time before the endusers transparently move on to IPv6 ;)
It won't happen in a single day but one day it will be there.

Hope this clears some things up again...

Greets,
 Jeroen

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Mar 2002 22:26:18 -0000

Pekka Savola writes:
> everybody's needs.

I'm saying that certain things are _required_ before the Internet can
escape the IPv4 address crunch. I explained the reasons for those
requirements in detail. It's really not that complicated.

Evidently you disagree with one of the requirements. Please identify the
first paragraph on my web page with which you disagree, and explain what
flaw you see in the reasoning.

> You seem to make an assumptions that every IPv4 node in the DNS would
> be upgraded to IPv6,

I spent three paragraphs explaining why having IPv6 software everywhere
is a _requirement_ for escaping the IPv4 address crunch.

> blindly decapsulate tunneled packets from everywhere,

I explained why automatically receiving IPv6 packets to an address based
on the IPv4 address is a _requirement_ for escaping the IPv4 address
crunch. It isn't ``blind''; packets for other IPv6 addresses will be
discarded by default.

> be configured in identical topology with IPv4,

I'm not sure what you're complaining about. Ignoring the Internet is not
a recipe for success.

> have its applications ported

I explained why automatically providing services to IPv6 clients is a
_requirement_ for escaping the IPv4 address crunch.

You assert that setting up an IPv6 service for every IPv4 service won't
work on ``the scale of the Internet.'' I don't believe you.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Mar 2002 22:40:04 -0000

Jeroen Massar writes:
> If you want to connect a IPv4 only host to an IPv6 only host

I don't. Every computer on the Internet needs IPv6 software.

> for one thing the average enduser doesn't
> have a clue wether he/she/it/* is using IPv4 or IPv6,

Stop thinking about how you talk to your local proxies. That's a minor
local issue. I don't care whether you use 10.*, IPv6, or tin cans.

Start thinking about how your local proxies talk to www.google.com and a
million other servers. The current situation is that your local proxies
need IPv4 addresses. I want to fix that.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Mar 2002 23:11:22 -0000

Brian E Carpenter writes:
> you don't seem to understand the purpose of 6to4, which is to provide
> an IPv6 site with an IPv6 prefix derived from the site's border
> router's IPv4 address.

Please explain how a typical server program will figure out ``the site's
border router's IPv4 address'' without pestering the host administrator.

Then explain how an IPv6 client program, trying to reach that server
from another site, will figure out that information without pestering
the DNS administrator.

Then explain exactly what advantage this has over using the host's own
IPv4 address, which is readily available to both programs.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 00:16:42 +0100

In your previous mail you wrote:

=> here are my comments. I agree on some points but not all...
   
   The IPv4 address crunch

=> even this is not very politically correct I agree.

   The magic moment

=> I am afraid the problem is more complex: the basic idea behind
transition is to add on most (then all) new nodes support for both
IPv4 and IPv6 (aka dual stack) so one day the number of IPv4+IPv6
nodes will be greater than the number of (old) IPv4-only nodes.
This will be the magic moment but it should take many years and
we have to consider the possibility than IPv4 routable addresses
become unaffordable before this magic moment...

   Status of IPv6

=> this is not an incoherent mess: the roadmap is still to be finished
so you go from dead-ends to swaps.

=> IPv6 has some other merits than larger address space.

=> we need this IPv6-only to IPv4-only because we'll likely run out
of IPv4 addresses before IPv6 will enough deployed.

=> if this is necessary we are dead because we have no magic way to
change all the Internet nodes and/or applications, even in some years.

=> I agree that running a dual stack is more complex than running IPv4
only but you have to take the NAT complexity into account if you have
no old class A or B. So the issue is only for folks which have used
the Internet for 10 years or more.

=> I agree but as IPv4 addresses are less and less affordable IPv6 will
happen. The question is the transition will be smooth or not.
Unfortunately this is not really a technical matter.
      
   Making servers reachable

=> 6to4 is not for this purpose...

IMHO the solution is with a new version of NAT-PT (the idea is from
Alain Durand who showed that in the current NAT-PT the DNS stuff doesn't
work well). The argument is a NAT-PT is not really worse than a
traditional NAT when the DNS translation madness has been removed.
And the purpose is (again) to get (new) IPv6-only clients speaking to
(old) IPv4-only servers without trouble (i.e. no more than today with
NATs).
Unfortunately this new mechanism has to be written down (implementation
should be easy because it only removed nasty DNS translation code from
current NAT-PTs). Perhaps it will be presented today at the NGtrans
session?

Regards

[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Mar 2002 18:23:00 -0500

> is a _requirement_ for escaping the IPv4 address crunch.

So all you have to do is to get everbody to read your web page, and
then they'll be convinced that they need to upgrade their software
immediately, at which point most of this WG's work will be irrelevant.

I'm sure most of us wish you luck in this endeavor.  But most of us
are assuming that there will necessarily be a significant transition 
period during with both v4 and v6 are used, and not everyone realizes
the benefit of upgrading to v6 or has the option of upgrading to it

If we knew how to convince everybody to upgrade their software to 
support v6 quickly, we wouldn't be spending so much effort trying 
to work out transition mechanisms.  But if you know a way to do this 
that we don't - go for it.  We'd love to find out that we were wrong 
on this one.

Keith

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 00:28:31 +0100

=> magic moment or magic wand (:-)? Please be serious, there is no way
to enforce IPv6 everywhere other than to make IPv4 unavailable and
to break the Internet.

   
=> I disagree: if you use IPv6 one day you'll be able to use it
end-to-end with everybody, not only with your local proxies.

=> IMHO the problem is the local proxy, not the fact it needs an IPv4
address. The Internet was designed to be end-to-end/peer-to-peer and
middle boxes (NATs, local/transparent proxies, and other abominations)
are the enemy.

Regards

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Mar 2002 01:59:21 -0000

Keith Moore writes:
> But most of us are assuming that there will necessarily be a
> significant transition period during with both v4 and v6 are used,

Keith, there is _one_ network that has aol.com and cnn.com and
cs.utk.edu and an incredible number of other sites.

Normal people call this network ``the Internet.'' They insist on being
connected to the Internet, so that they can exchange email and web pages
and so on with other Internet sites.

The universe you're imagining, in which sites are split across two
global networks that have trouble talking to each other, is an ancient
historical mistake that will never be repeated. What kind of idiot would
be the first to disconnect his site from the original Internet in favor
of the new Internet? Why haven't you cut yourself off from IPv4, Keith?

If you want IPv6 to succeed as a global network, you have to figure out
how to make an IPv6 address just as useful as an IPv4 address. How do
you plan to do that, Keith?

The way to make IPv6 addresses work is to teach every Internet computer
how to talk to IPv6 addresses---not just as an option that the sysadmin
might configure, but as something that's automatically enabled as part
of regular software/hardware upgrades.

Will this be done overnight? Of course not. But it is the crux of the
IPv6 transition. I remain astonished that this WG didn't settle the
details years ago.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Mar 2002 02:15:10 -0000

Francis Dupont writes:
> IMHO the problem is the local proxy, not the fact it needs an IPv4
> address.

The fact that the site needs an IPv4 address to browse the web, receive
email, etc. is _precisely_ the problem. How do you propose fixing this
problem? Eliminating proxies doesn't help.

For example, my computer distributed mailing-list messages to thousands
of sites today. If it had been stuck with an IPv6 address rather than an
IPv4 address, it wouldn't have been able to reach any of the relevant
SMTP servers. How do you propose fixing this problem?

The IPv6 transition needs credible answers to these questions.

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Mar 2002 21:34:02 -0500

> border router's IPv4 address'' without pestering the host administrator.

it doesn't need to, because applications aren't involved in 6to4 setup.
the applications just see that their host has some set of interfaces -
v4 and/or v6.  as far as apps are concerned, v6 interfaces that happen 
to use 6to4 prefixes act just like other v6 interfaces.
 
> from another site, will figure out that information without pestering

the v6 client just does a DNS lookup for the servers it wants to reach.
zero or more AAAA records will be returned.  some subset of those records
(perhaps a null set) will have 2002: prefixes.  the client picks 
which of those address(es) it wants to use.  (see the source address 
selection document for the default algorithm)

Keith

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 03:42:38 +0100

=> I still believe you reverse the cause and the effect.

   >Most people agree, however, that proxies merely delay the inevitable.

So what you'd like is an address per computer, and to get rid of
local proxies as "address savers". Same for NATs...
The shame is not you need a routable address per proxy, it is first you
need proxies!
So the long term goal should be to return to the original Internet
model, as described in RFC 2775 by Brian Carpenter.

=> by changing the IP version from 4 to 6.

=> as we disagree about the cause and the effect, we disagree about
the goal and the mean.
Basically the NGtrans WG idea is to find all reasonable ways to help
IPv6 deployment, including any replacement of NATs (which are the
current solution in the IPv4 Internet) using IPv6 locally. So
the IPv6-only client to IPv4-only server case is considered as
important as the client to server case (of course the Internet is more,
or was more and should be more).

Regards

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Mar 2002 02:44:14 -0000

Francis Dupont writes:
> so one day the number of IPv4+IPv6 nodes will be greater than the
> number of (old) IPv4-only nodes. This will be the magic moment

No. 50% isn't good enough. People are not going to be satisfied with an
IPv6 address that can talk to only half the Internet.

Do you think that having all IPv4 addresses assigned---having to pay for
aftermarket IPv4 addresses; being forced to squeeze more and more out of
each IPv4 address---is going to make people suddenly say ``Well, okay, I
guess half the Internet is good enough''? Wake up!

Note that the 50% I'm talking about is the percentage of machines that
actually _talk_ to IPv6 addresses, not just the percentage of machines
that have ``IPv6 support.'' I bet that all of Google's web servers are
running Linux versions with ``IPv6 support,'' for example, but they
haven't actually been configured to accept IPv6 packets.

> if this is necessary we are dead because we have no magic way to

Further delay certainly doesn't help! Why hasn't ngtrans standardized an
embedding of IPv4 address space into IPv6 address space?

> IMHO the solution is with a new version of NAT-PT

NAT-PT is irrelevant. It doesn't change the fundamental fact that, to
talk to Google and practically every other site, I need IPv4 access.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 04:10:56 +0100

> number of (old) IPv4-only nodes. This will be the magic moment
   
   No. 50% isn't good enough.

=> I disagree, 50% is the good point. With less than 50% we are the loosers,
with more than 50% they are the loosers. The only problem is to reach 50%
but the IPv4 total number can't grow very high and the IPv6 total number
has no limit so this will happen one day.

   People are not going to be satisfied with an
   IPv6 address that can talk to only half the Internet.
   
=> this is why we need transition mechanisms, both for situations
like today (0.epsilon %) and for situations where IPv4 will become rare.

=> you assume they'll have a choice... BTW today most of the folks with
"access to the Internet" have only a very small part of possible Internet
applications, just because they use NATs/local proxies.

   Note that the 50% I'm talking about is the percentage of machines that
   actually _talk_ to IPv6 addresses, not just the percentage of machines
   that have ``IPv6 support.''

=> we agree.

   I bet that all of Google's web servers are
   running Linux versions with ``IPv6 support,'' for example, but they
   haven't actually been configured to accept IPv6 packets.
   
=> if you know how to change this, please do it!

   Why hasn't ngtrans standardized an
   embedding of IPv4 address space into IPv6 address space?
   
=> this was standardized by the IPng (IPv6 today) WG from the
beginning and is a key point in the dual stack API.

   
=> our new NAT-PT is NAT with IPv6 for the local network. This doesn't
change the need of IPv4 access but enables the real Internet for the
IPv6 part.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Mar 2002 06:36:08 +0200 (EET)

Francis and Keith are already doing a good job, so I don't bother to 
answer to the issues.

> Pekka Savola writes:
[snip]
> I'm not sure what you're complaining about. Ignoring the Internet is not

Ignoring people who know better is not a recipe for success either.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Mar 2002 05:19:14 -0000

Francis Dupont writes:
> With less than 50% we are the loosers,
> with more than 50% they are the loosers.

No! Here's the picture:

            percentage of the Internet  percentage of the Internet
   time         reachable through IPv4      reachable through IPv6
 
      0                            100                           0
      1                            100                          10
      2                            100                          40
      3                            100                          80
      4 (the magic moment)         100                         100
      5                            100                         100
      6                            100                         100
      7                             80                         100
      8                             60                         100
      9                             40                         100

Look at time 3, for example, when 100% of the Internet can talk to an
IPv4 address and 80% of the Internet can talk to an IPv6 address. IPv6
addresses are still less useful than IPv4 addresses at that point. Your
comparison of 80% to 20% is nonsense.

Notice that there is, at every moment, a 100% column. This is not an
accident. There is _one_ Internet. Everybody can talk to everybody else.
The IPv4 column will not drop until the IPv6 column reaches 100%.

It is a waste of time to consider situations such as 60% IPv4, 60% IPv6.
Those situations are never going to happen.

> if you know how to change this, please do it!

What do you think my web page is aimed at? Manual IPv6 configuration is
too much of a pain for most people to actually use. I want a transition
plan that, when followed by all software on an IPv4 computer, makes that
computer just as easy to reach through IPv6 as through IPv4, with _no_
extra host configuration and _no_ extra DNS configuration.

If ngtrans creates a coherent AutoIPv6 transition plan, I'll adopt it
for my software, and I expect that other implementors will do the same.
On the other hand, if ngtrans keeps focusing on FantasyUniverseIPv6 and
PrivateIPv6, then the magic moment will obviously never happen.

> this was standardized by the IPng (IPv6 today) WG from the

The API is a side issue. The IPv6 addresses have to _work_! They have to
be functionally identical to the IPv4 addresses, plus the extra feature
of being able to talk to new IPv6 addresses.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Mar 2002 05:36:40 -0000

Keith Moore writes:
> applications aren't involved in 6to4 setup

I said ``without pestering the host administrator.'' I take it that you
don't have an answer?

> zero or more AAAA records

I said ``without pestering the DNS administrator.'' I take it that you
don't have an answer?

You also ignored my third question. What advantage does this have over
using the host's IPv4 address?

---

From: Brian Haberman <[email-masked]>
Date: Tue, 19 Mar 2002 08:04:47 -0500

> border router's IPv4 address'' without pestering the host administrator.

It doesn't have to.  The IPv6 prefix derived from the IPv4 address
will be used in an IPv6 address found in DNS.  The basis of 6to4 is
to support IPv6 sites communicating over the IPv4 infrastructure.

> from another site, will figure out that information without pestering

The client program:
     1. performs a name lookup
     2. gets a AAAA record back
     3. sends a request to that address
     4. ...

The site border router controls when the v6 data packet sent by the
client gets encapsulated in an IPv4 header.

> IPv4 address, which is readily available to both programs.

Who ever said the host has an IPv4 address?

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 19 Mar 2002 08:57:11 -0500

>you plan to do that, Keith?

This is, in part, the role of the ngtrans WG.  We are 
developing tools and techniques that are intended to 
prevent the balkanization of the Internet when some 
hosts are using IPv4-only, some are dual stack, and
some are using IPv6-only.

*Magic* moments don't just happen.  They are brought
about by careful planning and hard work.

We know that we haven't solved all of the problems in 
this area, and we welcome your input to identify and
solve the remaining problems.  

Over the next several months, we will be exploring 
transition scenarios and working on an overall 
architecture for IPv6 transition.

We expect that many of the individual transition 
tools that we have developed will have important 
places in that architecture, and our experience with 
these tools has helped us to understand the types of 
problems that need to be solved, and some options for 
solving them.  But we agree that a grab-bag of transition 
tools is not sufficient to bring about an organized and 
effective IPv6 transition.

>of regular software/hardware upgrades.

Not all IP nodes are subject to "regular" software/
hardware upgrades.  

Even when nodes are upgradeable, end users are constrained 
by what their software/hardware providers choose to supply
to them.  It is not realistic to believe that all software
and/or hardware providers will make IPv6 available at the
same time.

So, we are assuming a long time period during which IPv4-only,
dual stack and IPv6-only nodes will coexist on _the_ Internet
(not two Internets -- one Internet simultaneously supporting
two different versions of the Internet Protocol).

>IPv6 transition. I remain astonished that this WG didn't settle the

History aside, there is no time like the present...

You have mentioned a goal state of having all Internet nodes
"talk to IPv6 addresses".  Do you have a concrete proposal 
for how we can reach that point?

Margaret

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 17:19:00 +0100

No! Here's the picture:

         0                            100                           0

=> you have to define reachable first because today only 5% of
the Internet is reachable. So I assume percentages are relative
to the reachable part of the Internet.

=> this assumes IPv4 addresses shall stay affordable for many years.

   Look at time 3, for example, when 100% of the Internet can talk to an
   IPv4 address and 80% of the Internet can talk to an IPv6 address.

=> note this is *not* the common definition of "reachable".

=> The last statement is definitely false.

   What do you think my web page is aimed at? Manual IPv6 configuration is
   too much of a pain for most people to actually use.

=> IPv6 host configuration can be stateless (in fact today is nearly 100%
stateless) so the only thing to do for this side is to enable IPv6 is
it is not (so the default should be to enable IPv6, it seems we agree
about this point).

   I want a transition
   
=> DNS configuration is another problem. Dynamic update should help us
(cf. the current experiment at the IETF meeting). I have a concern about
dynamic updates but the NGtrans WG mailing list is not the good place.

=> our local "credo" at ENST Bretagne is that IPv6 is not a new protocol,
it is a new version of the IP protocol. Join us?

Regards

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Mar 2002 12:26:02 -0500

> embedding of IPv4 address space into IPv6 address space?

because it wouldn't provide a way to allow IPv4 hosts to reach IPv6 hosts.

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Mar 2002 12:28:01 -0500

> What advantage does this have over using the host's IPv4 address?

the host doesn't have an IPv4 address.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 07:30:31 -0000

> Who ever said the host has an IPv4 address?

My users. For example, the operators of nearly a million publicly
reachable IPv4 addresses running my SMTP server.

Let me try to phrase the problem differently:

   (1) I'd like to connect my office computers to the IPv6 network, and
       make their services---the web server, for example, and the mail
       server---available to IPv6 clients around the world.

   (2) I control the operating system and the applications. I am ready
       and willing to make various changes to the code.

   (3) However, I refuse to provide _any_ information to those programs
       beyond what they already have (such as my IPv4 addresses), and I
       refuse to do any work outside changing the programs themselves.
       I'm not going to ask my ISP for an IPv6 address, for example, and
       I'm not going to touch my DNS data.

Here's the big question: How do I achieve #1, taking advantage of #2,
without violating #3?

You might think that #2 and #3 are strange. Why am I willing to write
code, maybe quite a bit of code, but not willing to send a message to my
ISP and make some trivial configuration changes? Isn't this backwards?

The answer is that I'm actually talking about a huge number of IPv4
sites. There's nothing special about my site. When the same situation is
repeated at N sites, the code is written only once, while the trivial
requests and the trivial configuration changes are repeated N times.

I see no reason that my users should have to suffer the costs of manual
configuration. On behalf of my users, I object to all IPv6 transition
plans that impose such costs.

Maybe you've put so much time into IPv6 that you don't care about the
five minutes you spent acquiring a connection and configuring software.
``Look how easy it was,'' you say.

Well, I'm looking at a much larger group of users, and most of them
aren't putting even five seconds into IPv6. They have better things to
do. If the IPv6 configuration isn't automatic, it won't happen.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 08:41:44 -0000

Francis Dupont writes:
> IPv6 host configuration can be stateless (in fact today is nearly
> 100% stateless)

``Nearly'' won't be deployed. ``Can be'' won't be deployed. And I bet
that your notion of ``stateless'' includes sending your Ethernet address
to your master DNS server---but the simple fact is that most computers
today don't know their master DNS server addresses. That, too, won't be
deployed.

Why do people insist on pestering the DNS server administrator? It's a
layering violation for the IPv4-in-IPv6 embedding to depend on DNS.

> you have to define reachable first because today only 5% of
> the Internet is reachable.

Sorry. I thought it was obvious that percentages were weighted by user
desires. For example, practically every site wants to, and can, connect
to www.google.com. Connections the other way would often be prevented by
firewalls, but that doesn't count against reachability, because Google
doesn't want to make connections the other way.

As a percentage of all sites, Google is very small. As a percentage of
user desires, Google is much larger. If you had 99.99% of the Internet,
but not Google, talking to IPv6 addresses, then people would still
insist on IPv4 addresses.

> The last statement is definitely false.

Someone who sets up a firewall _can_ talk to you but doesn't _want_ to.
There's a difference.

You can restrict attention to public DNS/HTTP/SMTP servers if you like.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 11:13:55 -0000

> for how we can reach that point?

Outline:

   (1) Each IPv4 address is globally assigned an IPv6 address by some
       simple rule. Let's call this the AutoIPv6 address for the IPv4
       address. The overall objective is to make the AutoIPv6 address
       functionally identical to the IPv4 address, plus the extra
       feature of talking to native IPv6 addresses.

   (2) Network stacks add AutoIPv6 support. This means a little more
       than dual-stack: when the stack is given a local IPv4 address for
       incoming and outgoing packets, it also automatically sets up the
       corresponding AutoIPv6 address.

   (3) Servers add AutoIPv6 support. This means a little more than IPv6
       support: when the server is told to listen to a particular IPv4
       address, it also listens to the corresponding AutoIPv6 address.

   (4) Clients add AutoIPv6 support. This means a little more than IPv6
       support: if the client tries to connect to an IPv4 address but is
       told that the network is unreachable, it instead tries an IPv6
       connection to the corresponding AutoIPv6 address.

Similar comments apply to other network components. For example,
AutoIPv6 firewalls that allow IPv4 packets to an IPv4 address will also
start allowing IPv6 packets to the corresponding AutoIPv6 address.

All of the features of this outline follow from requirements implicit in
the problem, as discussed in http://cr.yp.to/proto/ipv6.html. Most
importantly, we can't pester the DNS administrator; so future clients on
IPv6 addresses will have only the server's IPv4 address; so the AutoIPv6
address has to be determined entirely by the IPv4 address.

Details: RFC 3056 and RFC 3068 appear to provide an adequate base for
AutoIPv6. The AutoIPv6 address can be ``stick 2002 in front and 1 on the
end.'' Routing to the native IPv6 network can be handled by 192.88.99.1.
Of course, there will have to be enough 6to4 relay routers to handle the
eventual traffic to native IPv6 sites, but RFC 3068 already contemplates
that.

I get the feeling that the 6to4 people are scared of having hundreds of
millions of 6to4 sites, even though they say they're not scared of ten
million. Is there any justification for drawing this line?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 16:06:10 +0200 (EET)

>        connection to the corresponding AutoIPv6 address.

You didn't describe the hard parts.

How are you going to deploy your "No need to change DNS" 
model incrementally?

There will be no flag days...

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 20 Mar 2002 09:27:06 -0500

Your plan ignores the issue of routing the "AutoIPv6" addresses over
an IPv6 infrastructure to your IPv6 host.  This is the most difficult
part of making this type of system work, and results in the tunnels
and server-based solutions that you object to...  These mechanisms
will be needed, however, until IPv6 addresses are globally routable.

The needs of a home or small enterprise that is transitioning from
IPv4 to IPv6 is one of the scenarios that we will be exploring to
determine the applicability of our current transition toolkit.  But,
I think ti will go something like this.

Current thinking by some is that the core can be converted to support
IPv4 and IPv6 simultaneously, and that many major ISPs have this
conversion underway.  If/when this happens, the router at the end of
your PPP link (for example) will be an IPv4/IPv6 router and will
send router advertisements that can be used by your host to autoconfig
a globally-routable IPv6 address.  All you will need to do is 
configure the software, IPv6 autoconfiguration (or DHCPv6, if that
is what your ISP prefers) will do the rest...

So, assuming that your host already had a valid IPv4 configuration
(with either globally routed or NATed addresses) and a dual-mode
IPv4/IPv6 stack, you will also have a valid, globally routable
IPv6 configuration.

Now we get to the harder part -- how does the host choose whether to 
use IPv4 or IPv6 to communicate to other nodes?  This will require your
DNS server (which may also be provided by your ISP) to return IPv4
addresses for IPv4-only hosts and IPv6-addresses for IPv6-only
hosts.  IPv4/v6 hosts may have both types of addresses, and you
can choose what you prefer.  You may actually prefer IPv6 at
this point to IPv4/v6 servers, especially if your IPv4 traffic is
traversing a NAT.  Voila!  One Internet, two versions of IP,
global connectivity.

At this point, if you are behind an IPv4 NAT box anyway, you may 
choose to stop configuring IPv4 on new hosts.  Since you are already 
behind a NAT for IPv4 (with all that entails), you would not see any
degradation in service by running an IPv6-only host and using NAT-PT
to talk to IPv4-only servers.  You would have to set-up a NAT-PT
box, but this would be a fairly simple software upgrade to the
box that is already running your NAT.  So, why go to the bother of 
configuring IPv4 on all of your new computers?  :-)

All of this waits, though, until your ISP provides globally routable
IPv4 and IPv6 connectivity.  Is there a reason why you would want
to use IPv6 in a home or small enterprise before globally routable
IPv6 is available?  Maybe for autoconfiguration, but so far that 
hasn't proven to be compelling...

Margaret

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Mar 2002 09:42:27 -0500

> do. If the IPv6 configuration isn't automatic, it won't happen.

well, if you control the OS then presumably you can make the OS 
automatically configure IPv6.  the technology exists - just enable
IPv6 router discovery on all interfaces, and enable 6to4 if none 
of the interfaces find a v6 default route.

(this assumes the host has native v4 connectivity, isn't behind
a NAT, etc.  but folks are working on shipworm/teredo to handle
the latter case.)

however, I don't know of any way to put the AAAA records for that
host into DNS without doing *some* additional configurartion
for that host - either on the host, or on some kind of server 
(to associate an fqdn with the host's MAC address) or both.

and given the large numbers of sites that (unfortunately) run
insecure operating systems and rely on firewalls to protect
their insecure hosts from network attacks.  if OSes shipped
with IPv6 enabled by default this would open numerous security 
holes that the firewall isn't equipped to deal with.  

bottom line is I don't see any way to escape having some per-host 
configuration required to enable IPv6.  it's not because of a lack 
of mechanisms in IPv6 but because security demands some amount of 
per-host configuration no matter what layer 3 looks like. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Mar 2002 09:48:15 -0500

> eventual traffic to native IPv6 sites, but RFC 3068 already contemplates

but if the client already had a working v4 address for the server, 
why would it try using the derived v6 address?  it's less likely
to work, and if it does work, it's certain to be less efficient.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 15:06:16 -0000

Margaret Wasserman writes:
> an IPv6 infrastructure to your IPv6 host.

As I said: ``Routing to the native IPv6 network can be handled by
192.88.99.1.''

As far as I can see, I'm following every rule in RFC 3056 and RFC 3068.
If something goes wrong with routing for these specific addresses then
there's a bug in 6to4.

I realize that the 6to4 authors didn't expect every host on the Internet
to call itself a separate IPv6 site. So what?

> conversion underway.

There are three levels of routers between my machines and UIC's ISP. The
router administrators don't care about IPv6; they have real work to do.

Furthermore, even if I could obtain an IPv6 address this way, that
obviously wouldn't suffice to let an IPv6 client make a connection to my
servers. I wish people would stop giving me ``solutions'' that clearly
don't answer the question I asked.

> use IPv4 or IPv6 to communicate to other nodes?

With AutoIPv6, this decision becomes trivial. If you're connecting to an
IPv6 address, use IPv6. If you're connecting to an IPv4 address, try
IPv4 to that address; if the network is unreachable, try IPv6 to the
corresponding AutoIPv6 address.

> IPv4 addresses for IPv4-only hosts and IPv6-addresses for IPv6-only hosts

That universe is never going to happen. Considering it is a waste of
time. Right now, 100% of sites are reachable through IPv4; this is not
going to change until 100% of sites are reachable through IPv6.

> At this point, if you are behind an IPv4 NAT box anyway,

I really don't give a damn about the protocol for non-Internet computers
to talk to their local proxies. IPv4 with 10.*; IPv6; whatever. It's a
distraction from the real problem of making IPv6 work globally.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 15:26:00 -0000

Keith Moore writes:
> for that host

Fortunately, with an IPv6 address determined entirely by the IPv4
address, these AAAA records are unnecessary.

That's the starting point for AutoIPv6: we can't pester the DNS
administrator, so we have to use the available information, which for
typical clients means the existing A record.

> holes that the firewall isn't equipped to deal with.  

Standard firewall configurations drop unrecognized protocols. An
AutoIPv6 firewall has to start _allowing_ IPv6 packets (tunneled through
IPv4) to the same addresses where IPv4 packets would be allowed.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 20 Mar 2002 10:37:23 -0500

It sounds like you have a proposal "AutoIPv6" that you believe
will solve some problems inherent in existing ngtrans
transition mechanisms.  

I encourage you to document this proposal as an Internet-Draft, 
so that we can have an informed discussion regarding its features 
and applicability.

Margaret

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 16:02:46 -0000

Keith Moore writes:
> why would it try using the derived v6 address?

The answer to your question, obviously, is that the client doesn't have
an IPv4 address. IPv6 is the only option.

Why doesn't the client have an IPv4 address? Because the objective under
discussion is to make all these servers---for example, all the SMTP
servers that I mentioned---reachable from such clients.

Why is that the objective? Because, if those servers _don't_ become
reachable, then IPv6 addresses will remain second-class citizens, and
sites will continue to demand IPv4 addresses.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 17:10:03 -0000

Margaret Wasserman writes:
> I encourage you to document this proposal

http://cr.yp.to/proto/ipv6.html

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 19:13:46 +0200 (EET)

> http://cr.yp.to/proto/ipv6.html

That 'document' fails to address a few critical aspects e.g. how to 
transition to this mechanism.

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Mar 2002 17:24:24 +0000 (GMT)

> transition to this mechanism.
 
Or security considerations...

tim

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Mar 2002 11:28:40 -0600

> transition to this mechanism.

and, as margaret said, in the ietf, we use internet-drafts

randy

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 20 Mar 2002 09:29:29 -0800

Are you trying to find a way to embed an IPv4 address in a globally routable
IPv6 address at the host level? (i.e., only one IPv6 address per IPv4 address?)
Section 4 of 'draft-ietf-ngtrans-isatap-03.txt' has some language that speaks
to this. ISATAP is an intra-site mechanism that connects IPv6 hosts and routers
within IPv4 sites. It provides a complementary function to 6to4, which inter-
connects IPv6 islands across an IPv4 backbone.

Fred
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Mar 2002 18:30:38 +0100

=> there are two different cases: a host alone and a site/network.

=> I suppose this includes any autoconfiguration tool, doesn't it?

   
=> in some easy cases this can be already done.

=> fortunately IPv6 is far better than IPv4 for automatic configuration.

So we can scan different cases:
 - a host connected to a link where there is IPv6:
   * the stateless autoconf gives the address
   * a dynamic DNS update script (we have one) can handle DNS part
   => solved
 - a host connected to a link where there is no IPv6:
   * the stateless autoconf permits to recognize this case
   * 6to4, etc, gives the address
   * you can be in trouble for the reverse DNS (see Keith's proposal
     for 6to4, some other mechanisms (tunnel broker for instance) are
     better but need some work to become automatic)
   => near solved
 - a "dialup" host connected to an IPv6 ISP:
   * the prefix delegation (in progress, see tomorrow agenda) gives
     the prefix
   * some work (mainly to get security) is needed for the reverse DDNS
   => in progress, should be solved ASAP
 - a "dialup" host connected to an IPv4-only ISP:
   * or use the no-IPv6 link case or change for an IPv6 ISP.
   => not worse than previous cases
 - a (sub)network connected to an IPv4-only ISP:
   * same than for a host but more work can be needed on the router
     which traditionally is not automatically configured (i.e. there
     is a trade-off between good management/security issues and
     automatic configuration)
 - a (sub)network connected to an IPv6 ISP:
   * same than for a dialup host with same considerations than in the
     previous case
 - sites:
   * basically the site case is a network case multiplied by a second
     network case with IPv6 and local management (this will help for
     security issues)

So the results are:
 - NGtrans mechanisms are already there
 - the prefix delegation issue has to be solved for yesterday
 - DDNS must become more usable (especially for security) but
   this is not a real IPv6 issue, i.e. today IPv4 should take
   benefit of a better DDNS (so the DDNS experiment at this IETF
   meeting is a very good idea because it should raise any remaining
   operational problems, including user education and scripting).

Regards

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 18:15:48 -0000

> transition to this mechanism.

This _is_ a transition mechanism. Components can be upgraded to AutoIPv6
in any order. A host where all the components have upgraded to AutoIPv6
becomes reachable from the global IPv6 network.

What other ``critical aspects'' did you have in mind?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 20:29:28 +0200 (EET)

> becomes reachable from the global IPv6 network.

When an IPv4/IPv6 node tries to connect to an IPv4 node, does it always 
try AutoIPv6 first?  Consider the delays..  Remember, during the first 
couple of years, very very small percentage either supports this or has 
the applications IPv6-ready.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Mar 2002 20:01:28 +0100

> IPv6 host configuration can be stateless (in fact today is nearly
   
   ``Nearly'' won't be deployed. ``Can be'' won't be deployed.

=> Blablabal won't be deployed... What is your argument.

   And I bet that your notion of ``stateless''

=> not mine, this is RFC 2462.

   includes sending your Ethernet address

=> your interface ID which *may* be derived from your Ethernet address.

   to your master DNS server

=> this is not included into RFC 2462 but the idea to register an AAAA
and a PTR RRs by a dynamic update script is common.

   ---but the simple fact is that most computers today don't know
   their master DNS server addresses.

=> to find DNS server addresses is another problem which is being
fixed. My concern is more than the DNS server should allow dynamic
update and the security. But this is not an IPv6 problem, you have
it with IPv4 too.

=> I don't understand your second statement, perhaps it is against
some NGtrans mechanisms like NAT-PT?

   
=> I strongly disagree: please don't reduce the Internet to an online
service. One way connectivity is a real concern.

=> so we need a way to make Google IPv6 capable. Have you a concrete
suggession, this could really help!

   
=> my concern is more NATs than firewalls because a firewall can be opened
but a NAT cannot, i.e. with a firewall you can restrict services you
offer, with a NAT you have to wired down mapping rules for anything
from the Internet.

=> I dislike both the terms public and servers in your statement,
the Internet is a network which interconnects computers.
Again, look at RFC 2775...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Mar 2002 20:18:04 +0100

> an IPv6 infrastructure to your IPv6 host.
   
=> I strongly agree with Margaret, the issue is without an IPv6
infrastructure IPv6 addresses are useless (and of course this is 
a chicken and egg problem).

=> BTW this is not true: 6to4 includes this case from the beginning.

   Right now, 100% of sites are reachable through IPv4

=> this is definitely not true. As I've said, you reverse the cause
and the effect, so the goal and the mean.

   I really don't give a damn about the protocol for non-Internet computers
   to talk to their local proxies.

=> this is the real issue: these computers are not non-Internet by choice.

   IPv4 with 10.*; IPv6;

=> IPv4 with 10.* is NAT, IPv6 is Alain's NATv6. Today there is
no difference but the bet is IPv6 will restore the real Internet.

   It's a distraction from the real problem of making IPv6 work globally.
   
=> again we deeply disagree about the cause and the effect...

Regards

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 19:29:02 -0000

Pekka Savola writes:
> When an IPv4/IPv6 node tries to connect to an IPv4 node, does it
> always try AutoIPv6 first?

Of course not. The document quite clearly says ``If it tries making a
connection to an IPv4 address, and is told that the network is
unreachable, it then tries a connection to the corresponding AutoIPv6
address.''

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 19:37:11 -0000

Francis Dupont writes:
> so we need a way to make Google IPv6 capable. Have you a concrete

> to find DNS server addresses is another problem which is being fixed

Only by violating the ``don't pester the administrator'' rules, so it's
not relevant to this discussion.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 21:55:28 +0200 (EET)

> unreachable, it then tries a connection to the corresponding AutoIPv6

Ok, this kinda works if you hack libc, disregard quite a few current 
transition mechanisms and want to live with the mess that ensues from 
user requesting a connection to IPv4 resulting in one to IPv6.

More details would be good.  Preferably in I-D format.

Have you been reading about Jim Fleming's IPv8?  This sounds awfully 
familiar.

I don't see a model like this ever having a "sunset": we'd be in this kind 
of AutoIPv6 addressing (depending on IPv4) pretty much forever.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 20 Mar 2002 11:59:21 -0800

It is good to have someone with a fresh perspective try to figure this

> plans that impose such costs.

I personally agree completely, but transition plans which lack manual
configuration are also a non-starter in the minds of those who *value*
absolute control. We have a suite of approaches for the various
environments people already have in place.

>        I'm not going to touch my DNS data.

Since you could not possibly expect to provide service to an IPv4 node
without interaction with the DNS administrator, this is a bogus claim.
While I agree it would be preferred to avoid any human interaction for
adding IPv6, people still have an aversion to dynamic DNS updates. If
DDNS were pervasive, your requirement of not pestering the administrator
becomes possible, but not absolute avoidance of updating DNS.

> For example, the AutoIPv6 address corresponding to
> 131.193.178.181 is 200283c1b2b500000000000000000001.

The final 1 is unnecessary, as the address 200283c1b2b5:: cooresponds to
'any router' at that prefix. Since the proposed mechanism requires every
node be directly attached, they are also 'THE router', so the anycast
already provides what you are looking for.

> address, these AAAA records are unnecessary.

One issue with assuming that an A record will always map into a 6to4
record would only work if and when all nodes had a global IPv4 address
of their own, and it was identified in a DNS A record. 6to4 as defined
allows many nodes to share a single IPv4 address, and in these cases
your approach would never find the nodes behind the 6to4 router.

There is no requirement of a client to request a AAAA, and this
discussion shows that it would be possible for a client to construct an
IPv6 address from an A record that would work in some/many cases. At the
same time, we know there are nodes that are not directly on the public
IPv4 network, or do not have their address registered in DNS. We need
mechanisms to find those as well, and it would be easier if the approach
was consistent.

> unreachable, it then tries a connection to the corresponding AutoIPv6

Assuming that a node will always try IPv4 first will ensure that IPv6
never gets used. If you are not sure about that, consider that to get
the IPv6 over IPv4 tunneling to work, the node had to have a reachable
IPv4 address. When would a node get told that the address is unreachable
yet would still allow an IPv6 over IPv4 packet to get through?

Tony

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Mar 2002 21:05:39 +0100

=> it then trie a connection using a tunnel using the IPv4 address it
already knows to be not working...

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 22:14:30 +0200 (EET)

> already provides what you are looking for.

Just commenting on a detail.  Not good enough:

 1) subnet-router anycast address isn't really been implemented
 2) can't establish TCP sessions to anycast addresses

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 22:10:57 +0200 (EET)

> already knows to be not working...

True on dual-stack nodes, on IPv6-only nodes (which this proposal really 
doesn't cater), it would kinda work.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Mar 2002 21:16:57 +0100

=> what is the corresponding AutoIPv6 address on an IPv6-only node?

PS: the interface ID ::1 is fine (anycast :: is unusable as a source address).

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 22:20:34 +0200 (EET)

Stripped off DJB from Cc:, because I'm getting bored of deleting his 
anti-spam autoresponder spam.

> => what is the corresponding AutoIPv6 address on an IPv6-only node?

2002:<IPv4>::<IID>  (with multi-link subnet routing)
2002:<IPv4>:<something>::<IID>

Requirement here would be that IPv6-only nodes would be behind AutoIPv6 
and inherit their addresses (like 6to4 hosts which aren't 6to4 routers)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 20:36:54 -0000

Francis Dupont writes:
> it then trie a connection using a tunnel using the IPv4 address it

Presumably it doesn't have an IPv4 address of its own, so trying through
IPv6 is exactly the right strategy.

The whole point is to make existing sites reachable from IPv6 addresses.
Pestering the administrator is unacceptable, so the software on both
sides has to go to a little bit more effort.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 22:49:53 +0200 (EET)

> and inherit their addresses (like 6to4 hosts which aren't 6to4 routers)

This won't solve the problem of <IPv4> becoming unreachable though.

I guess a fallback could be to send everything through an AutoIPv6 relay,
but soon they'd be totally swamped, as it would be quite difficult for an
implementation not to send IPv4-only traffic to them too..

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Mar 2002 15:53:06 -0500

> The whole point is to make existing sites reachable from IPv6 addresses.

indeed that is the point of 6to4.  the only new idea I've seen here
is to use A records as a guess of the v6 address of a host.
it's an interesting idea, and it would work *if* folks could be
convinced to upgrade their existing hosts to support v6 (and if
they're not behind NATs, etc.) 

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 20:54:16 -0000

> without interaction with the DNS administrator, this is a bogus claim.

The DNS administrator and host administrator have set up service on an
IPv4 address. AutoIPv6, as described in http://cr.yp.to/proto/ipv6.html,
makes the same service available automatically on an IPv6 address. What,
precisely, are you asserting is ``bogus''?

> 6to4 as defined allows many nodes to share a single IPv4 address

Right. Such nodes can safely be created after the magic moment. They
will have AAAA records. What's the problem?

> There is no requirement of a client to request a AAAA

I don't understand. Are you asserting that my document doesn't require
AAAA lookups along with A lookups? That assertion is false.

> When would a node get told that the address is unreachable

I have no idea why you think this question is relevant to AutoIPv6.

> transition plans which lack manual configuration are also a
> non-starter in the minds of those who *value* absolute control

You can have manual configuration too. Automation is a question of
defaults.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 20:59:27 -0000

> and inherit their addresses (like 6to4 hosts which aren't 6to4 routers)

This is the fifth blatantly incorrect assertion you have made about
AutoIPv6. Please learn to read.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Mar 2002 23:18:55 +0200 (EET)

> AutoIPv6. Please learn to read.

As others seem to also have problems with understanding your brilliant
idea, perhaps you should also consider whether you've learned to write.

An I-D format draft which goes a bit deeper into the details would be
fine.  Thanks!

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 20 Mar 2002 14:17:58 -0800

>  1) subnet-router anycast address isn't really been implemented

as long as the two that already exist interoperate, this is a noop
statement

>  2) can't establish TCP sessions to anycast addresses

This is an issue with the language about source addresses that really
should be removed. There is no magic about this address in terms of the
application. The only issue is that the connection will drop if routing
decides another box is closer. That should only happen when the original
went away, so the connection would have dropped anyway.

In the context of the combined 6to4 host/router, that address really
does represent the box, and there is no routing alternative.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Mar 2002 00:23:28 +0200 (EET)

> does represent the box, and there is no routing alternative.

In this _particular_ scenario, I agree: nothing would be lost by that.

Actually, one could specify 2002:<IPv4>:: as a "well-known" unicast
address: this does not conflict with addrarch because this address is only
assigned on one node, as IPv4 address can't be shared.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 20 Mar 2002 14:48:24 -0800

> precisely, are you asserting is ``bogus''?

That setting up a service without participation of the DNS administrator
is a bogus process. You happend to be able to do it since they had
already done the work for an IPv4 service, but if they hadn't, just
having an IPv4 address wouldn't help your proposal.

> will have AAAA records. What's the problem?

By your own definition of the magic moment, it can't ever happen.
'... the moment when people can start relying on IPv6 addresses for
their Internet communication...'
Since the nodes behind the AutoIPv6 node can't be reached until after
the magic moment, any remote nodes can't rely on IPv6 to get to them,
and the magic moment never happens.

> AAAA lookups along with A lookups? That assertion is false.

No, this was a simple statement that there is no requirement for a node
to ask for a AAAA record, ever. DNS is an optimization for distributed
management of ascii to numeric mapping.

> I have no idea why you think this question is relevant to AutoIPv6.

'If it tries making a connection to an IPv4 address, and is told that
the network is unreachable, it then tries a connection to the
corresponding AutoIPv6 address.'

Since AutoIPv6 requires a working IPv4 address for the tunnel, when
would the original IPv4 attempt fail, yet the tunnel would still work?

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 20 Mar 2002 14:54:31 -0800

> assigned on one node, as IPv4 address can't be shared.

I am not sure that redefining the address is necessary, but recognizing
the unique property of that address is a good idea. It may be that an
application would be looking for the router anycast addresses of a
collection of subnets, and if one of these is in the set you would want
a consistent interpretation.

Tony

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Mar 2002 00:03:24 -0000

Keith Moore writes:
> the only new idea I've seen here

It's a specification, not a guess. It's analogous to the substitution of
A for MX->A when there are no MX records.

It has to be globally defined, so that a native IPv6 client following
the specification can reach a server following the specification. This,
too, is analogous to the MX situation.

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Mar 2002 10:22:15 -0500

> A for MX->A when there are no MX records.

no, it's a guess (even if you've written a specification for how to 
do the guess).  it's a guess because you don't know whether the host
with that A record actually supports that v6 address - that host may
well have a different v6 address, or not support v6 at all.

> the specification can reach a server following the specification. 

clearly having a standard guess / recommended practice for a v4 host's 
v6 address works better than asking the client to make a random guess
about its destination's v6 address.

> This, too, is analogous to the MX situation.

disagree.  if a domain has an MX record it's because a DNS administrator
explicitly placed it there.  making assumptions about the practices of
a remote host in the absence of explicit information is always somewhat
risky.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Mar 2002 16:48:50 -0000

Keith Moore writes:
> it's a guess because you don't know whether the host
> with that A record actually supports that v6 address

You could make the same bogus argument about hosts without MX records:

   The host has no MX records.     The host has no AAAA records.

   You don't know whether          You don't know whether
   you can use the A record        you can use the A record
   to find SMTP services.          to find IPv6 services.
   Sometimes you can't.            Sometimes you can't.

   Using the A record is a guess.  Using the A record is a guess.

   We don't need to standardize    We don't need to standardize
   this use of the A record.       this use of the A record.

The bottom line is that deployment of MX clients---clients using MX
records to find SMTP services---depended vitally on having those clients
fall back to A records in the absence of MX records. The other approach,
pestering every DNS administrator in the world to set up MX records,
would have been a miserable failure.

Similarly, deployment of IPv6 clients depends vitally on having those
clients fall back to A records in the absence of AAAA records. (It also
depends on updating the server stack etc., so it's not as easy as the MX
transition.) Your current approach, pestering every DNS administrator in
the world to set up AAAA records, is a miserable failure.

It's interesting to note that RFC 974 characterizes the A fallback as
``benefit of the doubt'' rather than an essential transition tool. Now
you're characterizing the A fallback for IPv6 as a ``guess'' rather than
an essential transition tool. But the choice of words doesn't change the
economic burden.

> if a domain has an MX record it's because a DNS administrator
> explicitly placed it there.

Probably. And the same for AAAA records. But the interesting question is
what to do with hosts that have only A records.

Keith, were you arguing in 1985 that MX->A shouldn't fall back to A?

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Mar 2002 12:25:41 -0500

>    The host has no MX records. 
> 
>    You don't know whether     
>    you can use the A record  
>    to find SMTP services.   

no, but you do know that if that host accepts mail, then it will
be at port 25 at that host's address.  

it's true that if an MTA contacts that host's SMTP port and it says 
'connection refused' then it doesn't know whether this is a temporary 
or a permanent condition - so it ends up retrying delivery until it
decides it must give up.  but this is true for any network service - 
there's no way to distinguish between 'the server is down' and
'the service is not supported at this host, and any information you
received elsewhere to the effect that the service is supported here
is in error'.

> fall back to A records in the absence of MX records. 

it was even worse than that - for many years mail delivery depended 
vitally on having an SMTP server that would "do the right thing"
answering at the address in the A record even if your primary 
MX server was elsewhere.

before MX there was a well-established convention of using A records,
and it was many years before you could count on mail clients honoring
MX records.  what you're proposing is slightly different - you're
not replacing a well-established convention, you're creating a new
convention that retroactively applies to millions of existing hosts.
offhand I don't see a tremendous potential for harm here as long
as it's only used as a last resort (when there are no AAAA records)
and as long as apps or hosts don't favor v6 over v4 (some do that today).

> Keith, were you arguing in 1985 that MX->A shouldn't fall back to A?

Dan, would you please concentrate on the technical aspects of your
proposal rather than trying to make this a personal issue?

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Mar 2002 18:18:54 -0000

Keith Moore writes:
> for many years mail delivery depended vitally on having an SMTP server
> that would "do the right thing" answering at the address in the A
> record even if your primary MX server was elsewhere.

Right. This is obvious to people who understand how transitions work.
Here's the situation:

   MX:                                IPv6:

   There was a transition period      There is a transition period
   from old clients,                  from old clients,
   connecting only to A records,      connecting only to A records,
   to new clients,                    to new clients,
   which also understood MX.          which also understand AAAA.

   Servers had to be reachable        Servers have to be reachable
   through A records                  through A records
   until the old clients were gone.   until the old clients are gone.

Of course, when you focus on this situation (old clients talking to new
servers), you don't see the importance of all clients being able to use
A records as a default (so that _new_ clients can reach _old_ servers).

> proposal rather than trying to make this a personal issue?

I'm simply drawing an analogy between your current mistakes and the
mistakes that, presumably, some people were making in 1985. You do agree
that the omission of the A fallback from the MX specification would have
been a huge mistake, right?

Your hostile response suggests that perhaps you _were_ making exactly
the same mistake in 1985. That wouldn't surprise me, since I'm familiar
with how you screwed up some subsequent transition efforts, but it's not
the foundation of my argument.

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Mar 2002 20:22:49 -0500

MX:                                IPv6:

the difference is that in the case of SMTP, using A was the originally
specified behavior that legacy applications expected; while in the case 
of v6, using AAAA was the originally specified behavior that 
applications expected.  

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Mar 2002 02:51:15 -0000

Keith Moore writes:
> while in the case of v6, using AAAA was the originally specified
> behavior that applications expected.  

I understand, and I feel sorry for the implementors who moved forward
without seeing a plausible transition plan. However, the extra costs for
them are much smaller than the human costs I've been talking about.

Suppose that MX had originally been specified without an A fallback.
People would quickly have noticed that the MX clients were unusable
because most DNS administrators weren't setting up MX records. The only
reasonable solution would have been to add the A fallback and redeploy
the clients.

---

From: "Eugene M. Kim" <[email-masked]>
Date: Fri, 22 Mar 2002 10:45:26 -0800

Wouldn't this be the right direction to solve the administrative
problem?

Eugene

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Mar 2002 09:26:58 -0500

> them are much smaller than the human costs I've been talking about.

the extra costs are mostly borne by users who have to wait when their
apps (those that follow your recommendation) try to contact a server
at an IPv6 address that (in most cases) isn't supported by the 
destination.

in other words, you're assuming that most current v4 hosts are willing
to support 6to4 in order to be reachable by v6-only hosts.  though 
it would indeed be nice if this were the case, to me it seems like a
rather large leap of faith.  my guess is that most sites would rather 
filter 6to4 traffic entirely (out of securty concerns, whether
misguided or not) than to upgrade all of their hosts to support 6to4
and apply reasonable security filters to the 6to4 traffic. 

> because most DNS administrators weren't setting up MX records. 

or perhaps, people would have noticed that they didn't get incoming
mail unless they had an MX record in place - so they would have had
an incentive to put those records in place.  

of course, email predates DNS, and there was no MX provision  in
HOSTS.TXT.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Mar 2002 19:46:28 -0000

> at an IPv6 address that (in most cases) isn't supported by the 

``If it tries making a connection to an IPv4 address, and is told that
the network is unreachable, it then tries a connection to the
corresponding AutoIPv6 address.''

Under exactly what circumstances would this produce a delay?

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Mar 2002 16:47:50 -0500

> Under exactly what circumstances would this produce a delay?

the delay is caused by trying to connect to the v6 address when 
v6 isn't supported by the destination.  you typically won't get
an ICMP unreachable message in this case; you have to wait
until the connection times out.

(of course, if you get an ICMP unreachable message on the v4 address, 
the corresponding v6 address won't work either.  the correct indication
to use before trying the v6 address would be a host having no v4 route 
to the destination address) 

Keith

p.s. there are other problems with AutoIPv6, one being that it
won't work for destination hosts behind a v4 NAT using DNS ALG.
that doesn't necessarily make AutoIPv6 worse than other transition
solutions that have been proposed, but it doesn't seem to be an
inherently superior solution either.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Mar 2002 23:04:10 -0000

Keith Moore writes:
> the delay is caused by trying to connect to the v6 address

That doesn't answer the question.

Once again: The AutoIPv6 connection is attempted _if_ the IPv4
connection attempt says network-unreachable.

You seem to be making the rather strange claim that users on typical
directly-connected IPv4 hosts will frequently encounter situations where

   (1) an IPv4 connection attempt says network-unreachable and
   (2) an IPv6 connection attempt to the corresponding AutoIPv6
       address produces an annoying delay.

But #1 already excludes the vast majority of failures encountered by
users. I see no reason to believe that the combination of #1 and #2 will
be a statistically significant event.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Mar 2002 20:23:21 -0500

> be a statistically significant event.

if by #1 you really mean that the sending host receives an ICMPv4 network 
unreachable message when trying to send directly to the destination
host's IPv4 address, then the corresponding AutoIPv6 address will also be 
unreachable. so if that is your assumption then the combination of #1 and 
#2 will indeed be a rare event - but it also means that AutoIPv6 would be 
useless - the only conditions under which you'd use it would be those
in which the host isn't reachable anyway.  (so I assume this is NOT what
you mean by #1.)

if by #1 you mean that the network is unreachable because the sending
host doesn't have a v4 route to the destination network, then an attempt
to send to the destination's AutoIPv6 address might still work (presuming
the sending host has a route to 2002::/16) but in that case the sending
host would be unlikely to get an ICMPv6 response if the destination host
were unreachable, because ICMPv4 messages from the destination network
will not get translated into ICMPv6.  So in that case the sending host
would not get an immediate indication that the destination were 
unreachable - it would have to time out the connection.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Mar 2002 07:44:24 -0000

Keith Moore writes:
> to send to the destination's AutoIPv6 address might still work

Right. This is the normal situation for future hosts whose only global
addresses are v6 addresses. Trying AutoIPv6 is essential.

For today's hosts with v4 addresses, on the other hand, there's normally
a route out of the host covering every global v4 address, so this
situation won't happen at all. No delays to worry about.

I've changed my web page to emphasize that, under the standard socket
API, the client should be watching for the EHOSTUNREACH error. Sure, we
might waste a packet on the occasions when this is caused by an ICMP
message, but this is a much smaller traffic issue than constant AAAA
lookups, which in turn are a much smaller issue than HTTP traffic.

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Mar 2002 13:28:35 -0500

> situation won't happen at all. No delays to worry about.

this is only the case if every v4 host also supports 6to4 and v6.  
as I said earlier, this is a big leap of faith - first to assume
that most existing v4 hosts will upgrade to support 6to4 (most
current v6 stacks do not support host 6to4); second because many 
(perhaps a majority) of existing v4 hosts are behind NATs and won't 
accept a packet sent to a 6to4 address derived from the v4 address 
external to the NAT (an address which, for most NATs, will change 
frequently) even if the host supports 6to4 and the encapsulated 
packet arrives at its network interface.

and in those cases the sending host *will* see a delay, waiting for
a response from the destination host which will never come.  for
some apps such as SMTP this isn't a big problem - no human user is
waiting.  for other apps such as web browsers it's a bigger issue.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Mar 2002 10:39:46 -0000

Keith Moore writes:
> and in those cases the sending host *will* see a delay

What makes you think that? Let's review the situation for these typical
hosts:

   * There's a default IPv4 route out of the machine.

   * The client tries an IPv4 connection.

   * The IPv4 connection fails: usually a timeout; sometimes connection
     refused.

   * That error is _not_ EHOSTUNREACH (or the equivalent in another
     API), so the client doesn't try the AutoIPv6 connection.

You say that the AutoIPv6 connection attempt causes a delay. But the
AutoIPv6 connection attempt isn't even happening in the first place. So
what are you talking about?

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Mar 2002 13:34:48 +0100

> > and in those cases the sending host *will* see a delay
<SNIP>
> what are you talking about?

Maybe a bit 'd0h' style but for exampel Internet Explorer and Mozilla's
do the following in pseudo code:

if (host = fetchdns("servername.example.org", "AAAA"))
{
	socket = connect(host, port);
	// if this fails caused by no route, timeout etc.. we get no
connected socket but NULL or something...
}
if (!socket)
{
	// No socket yet so try IPv4
	if (host = fetchdns("servername.example.org", "A"))
	{
		socket = connect(host, port);
	}
}

if (socket)
{
	// Connected
}
else
{
	// No Connection
}

Postfix/sendmail/PuTTY/<random other IPv6 enabled application> do this
same process, though for mailers MX's are resolved first and the AAAA/A
is taken from that or if no MX is found they simply lookup AAAA and then
A.

This currently WORKS and I think many people use it on a daily basis
without knowing it.
If some user on Windows XP has typed "ipv6 install" IE automagically
goes into this mode (IPv4 as fallback) too and as some people do
actually type the install command but never really setup IPv6 at all, or
forget about it they are probably using it without knowing it ;)

If the administrator of the server host didn't make AAAA's he doesn't
know about IPv6 at all so IPv6 won't be available either and why try it
then, if the admin did take the time in filling in AAAA's he probably
wants to be reachable by IPv6 too so it'll prolly work anyways.
If your side doesn't work that's your problem, not the remote side.

And as for this nice 'autoipv6' thingy.....  read:
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp "The
6to4cfg.exe tool"
which enables all this on IPv6 enabled Windows platforms, and it's a
trivial script for most unix-derived systems...

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Mar 2002 10:24:34 -0500

> What makes you think that? 

because this is exactly what happens whenever I try to contact
a host using a 6to4 address when it doesn't support receiving
traffic at that address, or when there's a NAT in the way of the
v4 path.  

> Let's review the situation for these typical
> hosts:
> 

assuming you mean "client" by "the machine", that's a different
case than the one I was describing.

maybe an exhaustive case analysis would help.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Mar 2002 17:06:43 -0000

Jeroen Massar writes:
  [ IPv6 connection to AAAA, then IPv4 connection to A ]
> This currently WORKS

Only if the client machine has IPv4 connectivity. Otherwise the client
won't be able to reach most of the Internet's servers.

Consequently you'd have to be an idiot to accept a global IPv6 address
as a substitute for a global IPv4 address. This is a crucial obstacle to
IPv6 deployment.

I'm proposing a slightly different software strategy that, if broadly
adopted, will change this situation. An AutoIPv6 client that has IPv6
connectivity can reach an AutoIPv6 server that has IPv4 connectivity.

It seems that ngtrans is almost entirely populated by people saying
``Well, yes, we want the whole Internet to talk to IPv6 addresses, but
we don't need the software and protocols to set this up automatically,
because the server administrator can manually do XYZZY.'' That's a
ludicrous response. You're trading a small software cost for a vastly
larger human cost. There are many more administrators than network
programmers.

Have you all been so blinded by the wonders of IPv6 that you're unable
to comprehend why millions of people are _not_ setting it up? Am I the
only person here who insists on subjecting IPv6 transition plans to a
cost-benefit analysis?

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Mar 2002 13:22:44 -0500

> Am I the

no.  but your analysis appears to be based on assumptions that aren't 
widely shared.  for instance, you seem  to assume that:

- most existing v4 hosts will be willing to upgrade to support AutoIPv6
  in order to be reachable from v6-only hosts, and

- most existing v4 enterprise networks will be willing to upgrade their 
  firewalls to apply their current policies to AutoIPv6 traffic
  (as opposed to simply blocking 6to4 traffic)

and since AutoIPv6 won't work through NATs (or if it will, details are
yet to be supplied) you seem to (implicitly) assume that the failures
caused by NATs won't significantly affect acceptance of AutoIPv6.

call me skeptical.  my model for most network security admins, for instance,
is that they block any kind of traffic that they don't understand, or that 
seems like a threat to their ability to control access to their networks, 
and that they don't enable it again without direct orders from the 
CTO/CIO/CEO.  and while I suspect that OS vendors might be convinced to 
include host 6to4 with a future version of their operating systems, enabling 
it by default is a different question. 

as to whether IETF's influence could help to encourage OS vendors
and network security admins to support AutoIPv6 - I think our influence
with the former group is much better than our influence with the latter
group.  but even the former group is going to (quite reasonably) insist
that AutoIPv6 not disrupt existing services. which is why I raised the
concern about delays resulting from attempts to contact IPv6 addresses 
on hosts for which they don't exist or for which connectivity can't be 
established.

(this concern about disrupting services isn't specific to AutoIPv6.  
one of the problems I see when using NetBSD is that its built-in tendency 
to use IPv6 in preference to IPv4 often causes a delay when trying to 
access a site that advertises both A and AAAA records, and the 
connectivity for IPv6 is significantly worse than for IPv4.  The
client first attempts to contact the IPv6 address and only when that
attempt times out does it try to contact the v4 address that works right
away.)

I don't want to prematurely discard a promising idea.  but neither do I 
think that we can afford to assume that most sites using v4 will adopt 
AutoIPv6 within a short time, even with the most enthusiastic of 
recommendations from IETF.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Mar 2002 20:49:45 -0000

Keith Moore writes:
> you seem  to assume that:

I have said nothing of the sort. I am not saying that any particular
IPv6 transition plan will succeed. I am not saying that IPv6 itself will
succeed. Quite the opposite: I am telling you that most IPv6 transition
plans are definitely _not_ going to succeed.

I ask basic questions like ``Why should I set up an AAAA address?'' and
get idiotic responses like ``Why do people climb mountains?'' Frankly, I
feel like I'm talking to a bunch of OSI proponents who are convinced
that OSI is the wave of the future and who can't understand why most
Internet users aren't signing up.

> which is why I raised the concern about delays resulting from attempts
> to contact IPv6 addresses on hosts for which they don't exist or for
> which connectivity can't be established.

I agree that IPv6-connection-attempt delays are a serious problem. I've
seen people turning off client-side IPv6 to avoid those delays. It's
obvious that A should be tried _before_ AAAA for the moment.

But I still don't see why you think AutoIPv6 will cause these delays.
Remember that the AutoIPv6 connection attempt happens only if the IPv4
connection attempt returns EHOSTUNREACH.

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 28 Mar 2002 01:41:53 +0100

> as a substitute for a global IPv4 address. This is a crucial obstacle
to

Let's take the picture again:
http://unfix.org/projects/ipv6/IPv6andIPv4.gif

<repeating story for yet another time, biting the troll in the flames
again>

Proxytricks (socks5 etc. ) are suited perfectly for letting a IPv4-only
host talk to a IPv6-only host.
There is no other way a IPv4-only client (or server for that matter) is
going to talk to an IPv6 only box.
Simple. And why should one want to upgrade that old nice VAX in the
corner? They won't.

I can setup a IPv6 only host and reach all IPv4 hosts without problem
already using NAT-PT.

$ host -t any cr.yp.to
cr.yp.to mail is handled (pri=0) by a.mx.cr.yp.to
cr.yp.to has address 131.193.178.181
$ host -t aaaa a.mx.cr.yp.to
$ host -t aaaa muncher.math.uic.edu
$

Hmm no IPv6 there yet? I wonder if you even ever succeeded, or even
looked at for that matter, an IPv6 installation at all.
Have you ever seen the real dancing kame, not the ghosted one. Maybe
AutoIPv6 is too difficult, better call the helpdesk
then; ah helpdesk -> ISP helpdesk bingo: see below for more about that.
I have been paying attention though, my machines do IPv6 for quite some
time now, I can even play Quake over IPv6
and do a zillion other things with it and configuring, oh: "just plug it
in" and no blue screens at all, very handy rtadverts.

> connectivity can reach an AutoIPv6 server that has IPv4 connectivity.
<SNIP>
Did you even LOOK at the link to Microsoft's FAQ explaining the
automagic 6to4 setup?

Let that 'small programmer' program a small script to do this simple
functionality...
Peter Bieringer has some very good examples at
http://www.bieringer.de/linux/IPv6/ so he can do some copy&paste work.

> only person here who insists on subjecting IPv6 transition plans to a
The reason that "millions of people" are not setting it up is very
simple: they don't peeping care.
They don't know about IPv6 (neither do they about IPv4 for that matter)
Tthey don't care how they connect, if it is IPv4 or IPv6 or IPX or
Appletalk for that matter
They simply want to run Kazaa and leech their stuff, type
"http://www.pr0nshop.c0m" and get their pr0n.
They really don't give a damn about which protocols are used, they don't
even care about the word 'protocol'
and really aren't interested how it works as long as it works.

What is going to happen, and what is currently happening in this world
is the following, which you apparently don't see happening:
ISP's and IX's are getting sTLA's and deploying native IPv6 everywhere:

APNIC:  54 /35
ARIN:  26 /35
RIPE:  55 /35
6bone: 114 pTLA's
Total Allocated for the 3 RIRs: 135 /35

(http://www.ripe.net/ripencc/mem-services/registration/ipv6/ipv6allocs.h
tml & www.6bone.net)

That's "The Internet" not "IPv6 Internet", most hosts are reachable with
IPv4 and IPv6 with fallback modes et all.
And that number is growing steadily, companies are getting the hang of
IPv6 and are deploying it.
How would one deploy hard&software in a company if the systems aren't
proven to be stable.
You can't just let your company depend on that 'small programmer' that
made a bug, it needs testing.

Maybe you know what the AMS-IX is... welll they did the following last
week:
8<--------------------------------
AMS-IX currently uses a 6BONE (3FFE:3000::/64) prefix. As you may know,
this is experimental address space.

AMS-IX obtained an official IPv6 prefix from RIPE. We kindly ask
operators
using IPv6 to start using this prefix on AMS-IX:

   2001:07F8:1::/64
------------------------------->8
Yes a complete IX running NATIVE IPv6 for some years now...
http://dmoz.org/Computers/Internet/Protocols/IP/IPng/ <-- there are more
there for you to find.
It's all a bit of a chicken and egg problem, but the chickens
(ISP's/carriers/IX's) are busy gathering food to produce egg's.
And the baby chickens are busy creating software for them...

Most software that is in common use has currently been made IPv6 capable
and is getting deployed around the world.
In time ISP's will start passing out IPv6 addresses to dailup & adsl
clients, this is already happening at some ISP's.
Windows XP comes with default IPv6 stack, so the ISP manual will simply
get an extra line soon "type 'ipv6 install' and you can connect'.
Native IPv6 doesn't have the hassle of setting up strange AutoIPv6
things, you simply get IPv6 on the wire with a nice subnet so you can
connect your fridge to the net too. And you might have read the RFC's
and read about Router Advertisements and DHCPv6.

If you really are so anxious of pushing this "purely magnificent
AutoIPv6" then first make sure you speak IPv6 too, maybe you could make
and RFC for it or a sample implementation ? You might also take a look
at the very useful TS Protocol ( http://www.freenet6.net/ )
In short:
8<---------
Step-by-step to get IPv6 connectivity  
1. Install an IPv6 stack
2. Install the Freenet6's client and configure tspc.conf
3. Create your userid
4. Run the client and get IPv6 connectivity
---------->8
If one takes the hassle for installing an IPv6 stack he/she/it will also
be able to 'config' the tspc.conf
which can be done all with a nice wizard. Clicketyclick.... look mommy
my pr0n goes over IPv6!

"If there is no Quake server, you can't play Quake"

</burnout>

PING ff02::1(ff02::1) from fe80::2a0:c9ff:fe07:e073 eth1: 56 data bytes
64 bytes from ::1: icmp_seq=0 hops=64 time=247 usec
64 bytes from fe80::201:3ff:fed7:5b81: icmp_seq=0 hops=64 time=364 usec
(DUP!)
64 bytes from fe80::280:48ff:fecd:bc57: icmp_seq=0 hops=64 time=374 usec
(DUP!)
64 bytes from fe80::210:4bff:fec6:e4be: icmp_seq=0 hops=64 time=381 usec
(DUP!)
64 bytes from fe80::260:8ff:fe2c:ca8e: icmp_seq=0 hops=64 time=388 usec
(DUP!)
<SNIP>
--- ff02::1 ping statistics ---
1 packets transmitted, 1 packets received, +72 duplicates, 0% packet
loss
round-trip min/avg/max/mdev = 0.247/0.782/1.377/0.256 ms

Only 72 dupes there, IPv6 isn't used at all, nobody knows how it works,
it's very difficult.
XS26 (www.xs26.net) statistics Users: 802, Tunnels 799, ain't used there
either apparently.
And what about freenet6 and hurricane and the numberous other providers.
Those users apparently had quite a worrysome time configuring all this
difficult IPv6 stuff.

Greets,
 Jeroen

BTW: The porn and "nature entertainment" industries or whatever you can
call it are always a step
ahead with most technological stuff, streaming video anyone, thats why I
mention it as an example, no other reasons whatsoever.
BTW2: Your spammish adverts for IM2000 hidden inside your 'qsecretary
notices' are all returned to [email-masked].
You might consider fixing your reply-to and set it to the list address
if you don't want any private replies.

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Mar 2002 21:09:38 -0500

> plans are definitely _not_ going to succeed.

Please forgive me for attempting to read between the lines of what you wrote.

I think that you and I would agree that most IPv6 transition plans
are of limited applicability.  Some of their authors would also agree.
We haven't been able to come up with a plan that seems to work for 
the general case; we've only found plans that work for subsets.
Some plans work for larger subsets of the general case than others.

> Internet users aren't signing up.

There is a variety of ideas of how difficult it will be to get people 
to move to IPv6, and a variety of views of what the transition will 
look like.  It's difficult to say exactly what will happen.  To cite
an example that's familiar to both of us, SMTP might have stayed 
mostly 7-bit only for much longer had it not been for several security 
bugs in sendmail that forced people to upgrade.

> connection attempt returns EHOSTUNREACH.

Even though I mostly program on UNIX, I think better in terms of ICMP 
than in UNIX errors.  Since not everyone uses UNIX, we'd have to define 
this behavior in terms of ICMP anyway.

In my experience, a ICMP host unreachable (ICMP type 3, code 1) 
indication is very rare, and normally cannot be issued except by 
the destination network.  Network unreachable errors (ICMP type 3, 
code 0) are much more common, and these can be issued by any
"gateway" (router) between the source and destination. 

Offhand, I'm not sure why you'd want to treat these two cases 
differently for AutoIPv6.  Either a host unreachable or a network 
unreachable would indicate that the v4 packet couldn't get to its 
destination.  

I started to do an analysis of which cases would work, which
would fail, which would cause delay, etc., but the number of cases 
became larger than I wanted to work out on the spot.  
Here are separable facets that I've identified:

(S = sender, R = receiver)

s4 - S has at least one v4 interface and a default v4 route
     (connectivity might be global or local-only or NATted)
     this is detectable by the sender.

s4g - S has global, non-NATted v4 connectivity 
      note that this can't be reliably detected by S

s6  - S has a v6 interface (could be using 6to4 or teredo) and 
      a default v6 route
      this is detectable by S

s64 - S has a host 6to4 driver - 
      so if it has s4 and s4g it can send v6 packets even without s6
      this is detectable by S
      (but if it doesn't have s4g the packets won't get there)

r4 - R has some kind of v4 connectivity and an advertised A record
     (might be NATted using static mapping or DNS ALG)
     this is detectable by S based on presence of A record

r4g - R has stable, non-NATted v4 connectivity with no filtering
     S can't reliably detect this

r6 - R has v6 connectivity at a stable v6 address (could be 6to4) 
     and an advertised AAAA record
     this is detectable by S by the presence of AAAA record.

r64 - R has "host" 6to4 capability and has it enabled
      so if it has r4 and r4g it should be able to receive v6 packets
      but there's not necessarily an AAAA record for that interface.
      this is not detectable by S

That yields 256 possible cases.  Many of them are trivial - for instance
if either s4 or s6 is false then S can't send to anybody, and
if either r4 or r6 is false then R can't receive from anybody.
s64 is useless without s4 (and s4g, but s46 isn't detectable by S)
r64 is useless without r4 (and r4g, but r46 isn't detectable by S), etc.

For now, consider a few cases:

1. s4 = 1, s4g = 1, s6 = 0, s64 = 1, r4 = 1, r4g = 1, r6 = 0, r64 = 1

	In this one, S and R would just use v4

2. s4 = 0, s4g = 0, s6 = 1, s64 = x, r4 = 1, r4g = 1, r6 = 0, r64 = 1

	This one would work as advertised.
        S would send to R's autoipv6 address based on R's A record

3. s4 = 0, s4g = 0, s6 = 1, s64 = x, r4 = 1, r4g = 1, r6 = 0, r64 = 0

	(like case 2, except R doesn't have host 6to4 support)
	S sends packets to R's 6to4 address.  R ignores them
	because it doesn't have 6to4 support.  There's no indication
	of error from ICMP.  Even if R issues a "protocol unreachable"
	ICMP (type 3 code 2) then this won't get translated by the 6to4 
        relay router, and S will never see it.  The only indication of
        failure that S receives is a connection timeout.

	I'd expect this case to be very common even if autoIPv6 were
	enthusiastically adopted, during a transition period until
	most v4 hosts had host 6to4 support enabled.

4. s4 = 0, s4g = 0, s6 = 1, s64 = 0, r4 = 1, r4g = 0, r6 = 0, r64 = 1

	(like case 2, except R is behind a nat running DNS ALG)
	S sends packets to R's 6to4 address, and they arrive
	at R's interface.  Either R rejects them because the 
	inner and outer destination addresses aren't compatible,
	or R's replies get dropped by the 6to4 relay router because
	the inner and outer destination addresses of the reply aren't
	compatible.  Either way, s receives no indication of 
	failure other than a connection timeout.

	Given the number of NATs out there, I'd expect this to be a 
        common case.

The analysis gets more cumbersome if you consider that there are multiple
kinds of success: a NATted connection is good enough to allow some 
apps to work, but not good enough for all apps.  (and NAT-PT already 
handles the apps for which NAT doesn't interfere)   For some kinds of 
distributed apps it's not sufficient for s to have an address that allows 
it to reach R  - what is needed is a single address that allows any of 
the processes in that app to reach any other process in that app.

But the main point here is that if we're arguing about which cases will 
or won't cause delay, we need to specify those cases very carefully
to make sure we're both talking about the same set of circumstances.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Mar 2002 03:56:22 -0000

> 3. s4 = 0, s4g = 0, s6 = 1, s64 = x, r4 = 1, r4g = 1, r6 = 0, r64 = 0

Now I understand. Here's an English translation:

   Hi, I'm Keith. I have an IPv6 host without IPv4 connectivity, and
   without a proxy, except for a DNS proxy.

   Normally, when I try to use the Internet from that host, everything
   fails immediately. I try Google: fail. I try CNN: fail. I try sending
   email: fail. Well, okay, that last one isn't immediate.

   However, if I install AutoIPv6 software, those immediate failures
   turn into connection timeouts! I try Google, for example: timeout!

My response: So what? Who cares? It's a disaster either way. Before the
magic moment, you'd have to be insane to rely on that machine for your
Internet access. Normal users simply aren't in this situation.

It's completely unreasonable to compare this to the AAAA-before-A delay.
The AAAA-before-A delay is something that inflicts pain on normal users
and encourages them to disable IPv6. That hurts the transition; it makes
the magic moment harder to reach.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Mar 2002 09:49:37 -0500

>    without a proxy, except for a DNS proxy.

or maybe, I'm a host attached to a 3G cell phone.  

>    email: fail. Well, okay, that last one isn't immediate.

in such a case there would almost certainly be proxies for specific apps 
like web and email.  this doesn't change the general interop picture 
for other apps.

> My response: So what? Who cares? 

users care.  after they install AutoIPv6 software, their apps can reach
some additional set of hosts, but those same apps will exihibit delays 
before failing to connect to another set of hosts - and there's no way
for the app to tell the difference without trying to connect.  at best,
the app could change the connection timeout when it tries an AutoIPv6
address (which might be a useful compromise)

and if you don't consider this particular case significant, feel free
to enumerate and analyze the other cases.  but remember that your opinion 
about which cases are relevant may not be widely shared, and handwaving
to the effect of "this just works" in the absence of case analysis 
will not convince many people.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Mar 2002 00:07:21 -0000

Keith Moore writes:
> in such a case there would almost certainly be proxies for specific
> apps like web and email.

AutoIPv6 doesn't make any difference for applications using a proxy. So
these applications are obviously not relevant to your claim that users
will notice some effect from IPv6.

> this doesn't change the general interop picture for other apps.

Let's focus on those services. Suppose the machine doesn't have a proxy
for the BSD talk protocol.

With or without AutoIPv6, practically every talk connection from that
machine will fail, because the machine has no way to reach the IPv4
universe.

With or without AutoIPv6, the user is not going to use that machine for
his talk service. He's not an idiot. The machine doesn't work; he'll use
another machine.

It doesn't matter how long the failure takes. A toaster that keeps
spitting out your untoasted bread is no better than a toaster that never
heats up. Either way, it's broken. The user will find a working toaster.

As I said before, you are being completely unreasonable in comparing
this situation to the AAAA-before-A delays. The AAAA-before-A delays
hurt _successful_ connections from _working_ machines. The AAAA-before-A
delays give people an incentive to turn off IPv6, making your IPv6
addresses less useful, pushing off the magic moment. There is no such
incentive in your broken-toaster scenario.

---

From: JJ Behrens <[email-masked]>
Date: Thu, 28 Mar 2002 17:14:05 -0800

> heats up. Either way, it's broken. The user will find a working toaster.

DJ, I think, perhaps, you misunderstand Pekka's scenario.  Suppose irritable
customer C wishes to connect to site S.  Site S does indeed have a DNS record
with an A entry.  However, site S is currently offline, for some unknown
reason.  First C tries an IPv4 connection to S, and gets a host unreachable.
Next, C tries an IPv6 connection to S (all of this is done by AutoIPv6,
actually).  However, rather than getting a host unreachable, the connection
will time out.  This takes too long and is inconvenient.  Pekka, please correct
me if I misunderstand your scenario--I'm still a newbie!  By the way, DJ, I'm 
interested in your AutoIPv6 ideas.  When will you be releasing an internet
draft so that the discussion may begin in earnest? 

Best Regards,
-jj

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Mar 2002 02:31:23 -0000

JJ Behrens writes:
> When will you be releasing an internet

I have a web page: http://cr.yp.to/proto/ipv6.html. Is there anybody
else here who understands that administrator time is valuable? If so,
that person can write a draft. If not, IPv6 is doomed. Either way, the
notion that discussion has been stymied by the lack of an I-D is absurd.

> However, site S is currently offline, for some unknown
> reason.  First C tries an IPv4 connection to S, and gets a host
> unreachable.  Next, C tries an IPv6 connection to S (all of this is
> done by AutoIPv6, actually).  However, rather than getting a host
> unreachable, the connection will time out.

Wrong. In this unusual situation---where an IPv4 router announces that a
host is unreachable---the AutoIPv6 connection attempt will be tunneled
to the same IPv4 address, so it will receive the same host-unreachable
message from the same router.

---

From: Tim Chown <[email-masked]>
Date: Fri, 29 Mar 2002 12:19:15 +0000 (GMT)

> notion that discussion has been stymied by the lack of an I-D is absurd.

There is also the little matter that the ngtrans WG is not taking new I-D
material (in terms of transition methods) until July while the requirements
are reviewed.

I think Dan spends enough time mailing this list however to instead invest
time in creating an I-D :-)   The above web page, as Pekka put it, assumes
a healthy sprinkling of network pixie dust.   A full I-D should remove
some of the mist surrounding the specifics of AutoIPv6, as well as good
discussion of security issues.

The sort of analysis that Keith(?) posted is certainly useful. 
 
Tim

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Mar 2002 10:46:25 -0500

> will notice some effect from IPv6.

agreed.

> machine will fail, because the machine has no way to reach the IPv4

not necessarily.  if the server machine has IPv4, is running host 
6to4, and isn't behind a NAT, and the client machine is willing to try  
contacting the server machine at a 6to4 address derived from the
server's v4 address, then the two machines can "talk".  the only problem
is that, absent a AAAA record for the server, the v6-only client machine
doesn't have a good way to determine whether that connection is likely to 
succeed.

> his talk service. He's not an idiot. The machine doesn't work; he'll use

the decision isn't entirely the user's.  the user has a mobile terminal -
a smart cell-phone/PDA or a laptop attached to a cell phone.
the wireless provider provides IPv6 access because 3G cell phones are 
based on v6.  the provider also realizes that some kind of v4 access is 
necessary because most legacy apps are on v4.  what technology does the 
provider rely on?  application-specific proxies?  NAT-PT?  or will
it expect apps to use AutoIPv6?

> incentive in your broken-toaster scenario.

I cited the AAAA-before-A delay only as a concrete example of why 
trying to use an address that won't work will cause a delay.  naturally 
an app will use an advertised address (whether A or AAAA) in preference
to an unadvertised address (a v6 address derived from an A record
when the app doesn't have v4 access).  the point is, there's a penalty
for trying to use such an address if the address doesn't work, so you
would like to avoid forcing the app to choose between using an address
that has a high probability of not working (at least in initial 
deployment) and not using the address at all.

Keith

p.s. I don't think there's going to be a magic moment when IPv6 just works.  
I think we'll end up using IPv6 for some apps, IPv4 for others.
each app will develop or evolve using the path of least resistance
at the time.  for the time being, apps that can easily tolerate NATs
will use IPv4.  those same apps can work over v6 with something like
NAT-PT, so they can migrate.  initially, v6-only apps  will be those that 
cannot tolerate NATs and/or which are designed to reach users or devices 
that depend on a v6 infrastructure.  any v4 host that needs to run a
v6-only app can be upgraded to run v6 - using 6to4/6over4/teredo
until its local network infrastructure catches up.   Folks who don't
upgrade their hosts to run v6 will be like today's folks who refuse
to use email or the web or the telephone - they will always exist, 
but their numbers will diminish over time.  At some point essentially 
all the v4 access will be NATted anyway, and users won't know or care 
whether the network is using v4 or v6.

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Mar 2002 11:02:49 -0500

> notion that discussion has been stymied by the lack of an I-D is absurd.

nobody doubts that administrator time is valuable.  for that matter,
our time is valuable also.  the failure to produce a sufficiently 
detailed specification to determine how the proposal will work
does hamper discussion, and wastes our time.  beyond that, the I-D 
mechanism just helps us ensure that we're all talking about the same 
version of a document - so we don't argue about a problem that's 
already been fixed.

> message from the same router.

there's an interesting point.  if you're assuming that the sending host
does the v6-over-v4 encapsulation then the sending host will also receive
any ICMPv4 message that results.   there are two problems with this:

1. it assumes that the sending host has v4, so it only works for clients
with native v4 access.  it won't work for clients with v6 only access
that are trying to send to servers with native v4 access.  so in a sense,
it only solves half the problem.

2. it assumes that there's enough information in the ICMPv4 message to
associate it with the outgoing IPv6 connection.  however the ICMPv4 message
doesn't contain enough of the inner v6 header of the failed packet to let
you identify the connection, it only contains the outer v4 header + 8 bytes 
of payload.  if the host has multiple v6 connections with source/destination 
address combinations that correspond to the v4 source/destination address 
on the outer v4 header, it won't be able to determine which v6 connection 
should be associated with the ICMPv4 message.

Keith