Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
From: Paul Smith <[email-masked]>
To: Tim Chown <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 20 Nov 2001 09:55:09 +0000
List-Id: <ietf-822.imc.org>

>IPs are certainly not free.... not in the UK....

Yes they are...

We have 32 IP addresses and don't pay a penny for them. We could have 256 
addresses if we wanted, and still not pay any more.

It depends on your ISP, and your type of Internet connection. On cheap/free 
dial-up connections the ISP will often charge more for an IP address 
(unless you're with Demon) as there's administration for them to do, but if 
you have a leased line, most reasonable ISPs will give you whatever IP 
addresses you want.

The ISP isn't charged for IP addresses. Any charge they make to users is 
for administrative/configuration work.

> > The obvious answer is to charge people for IP addresses rather than the
> > current system of giving them away for free.

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Tue, 20 Nov 2001 09:36:16 +0000
To: "D. J. Bernstein" <[email-masked]>, <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> > Eg, I picked a number at random - 52.0.0.0/8. This is owned by 
> 'dupont.com'
> > who I'm sure are a wonderful company, but they 'only' have 85000 employees
> > - why on earth do they need 16M IP addresses, even if each employee has 10
> > PCs they've still got 15.9M spare addresses? They aren't an ISP so they
> > aren't giving the addresses to other people.  There are other similar 
> examples.

>Why would people pay for Address Space, when it is FREE ?

But why should it be free? Any commodity which is in limited supply 
probably shouldn't be free, or people abuse the facility and grab that 
commodity in bulk while they can meaning that other people can't get it.

At something like $1 per IP address per year (retail - ISPs would get a 
discount..), it probably wouldn't really affect anyone who USES their IP 
addresses efficiently, but it would certainly make the hoarders rethink 
their situation.

If RIPE, APNIC, ARIN etc said 'in 12 months we will be charging people for 
IP addresses', people would HAVE TO pay for IP addresses or relinquish 
them. So, that's WHY people would pay for them..

The only problem I have with paying for IP addresses is - who would the 
money go to - but that's a separate issue.

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

From: "Jeroen Massar" <[email-masked]>
To: "'D. J. Bernstein'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: (ngtrans) including ipv4 address space into ipv6 address space
Date: Sat, 17 Nov 2001 02:17:28 +0100
Organization: Unfix
Importance: Normal
Sender: [email-masked]

D. J. Bernstein <[email-masked]> wrote:

> Jeroen Massar writes:
> > I only need 1 IPv4 IP which can do HTTP/SMTP/NNTP/FTP/etc.
> > proxy/gatewaying/etc. to the IPv6 world. Neeto huh?
> 
> Completely uninteresting. Every public server still has an IPv4
address,
> so your network is functionally identical to a standard IPv4 NAT
setup.
You can't call a new phone which can handle 128 numbers long
phonenumbers with an 'old' phone supporting only 32 numbers now can you?
And calling an old phone from a new phone will require a gateway system
which handles the old phone and the new phone.
But I already said that a couple of times.

> Meanwhile, despite heavy use of NAT, the available IPv4 address space
> seems to be disappearing. How do you propose solving this problem?
We don't. And if you look at the real numbers (free IPv4 space) there is
just enough IPv4 space left for the transition period between IPv4 and
IPv6.

> > But one time in the future we won't have any IPv4 addresses any more
> > and everything will be IPv6,
> 
> Aha! Now _that_ would be neat. If www.company.com can be 
> safely deployed on an IPv6 address, the problem described above will
vanish! 
> Wonderful. There are other reasons that, as a programmer, I'd like to
see this.
Please read Itojun's excellent "Implementing AF-independent application"
at http://www.kame.net/newsletter/19980604/ ) which reveals most
answers.
Maybe we will once see a 'native-tree' qmail supporting IPv6 or even
better AF independence, though it has ip_address struct ? :)

> But how exactly do we get to that situation? The current situation is
> that you'd have to be an idiot to rely on IPv6 for www.company.com.
How
> do we change this?
> 
> The underlying fact is that millions of Internet computers won't
connect
> to, and won't accept connections from, computers on IPv6 
> addresses. How do we change this?
> 
> These fundamental aspects of the IPv6 transition have been horribly
> mismanaged. Three examples:
> 
>    * Many network stacks and routers are providing ``IPv6 support,''
but
>      this ``support'' doesn't do anything unless the sysadmin takes
time
>      to configure it.
Well duh.... don't you have to configure a IPv4 router ?
But with IPv6 this is easier, just config your router to do rtsol's and
accept rtadv's from it's uplinks et tada it's configured.
Now you only have to give each downlink a portion of the IPv6 space it
gets from it's uplinks.

>      A small amount of extra effort would have provided an automatic
>      IPv6-over-IPv4 tunnel using an IPv6 address computed globally
from
>      the IPv4 address.
That's where 6to4 is for (2002:<ipv4>::/48) (RFC 3056).
For microsoft's stack that can easily be done by setting up the 'client'
host:
 - Install the IPv6 stack (on XP this translates into: 'start->run "ipv6
install")
 - 6to4cfg -b
et tada your done and every other stack also has this kind of
ease-of-use.

>    * A typical single-address server---for example, a small DNS server
>      answering queries on 131.193.178.181---has to set up a second
>      socket and pester the sysadmin for a second address if it's going
>      to answer IPv6 queries.
An IPv6 aware application could simply listen on [::/0]:<port> and
accept all connections there.
All depends on how/where one writes it's program.
For the 'IPv6 address pestering part', if it's a DNS server it probably
falls under the authority of the admin,
which if that admin setup his network correctly and did it the easy way
the server would simply rtsol an IPv6 address.

>      (Even if IPv6+IPv4 wildcards were supported by all IPv6 stacks,
>      they would be unacceptable for these applications. Many machines
>      have, for example, a DNS cache on one address, and a DNS server
on
>      another address. Same for SMTP servers.)
Would yet-another socket matter then ? ;)

>      A small amount of extra effort would have provided a unified
>      IPv6/IPv4 socket that accepts connections on 131.193.178.181
_and_
>      on the automatic IPv6 address described above, allowing these
>      common servers to support IPv6 with a minimum of fuss.
That currently depends on the stack.
Some stacks are mixed IPv4/IPv6 and some are IPv4&IPv6 in one.
Thus on some platforms/stacks a programmer needs to bind() only to IPv6
(and IPv4 comes in with the mapped way ::ffff::/96)
and on some to IPv6 and IPv4. (Yes, this is a not so very handy
situation but that's why there is that ./configure command ;)
 
>    * We're now being told that IPv4 sysadmins ``SHOULD'' take the time
>      to set up AAAA records for all their machines.
If you don't you simply won't have (easy) connectivity to the IPv6
world.
And today it's SHOULD, in a year or ten (or something ;) your boss says:
MUST.
Also if you don't want to do IPv6 then simply don't... but don't come
crawling back when you are to late with it.
Though as it really isn't that much work, except for some network
planning that shouldn't be a big problem.

>      A small amount of extra effort would have provided connectivity
>      from IPv6 clients to existing A records, through the tunnels
>      mentioned above.
NAT-PT... (RFC 2766):
"route -A inet6 ::ffff::/96 <nat-pt-gw-IPv6-address>" on your IPv6 only
machine.
done...

> In short, the transition cost is much larger than it needs to be.
Which 'costs' ?
The biggest 'cost' is the hardware, which you most of the time already
have for IPv4.
'Simply' upgrade your existing routers to support IPv6 et tada...
Or setup an *BSD/Linux/Solaris/etc... box and let that create a tunnel
into the IPv6 internet and have 'native' IPv6 on the LAN/WAN...

> People here seem to have lost sight of the problem that motivated IPv6
in the first place.
You mean the size of the address space?
You mean the easy of management?
You mean the decrease of global routes?
etc...
Those are luckily all nicely covered and if something is not they should
be addressed ASAP (read: yesterday).

Also a nice new draft came up today on the ietf lists called
"Application Aspects of IPv6 Transition" see:
http://www.ietf.org/internet-drafts/draft-shin-ngtrans-application-trans
ition-00.txt

I think this is covering most of this discussion.

Greets,
 Jeroen

Date: Sat, 17 Nov 2001 00:49:23 +0000
To: "D. J. Bernstein" <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>Meanwhile, despite heavy use of NAT, the available IPv4 address space
>seems to be disappearing. How do you propose solving this problem?

The obvious answer is to charge people for IP addresses rather than the 
current system of giving them away for free.

I'm convinced that lots of companies have loads more IP addresses than they 
really need. In the early days of the ARPANet/Internet, class A addresses 
were given to anyone who wanted them. I'm sure all those addresses aren't 
needed, but obviously the people who have them want to keep them since 
there's no reason for them not to,

Eg, I picked a number at random - 52.0.0.0/8. This is owned by 'dupont.com' 
who I'm sure are a wonderful company, but they 'only' have 85000 employees 
- why on earth do they need 16M IP addresses, even if each employee has 10 
PCs they've still got 15.9M spare addresses? They aren't an ISP so they 
aren't giving the addresses to other people.  There are other similar examples.

But if you start charging $10 per year per IP address, then anyone with a 
class A address who doesn't need it will give it back sharpish! (or even $1 
per year will still be $16M per year for a class A range..)

(Or maybe this is just me being naive...)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: 16 Nov 2001 20:48:04 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Sender: [email-masked]

Jeroen Massar writes:
> I only need 1 IPv4 IP which can do HTTP/SMTP/NNTP/FTP/etc.
> proxy/gatewaying/etc. to the IPv6 world. Neeto huh?

Completely uninteresting. Every public server still has an IPv4 address,
so your network is functionally identical to a standard IPv4 NAT setup.

Meanwhile, despite heavy use of NAT, the available IPv4 address space
seems to be disappearing. How do you propose solving this problem?

> But one time in the future we won't have any IPv4 addresses any more
> and everything will be IPv6,

Aha! Now _that_ would be neat. If www.company.com can be safely deployed
on an IPv6 address, the problem described above will vanish! Wonderful.
There are other reasons that, as a programmer, I'd like to see this.

But how exactly do we get to that situation? The current situation is
that you'd have to be an idiot to rely on IPv6 for www.company.com. How
do we change this?

The underlying fact is that millions of Internet computers won't connect
to, and won't accept connections from, computers on IPv6 addresses. How
do we change this?

These fundamental aspects of the IPv6 transition have been horribly
mismanaged. Three examples:

   * Many network stacks and routers are providing ``IPv6 support,'' but
     this ``support'' doesn't do anything unless the sysadmin takes time
     to configure it.

     A small amount of extra effort would have provided an automatic
     IPv6-over-IPv4 tunnel using an IPv6 address computed globally from
     the IPv4 address.

   * A typical single-address server---for example, a small DNS server
     answering queries on 131.193.178.181---has to set up a second
     socket and pester the sysadmin for a second address if it's going
     to answer IPv6 queries.

     (Even if IPv6+IPv4 wildcards were supported by all IPv6 stacks,
     they would be unacceptable for these applications. Many machines
     have, for example, a DNS cache on one address, and a DNS server on
     another address. Same for SMTP servers.)

     A small amount of extra effort would have provided a unified
     IPv6/IPv4 socket that accepts connections on 131.193.178.181 _and_
     on the automatic IPv6 address described above, allowing these
     common servers to support IPv6 with a minimum of fuss.

   * We're now being told that IPv4 sysadmins ``SHOULD'' take the time
     to set up AAAA records for all their machines.

     A small amount of extra effort would have provided connectivity
     from IPv6 clients to existing A records, through the tunnels
     mentioned above.

In short, the transition cost is much larger than it needs to be. People
here seem to have lost sight of the problem that motivated IPv6 in the
first place.

---Dan

To: [email-masked]
Xref: clerew local.mime:837
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Date: Fri, 16 Nov 2001 12:51:25 GMT
Lines: 41
Sender: [email-masked]

In <[email-masked]> "Jeroen Massar" <[email-masked]> writes:

>I only need 1 IPv4 IP which can do HTTP/SMTP/NNTP/FTP/etc.
>proxy/gatewaying/etc. to the IPv6 world.
>Neeto huh? And yes this is yet-another-kind-of-NAT. But one time in the
>future we won't have any
>IPv4 addresses any more and everything will be IPv6, though when that
>time comes is unforseeable at this moment.

OK, try the following scenario.

My house is full of gadgets, and I want an IP address for each of them -
my garage door, the TV, every light switch, my coffee machine, the cat
flap, the lot. Nobody is going to sell me a hundred or so IPv4 addresses,
so all I can get is IPv6 ones (we are told there are enough of them to
cover every square cm on the surface of the earth).

Damn. My ISP will only give me one IPv4 address to connect to the outside.
OK, I will devote one machine as my firewall/gateway, but I don't want to
do any of that NAT stuff (too much misuse of port numbers and so on). I
would far rather use whatever tunneling facilities are on offer.

Now my coffee machine has run out of coffee, and wants to make an ordinary
HTTP connection to Safeway to order some more. DNS gives it an Ipv4
address for Safeway but it can only understand IPv6 packets that come back
to it.

So what does the gateway machine have to do? Do the right protocols exist
to do whatever routing/tunneling is needed. Are these tools to be found in
Solaris 8 out-of-the-box?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: "Jeroen Massar" <[email-masked]>
To: "'D. J. Bernstein'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: (ngtrans) including ipv4 address space into ipv6 address space
Date: Thu, 15 Nov 2001 11:08:06 +0100
Organization: Unfix
Importance: Normal
Sender: [email-masked]

D. J. Bernstein <[email-masked]> wrote:

> Jeroen Massar writes:
> > Example.com is new and only gets a IPv6 subnet from
> > RIPE/APNIC/whatever for whatever reason.
> 
> At this point they're not connected to the Internet. Pretty damn
stupid,
> if they actually wanted Internet addresses.
Nopes, not stupid it's just a case example, which completely answers
your question
and handles any if not all problems you forseen.

> >             MX 20 mail-ipv4.example.com.
> 
> Okay. With the help of an SMTP proxy having an Internet address, a web
> proxy having an Internet address, etc., this company manages to
connect
> to the Internet. IPv6 is functionally identical to 10.* here.
You mean RFC1918 addresses with the help of NAT?
If you want I can tell you how to NAT 'real' IPv4 space too, see the
previous message.

> Now, some people have noticed a little problem with this picture,
which
> is that there are only a few billion Internet addresses. How would you
> suggest solving this problem?

I only need 1 IPv4 IP which can do HTTP/SMTP/NNTP/FTP/etc.
proxy/gatewaying/etc. to the IPv6 world.
Neeto huh? And yes this is yet-another-kind-of-NAT. But one time in the
future we won't have any
IPv4 addresses any more and everything will be IPv6, though when that
time comes is unforseeable at this moment.

The biggest point you are missing is the fact that there are 2
'internets' (the two clouds in my picture) which
though with some added help can communicate with each other.

If you can think up a great marvelous idea how to make sure IPv4 hosts
can reach any new extended address space be my guest.
It will be the same as telling a telephone made to handle 100 digits to
be able to handle 8000 digits -> you need to get a new telephone.

Case ('ipv4 admins only want to sit on their lazy asses') taken,
handled, no problems -> closed.

Greets,
 Jeroen

To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space 
From: [email-masked]
Date: Thu, 15 Nov 2001 03:28:17 -0500
Sender: [email-masked]

On Thu, 15 Nov 2001 02:15:08 GMT, "D. J. Bernstein" said:
> This effort provides a huge reward: a connection to the Internet! Email,
> the web, and so much more. (Despite this, people complain about the
> effort, and so we have all sorts of automatic configuration systems.)

Yes, but the fact that lots of people do it *without* automatic configuration
shows that your point of "it won't happen unless there's zero cost" is not
true in the real world.  People *will* invest effort if needed.
 
> Now, what exactly is my reward for spending time setting up useless IPv6
> addresses for my perfectly functional IPv4 machines?

The same reward as why people set up perfectly useless IPv4 addresses when
they had perfectly functional NCP addresses.  They saw a benefit to doing so,
even if not everybody agreed.

The same reward as why people install mail software that does RFC1894 status
notifications.  They saw a benefit to doing so, even if not everybody agreed.

Given that we have historic proof that companies are *more* than willing
to say "If you don't have a Flash plugin, we don't care if you take your
business elsewhere", or "If you don't have IE, we dont care", it may be
a very bad idea to blindly assume that they will keep supporting IPv4
customers after they've moved their own network to IPv6 for whatever reason.

Yes, a company will lose customers if they go to IPv6.  On the other hand,
if a company can save $250K a year by going to IPv6 and cleaning up their
NAT jungle across 35 branch offices, and they lose $150K in sales to people
who are neither IPv6-ready nor able/willing to use a proxy/gateway, they're
still $100K ahead,

/Valdis

Date: 15 Nov 2001 02:33:58 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Sender: [email-masked]

Jeroen Massar writes:
> Example.com is new and only gets a IPv6 subnet from
> RIPE/APNIC/whatever for whatever reason.

At this point they're not connected to the Internet. Pretty damn stupid,
if they actually wanted Internet addresses.

>             MX 20 mail-ipv4.example.com.

Okay. With the help of an SMTP proxy having an Internet address, a web
proxy having an Internet address, etc., this company manages to connect
to the Internet. IPv6 is functionally identical to 10.* here.

Now, some people have noticed a little problem with this picture, which
is that there are only a few billion Internet addresses. How would you
suggest solving this problem?

---Dan

Date: 15 Nov 2001 02:15:08 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Sender: [email-masked]

[email-masked] writes:
> How quickly do you think IPv6 would deploy if msn.com or aol.com
> provided <insert glitzy new product> as an IPv6 application?

Go ask Microsoft to move the MSN servers from IPv4 addresses to IPv6
addresses. Also ask them to switch all their public client addresses
from IPv4 to IPv6. See what they say.

An extension to the public Internet address space is a failure if the
extended addresses can't talk to the old addresses.

> This is the same sort of wishful thinking that says "the only hope for
> computer security is to make it work without any effort from the user".

To a first approximation, the only hope for computer security is to make
it work without any effort from the user. In fact, the most successful
security products are _easier_ to use than the systems they replace.

The main exception is that attacks against low-security systems provide
some economic incentives to switch. NSA's Brian Snow commented at a
recent conference that web-site defacements are great advertising for
his team's computer-security work. (I resisted the urge to ask him
whether NSA has paid for any of this advertising.)

> And even today, when you add a new system to the Internet, you often have
> to tell it it's IP address, it's netmask, it's default router, and the
> IP address of a nameserver.  Hardly "without any effort".

This effort provides a huge reward: a connection to the Internet! Email,
the web, and so much more. (Despite this, people complain about the
effort, and so we have all sorts of automatic configuration systems.)

Now, what exactly is my reward for spending time setting up useless IPv6
addresses for my perfectly functional IPv4 machines?

---Dan

To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space 
From: [email-masked]
Date: Wed, 14 Nov 2001 11:56:03 -0500
Sender: [email-masked]

--==_Exmh_746539722P
Content-Type: text/plain; charset=us-ascii

On Wed, 14 Nov 2001 02:00:30 GMT, "D. J. Bernstein" said:

> Speaking as an IPv4 administrator: _I_ don't have a problem. I have all
> the addresses I need. I can reach the entire Internet, and the entire
> Internet can reach me. I'm not going to waste my time setting up IPv6;
> everything useful is reachable through IPv4.

That's your right, of course.

Although there *is* one small flaw in the reasoning:

You *cant* reach the entire internet.  What you *can* reach is "the part
of the internet that you find useful at the current time".  This is very
different than "the entire Internet".

Mention the three letters 'N', 'A', and 'T' to Keith Moore ;)

> Nobody is going to do that. Consequently everything useful will
> _continue_ to be reachable through IPv4. In short, IPv6 is a failure.

Nobody is going to do that *until there's a reason to bother*.

How quickly do you think IPv6 would deploy if Gartner released a
nice 8.5x11 color glossy report that said IPv6 was The Next Big
Thing for business applications, because it allowed enough address
space so the problems with getting 2 NAT'ed networks to talk to
each other can be resolved?

How quickly do you think IPv6 would deploy if msn.com or aol.com
provided <insert glitzy new product> as an IPv6 application?

How quickly do you think IPv6 would deploy if Quake4 supported it?

> Perhaps _you_ have a problem with this situation. Perhaps you want IPv6
> to succeed. Your only hope is to make IPv6 work WITHOUT ANY EFFORT FROM
> THE IPV4 SYSTEM ADMINISTRATORS. You have to slip IPv6 support into the
> operating systems and applications and routers so that IPv6 works
> _automatically_ over the existing IPv4 infrastructure. Then you have to
> wait for everyone to upgrade.

This is the same sort of wishful thinking that says "the only hope for
computer security is to make it work without any effort from the user".

Oddly enough, a lot of sites manage to get their users to do things
like install anti-virus software and personal firewall software, even
though it requires *some* effort.

Now that Microsoft has shipped IPv6 in Windows XP, most of the major
players now have IPv6 in their current product (only players I can
think of that aren't are Apple's OSX and SGI's Irix).  Now, we *do*
still have to wait for the upgrade crank to turn before "most" people
have been upgraded to IPv6 capable, so there's still a 3-5 year wait
before it becomes *really* common.

On the other hand, RFC882 came out in November 1983.  The HOSTS.TXT is
known to have been in use at least until August 1990, and may have been
updated throught 1992.

And even today, when you add a new system to the Internet, you often have
to tell it it's IP address, it's netmask, it's default router, and the
IP address of a nameserver.  Hardly "without any effort".

But somehow, the Internet and DNS have not been classified as failures
due to the incredible amount of work involved to get connected.  Users
grumble, but they do it - they've at least mostly gotten used to the
idea that they will occasionally have to put in some effort to keep their
machines functioning (be it upgrading, or patching, or fixing a corrupted
registry, or finding somebody willing to do it for them).

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

--==_Exmh_746539722P
Content-Type: application/pgp-signature

--==_Exmh_746539722P--

Date: Wed, 14 Nov 2001 13:31:48 +0100 (CET)
From: Jeroen Massar <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Sender: [email-masked]

On 14 Nov 2001, D. J. Bernstein wrote:

> Jeroen Massar writes:
> > your decission... your problem...
>
> Speaking as an IPv4 administrator: _I_ don't have a problem. I have all
> the addresses I need. I can reach the entire Internet, and the entire
> Internet can reach me. I'm not going to waste my time setting up IPv6;
> everything useful is reachable through IPv4.

Lets do it again.... going from your perspective...:
(Oh if you want I can tell it in Shrek style... maybe that reads easier...)

Let's say you currently have IPv4 space and that it can reach
anything in the IPv4 world... which is a good thing.
Along with the fact that in the IPv4 world nobody has to do anything to
reach the IPv6 world.... and yups I could understand that point of view...

Then company Example.com comes along.... Example.com is new and only gets
a IPv6 subnet from RIPE/APNIC/whatever for whatever reason.

Thus Example.com is only reachable over IPv6 and you are only reachable
over IPv4....

As Example.com wants you as a customer they also want you (and the rest
of the IPv4 world) to be able to connect to them.

Them connecting to you is easy, Example.com makes sure it gets a route to
::ffff::/96 and let that gateway do the NAT-PT or other conversion to the IPv4 world.

So far so good... Example.com (IPv6) connecting to you (IPv4) works.

But as they also want the other way around they will need to do some
creative stuff.... for example take SMTP.... quite simple...:

Install a box somewhere with both IPv6 and IPv4 connectivity, install a
random MTA with support for IPv4 and IPv6 protocols which acts as a
relay...

example.com MX 10 mail-ipv6.example.com.
            MX 20 mail-ipv4.example.com.

mail-ipv6.example.com AAAA 3ffe:8114:2000:240::1
mail-ipv4.example.com A    10.100.13.42

Et tada..... example.com's SMTP is reachable by the IPv4 world.
(Which was wat itojun's draft was all about...)

HTTP is also something that's quite a requirement ofcourse... so the same
trick, install a proxy with IPv6 and IPv4 support and proxy it along to
the IPv6 box...

> There are millions of other people in the same situation. So you would
> have to be an idiot to make your company's public servers and clients
> reachable only through IPv6. You would be cutting yourself off from the
> Internet.
>
> Nobody is going to do that. Consequently everything useful will
> _continue_ to be reachable through IPv4. In short, IPv6 is a failure.
Remember IPX ??, OSI ??, slip ?? uucp ?? bitnet ?? hamradio ??
They all passed away some time or another and did it hurt? nopes...
Did it take some time? yups...
Did it use a gateway system? yups...

Quake over IPX...... Quake3 only does IPv4 TCP/IP... guess why the IPX is
out Quake 666 will nicely do IPv6 in time ;)

(Yeah yeah IPX is still in use and the others too, but you probably also
know of such translator/gateway service like KALI which allow you to put
those IPX bits over the TCP/IP line or even translate it to it...)

> Perhaps _you_ have a problem with this situation. Perhaps you want IPv6
> to succeed. Your only hope is to make IPv6 work WITHOUT ANY EFFORT FROM
> THE IPV4 SYSTEM ADMINISTRATORS.
See above... the only 'effort' is the fact that they should be 'open' to
the situation...

> You have to slip IPv6 support into the operating systems and applications
> and routers so that IPv6 works _automatically_ over the existing IPv4 infrastructure.
Ehmmmm AMS-IX (Amsterdam IX fyi) has native IPv6 support which nicely runs
along the IPv4 parts on the shared medium for some time now....
And there are some more IX'es also already doing this...

IPv6 has nothing to do with IPv4 except for the fact that their is a away
into IPv4 space with ::ffff::/96... and that it is a "we've learned from
the problems with IPv4" enhancement...

> Then you have to wait for everyone to upgrade.
See the comment above... people will upgrade when interresting things come
along... and as most modern OS's support IPv6 there should be no problem
there... or didn't you (re)install the last say 10 years?

People upgrade all the time... upgrading to IPv6 isn't that big of a
deal... and if you don't do it today... good for you wait another day...
If the move to IPv6 is really catching on you'll have to do it anywayz.

Nobody is forcing someone IPv6 onto them.... it's currently still in the
"Chicken and Egg" fase... not many hosts, not many apps... but the IPv4
world was that also in the beginning.... actually in the beginning there
was only sendmail on the SMTP side... look at it now... it will grow...
But it all depends on developers and the network guys to figure it out if
they are going to use it... but there are many companies deploying it..
It might take some time... but it's probably inevitable that there one day
will be only an IPv6 world...

Greets,
 Jeroen

Date: 14 Nov 2001 02:31:41 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Sender: [email-masked]

Keith Moore writes:
> for hosts that have v4 addresses and 6to4 support, there's no
> administrative hassle.  they can simply use 2002:[v4 addr]::1

We ``can simply use'' an IPv4-compatible address too. However, no matter
how simple you think it is, we---and millions of other people---are not
going to do it if it means spending precious system administrator time.
Sorry, Keith, but that's how the world works.

---Dan

Date: 14 Nov 2001 02:00:30 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Sender: [email-masked]

Jeroen Massar writes:
> your decission... your problem...

Speaking as an IPv4 administrator: _I_ don't have a problem. I have all
the addresses I need. I can reach the entire Internet, and the entire
Internet can reach me. I'm not going to waste my time setting up IPv6;
everything useful is reachable through IPv4.

There are millions of other people in the same situation. So you would
have to be an idiot to make your company's public servers and clients
reachable only through IPv6. You would be cutting yourself off from the
Internet.

Nobody is going to do that. Consequently everything useful will
_continue_ to be reachable through IPv4. In short, IPv6 is a failure.

Perhaps _you_ have a problem with this situation. Perhaps you want IPv6
to succeed. Your only hope is to make IPv6 work WITHOUT ANY EFFORT FROM
THE IPV4 SYSTEM ADMINISTRATORS. You have to slip IPv6 support into the
operating systems and applications and routers so that IPv6 works
_automatically_ over the existing IPv4 infrastructure. Then you have to
wait for everyone to upgrade.

---Dan

From: "Jeroen Massar" <[email-masked]>
To: "'D. J. Bernstein'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: (ngtrans) including ipv4 address space into ipv6 address space
Date: Wed, 14 Nov 2001 01:50:41 +0100
Organization: Unfix
Importance: Normal
Sender: [email-masked]

D. J. Bernstein <[email-masked]> wrote:
> Jeroen Massar writes:
> > the only thing that needs to be done for an IPv6 host is get a
> > routable IPv6 IP
> 
> Why should I do this manually? Why doesn't the software
_automatically_
> give me an IPv4-compatible IPv6 address, as explained in RFC 2893?
man rtadvd
man rtsold

Router Advertisements & Solicitations......
Which if your admins set the IPv6 routers up correctly will get you your
autoconfigged addresses...
And these tend to be globabaly routable (if set up correctly yadda yadda
yadda)

> Our system administrators are busy getting real work done. Do you
expect
> them to waste time figuring out how to join a useless network?
Maybe they should READ, LEARN and UNDERSTAND before trying to do
something ???

> Some of our computers and routers already have IPv6 software. But
we're
> not going to bother configuring those machines to talk to the global
> IPv6 network.
If you want to stay in your own cloud, ofcourse you can... your
decission... your problem...

> If you want IPv6 addresses to be part of the 
> Internet---if you want them to be reachable from machines like
ours---then 
> you have to give us software that does _not_ require extra
configuration for IPv6.

Are you completely clueless or something ????

---> Addresses need to be routable, either if they are IPv4 or IPv6
<----

And if that isn't the case ofcourse the other end isn't reachable....
well duhhh...

Greets,
 Jeroen

Date: 13 Nov 2001 21:35:27 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Sender: [email-masked]

Jeroen Massar writes:
> the only thing that needs to be done for an IPv6 host is get a
> routable IPv6 IP

Why should I do this manually? Why doesn't the software _automatically_
give me an IPv4-compatible IPv6 address, as explained in RFC 2893?

Our system administrators are busy getting real work done. Do you expect
them to waste time figuring out how to join a useless network?

Some of our computers and routers already have IPv6 software. But we're
not going to bother configuring those machines to talk to the global
IPv6 network. If you want IPv6 addresses to be part of the Internet---if
you want them to be reachable from machines like ours---then you have to
give us software that does _not_ require extra configuration for IPv6.

---Dan

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space 
Date: Tue, 13 Nov 2001 16:43:10 -0500
Sender: [email-masked]

> The question is whether hosts WITH IPV6 SOFTWARE also have to suffer the
> administrative hassle of obtaining new addresses---non-IPv4-compatible
> IPv6 addresses.

for hosts that have v4 addresses and 6to4 support, there's no administrative 
hassle.  they can simply use 2002:[v4 addr]::1

Keith

From: "Jeroen Massar" <[email-masked]>
To: "'D. J. Bernstein'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: (ngtrans) including ipv4 address space into ipv6 address space
Date: Tue, 13 Nov 2001 21:29:25 +0100
Organization: Unfix
Importance: Normal
Sender: [email-masked]

D. J. Bernstein <[email-masked]> wrote:

> Keith Moore writes:
> > a host that only supports IPv4
> 
> Irrelevant.
> 
> The question is whether hosts WITH IPV6 SOFTWARE also have to suffer
the
> administrative hassle of obtaining new addresses---non-IPv4-compatible
> IPv6 addresses.
If you even did look at the picture, you might have noticed that the
::ffff:<ipv4> gateway is "yet another router"
so...... the only thing that needs to be done for an IPv6 host is get a
routable IPv6 IP.... and make sure it gets a route to a router which
handles the ::ffff:<ipv4> range...

> Upgrading software can be painful, but it's not as painful as
upgrading
> software _and_ maintaining two sets of addresses.
Welps.... that's not required... as it's "yet another route"...

I hope that finally makes it all clear...

Greets,
 Jeroen

Date: 13 Nov 2001 18:50:55 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) including ipv4 address space into ipv6 address space
Sender: [email-masked]

Keith Moore writes:
> a host that only supports IPv4

Irrelevant.

The question is whether hosts WITH IPV6 SOFTWARE also have to suffer the
administrative hassle of obtaining new addresses---non-IPv4-compatible
IPv6 addresses.

Upgrading software can be painful, but it's not as painful as upgrading
software _and_ maintaining two sets of addresses.

---Dan

Date: Tue, 13 Nov 2001 11:56:30 +0900
From: Kenji Rikitake <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?
Sender: [email-masked]

I second the reality view of Dan Bernstein, and:

In the message <[email-masked]>
at Mon, Nov 12, 2001 at 09:09:17PM -0000,
"D. J. Bernstein" <[email-masked]> writes:
> Under the RFC 2893 transition plan, the existing IPv4 address space is
> included in the IPv6 address space. If this is done properly, it can
> entirely eliminate the administrative hassle.

And from the programming point of view, using IPv4-mapped IPv6 address
space (::ffff:/96, RFC2373 Section 2.5.4) can eliminate the issues on
running an IPv6 program on an IPv4-only node.  djbdns with this
modification runs happily on an IPv4-only environment, though it treats
IP addresses as uniformed 128bit integers internally.

As Dan writes, the IPv4 address space should be fully included in the
IPv6 address space.

// Kenji Rikitake

Date: 12 Nov 2001 21:09:39 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?
Sender: [email-masked]

Christian Huitema writes:
> As we transition to IPv6, we will see three kinds of nodes: a large
> part of the unreconstructed installed base will be IPv4 only, many
> hosts will be dual stack, and many others will only have IPv6
> connectivity.

The current reality is that people who ``only have IPv6 connectivity''
are not on the Internet. An ISP that tried to sell an IPv6 address as if
it were an Internet address would be laughed out of the marketplace. No
sane company would set up www.company.com reachable only through IPv6.
IPv6 addresses are vastly less useful than IPv4 addresses.

The magic moment in the IPv6 transition will be the moment when this
changes: the moment when typical Internet computers can talk to IPv6
addresses.

How do we make that happen? There are several big deployment problems:
upgrading network stacks; upgrading applications; upgrading routers. Do
we also have to suffer the administrative hassle of setting up an IPv6
address for every IPv4 machine?

Under the RFC 2893 transition plan, the existing IPv4 address space is
included in the IPv6 address space. If this is done properly, it can
entirely eliminate the administrative hassle.

If, on the other hand, the IPv4 address space is _not_ included in the
IPv6 address space, then the magic moment won't happen until the entire
IPv4 universe has acquired IPv6 addresses.

People who characterize IPv6-over-IPv4 tunneling as a local decision are
massively confused. The big benefit appears if _everyone_ includes IPv4
addresses in the IPv6 address space.

This is one of the most basic questions about the IPv6 architecture. It
should have been settled years ago.

---Dan

From: Keith Moore <[email-masked]>
To: "Christian Huitema" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, "D. J. Bernstein" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments? 
Date: Sun, 11 Nov 2001 09:24:49 -0500
Sender: [email-masked]

> We can safely assume that IPv6 only nodes will be able to access IPv4
> only services, e.g. by using a NAT-PT server provided by the IPv6
> network provider. 

I assume that IPv6 ISPs will provide various translation services
to allow their customers to access IPv4-only services; however, I
hope that NAT-PT is not imposed "by default".  This would greatly
increase the problems that are already caused by having multiple 
views of DNS at different sites.

> The converse is not true: there is no way an IPv4 only
> node can understand an AAAA record and associate it with an IPv4
> address. If the IPv6 node wants to provide services to the IPv4 only
> Internet, it must somehow obtain an IPv4 address and document it in the
> DNS. Depending of the service, we have three possibilities:
> 1) Basic services, e.g. HTTP & Telnet: document an IPv4 address in an A
> record for the server;
> 2) SMTP: document at least one IPv4 capable server in the MX list;
> 3) Services accessed through SRV records: document at least one IPv4
> capable server & corresponding port in the SRV list.

And SRV only works for applications that were designed to use it.

Keith

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments? 
Date: Sun, 11 Nov 2001 09:00:30 -0500
Sender: [email-masked]

> > *none* of the software (IP, TCP or application) supports IPv6
> 
> Funny. I thought we were discussing ``IPv6 SMTP requirements'': things
> that every MTA is going to have to do as part of the IPv6 transition.

I realize a lot of people have been using the word "transition".
I personally don't think that's a very useful way to think about it, 
because I don't think that anyone who is using IPv4 is going to
make any firm plans to discontinue using IPv4 anytime soon.
I prefer the term "coexistence".

However I do think that folks are going to be begin using IPv6,
that some of them will not have IPv4 connectivity, and that folks 
using IPv6 will want to exchange mail to folks using IPv4, and 
vice versa.
 
> Apparently you have a different goal. You want to work with existing
> MTAs. You want to work with MTAs that don't know anything about IPv6.
> 
> In that case, writing a spec is rather idiotic. You have to use the
> _existing_ protocols. You have to work with what the MTAs do _now_. In
> other words, you have to support IPv4.

Indeed.  But you don't have to support v4 at your own MTA if you can
find a MTA that is willing to be a mail exchanger for your incoming
v4 mail and one that is willing to relay your outgoing v6 mail.

One purpose of the spec is to describe what v6-only sites need to 
do to make this work well.  Another purpose of the spec is to 
describe how new MTAs (whether v4-only, v6-only, or dual-stack)
can work optimally given a mix of v4 and v6 MTAs. 

> Of course, as long as that's the situation, IPv6 is a failure. IPv6
> addresses will be functionally identical to 10.* addresses.  Users with
> these second-class addresses aren't actually on the Internet; they need
> application-level relays to talk to the Internet. Everyone will continue
> to compete for real Internet addresses: connected IPv4 addresses.

For the forseeable future, everyone will need some way to get access
to the major services that are IPv4-based: email, web, etc.  Many sites 
are already doing this with IPv4 NATs and/or application-level proxies 
so it's not difficult to conclude that this will continue to happen.
I expect that for a very long time most sites will get at least one IPv4 
address which can be used for such NATs or proxies to support legacy
applications.  However, there will also be large numbers of hosts that 
can only be directly accessed via IPv6, precisely because the availability
of large numbers of IPv6 addresses will make it possible to network those
hosts in a standard way, when due to the address shortage it is not possible 
to do this with IPv4.    And there will be applications that require use
of IPv6 because they cannot work with NATted IPv4.

It's misleading to speak of IPv6 addresses as "second-class".  IPv6 has a 
different domain of applicability than IPv4.  IPv6 makes it possible to
network a great many more devices than IPv4, and it also makes it possible
to run new kinds of applications.  I think it likely that we will see large 
numbers of IPv6-capable "appliances" - cameras, power meters, game hardware,
security systems, cell phones - anything that would benefit by remote 
control, monitoring, or access.  

IPv6 is a failure only if you expect it to replace IPv4 in a short time.
It's quite clear to all of us that this isn't going to happen.  But 
due to the address shortage and the presence of NATs, IPv4 is getting
less and less flexible and more and more difficult to use for new 
applications.  IPv6 will be successful because it lets us do things
that cannot be done with IPv4.

Keith

Date: 11 Nov 2001 02:18:49 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?
Sender: [email-masked]

Keith Moore writes:
> *none* of the software (IP, TCP or application) supports IPv6

Funny. I thought we were discussing ``IPv6 SMTP requirements'': things
that every MTA is going to have to do as part of the IPv6 transition.

Apparently you have a different goal. You want to work with existing
MTAs. You want to work with MTAs that don't know anything about IPv6.

In that case, writing a spec is rather idiotic. You have to use the
_existing_ protocols. You have to work with what the MTAs do _now_. In
other words, you have to support IPv4.

Of course, as long as that's the situation, IPv6 is a failure. IPv6
addresses will be functionally identical to 10.* addresses. Users with
these second-class addresses aren't actually on the Internet; they need
application-level relays to talk to the Internet. Everyone will continue
to compete for real Internet addresses: connected IPv4 addresses.

---Dan

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments? 
Date: Sat, 10 Nov 2001 20:02:00 -0500
Sender: [email-masked]

> Irrelevant. The only hosts under discussion are hosts where the software
> supports IPv6.

wrong.  we are talking about mechanisms which will allow IPv4-only
hosts to exchange mail with IPv6-only hosts, and the former
group includes hosts where *none* of the software (IP, TCP or 
application) supports IPv6.

Keith

Date: 10 Nov 2001 23:41:01 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?
Sender: [email-masked]

Keith Moore writes:
> IPv4-only hosts cannot communicate directly with IPv6-only hosts.

Irrelevant. The only hosts under discussion are hosts where the software
supports IPv6.

RFC 2893 explains how two of these hosts, one with an IPv4 address and
the other with an IPv6 address, can communicate with each other.

Naturally, the details include a mechanism for routing an encoded IPv6
packet through the IPv4 network to the IPv6 network. This is not rocket
science.

What you are proposing, whether you understand it or not, is a foolish
duplication of the same feature in every higher-level protocol, making
unnecessary work for application writers and system administrators.

---Dan

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments? 
Date: Sat, 10 Nov 2001 18:02:19 -0500
Sender: [email-masked]

Dan,

IPv4-only hosts cannot communicate directly with IPv6-only hosts.
This should be obvious to anyone who has read the specifications:
the packet formats are completely different . An IPv4-only host
will not understand IPv6 packets without a software upgrade, and 
even if an IPv6-only host had a means of sending packets to IPv4
hosts, an IPv4-only host would not be able to reply to them.

Depending on the application, translation between IPv4 and IPv6 
may be possible at either the IP level (by translating individual 
packets in a manner similar to NAT-PT) or at the application level 
(as in a SMTP MTA on a host with both IPv4 and IPv6 connectivity,
a simple TCP-to-TCP gateway that speaks IPv4 on one side and IPv6
on the other, or a simple SMTP-aware shim similar to that provided 
by some firewalls).  Any of these works for SMTP.  But for for the 
same reasons that some protocols do not work in the presence of NAT, 
a completely general translation between IPv4 and IPv6 - one that 
works for all applications - is impossible.

For SMTP operation, the method by which translation is done is 
generally irrelevant - either a packet translator box or a 
TCP translator or a dual-stack firewall or a dual-stack MTA will 
work just fine.  The only caveats I have identified so far are these:

1. if packets are received via a translator, received headers
will show an incorrect source address.

2. if there are two addresses for an SMTP server - one which is
routed via NAT-PT and another which goes directly to the server,
those two addresses should be listed as alternate addresses for
the same domain, rather than as separate domains, for the following
reasons:

- if a dual-stack relaying MTA is trying to send to that server
  and it responds with a "temporary failure" error, the relaying
  MTA should not immediately attempt to retry to the same host,
  but it might reasonably try to relay the message to a different
  mail exchanger.  if the relaying MTA sees multiple addresses 
  for the same MX domain it will know to fail over to  another 
  mail exchanger, but if it sees separate domains in separate
  MX records it may well fail over to the same host.

- similarly, if the relaying MTA is using STARTTLS and authenticating
  the SMTP server, the domain that appears in the server certificate
  should match the domain under which that MTA appears in the MX record.
  if the NAT-PT address and the actual address are listed under separate
  domains, this will fail for one case or the other.

However, if the same host that is used for an SMTP server is also
used to serve applications that are incompatible with NAT-PT, it
would cause problems for such applications for both the IPv4 and IPv6
addresses to be listed under the same domain, if that domain was used
by those applications.  for this reason it may be necessary to list
the same host under multiple domains.  for instance:

multi-purpose-server.example.com	IN A xxx.xxx.xxx.xxx

mail-server.example.com			IN A xxx.xxx.xxx.xxx
					IN AAAA YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY

example.com				IN MX 10 mail-server.example.com.

in this example, multi-purpose-server and mail-server are the same
host.  a translator has been set up which will translate between IPv4 
and IPv6 packets for traffic forwarded to and from the IPv4 address 
of this host.  incoming mail will get routed to mail-server.example.com 
either directly or via the packet translator, which is fine since 
SMTP (modulo received headers) doesn't have any problems with address
translators.  however other applications that do not work in the
presence of packet translators will need to use the 
multi-purpose-server.example.com domain name.

> Apparently there is some dispute about the RFC 2893 transition plan. Are
> IPv4 addresses going to be able to talk to IPv6 addresses, or is every
> existing Internet site going to have to acquire IPv6 addresses?

Neither.  IPv4-to-IPv6 packet level translation will be used in some cases
but it requires someone to set up a translator, and is not a general 
solution that works for all applications.  Nor does anybody who has
thought much about the problem believe that "every existing Internet site"
will acquire IPv6 support - at least, not very soon.  (however 6to4 makes
this fairly easy for any host that already has a global IPv4 address - 
an OS upgrade is all that is needed - so IPv6 is easier to deploy than 
many seem to think).

My view is that there will be a long period of coexistence, and the 
choice of (probably NATted) IPv4 or (non NATted) IPv6 will often 
depend on the particular application being used.

Keith

Date: 10 Nov 2001 21:17:31 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?
Sender: [email-masked]

Keith Moore writes:
>      the IPv4- or IPv6-only MTA may wish to employ one or more external 
>      "last resort" relays which can deliver to the other kind of MTA.

Under the RFC 2893 transition plan, hosts with IPv4 addresses can talk
to hosts with IPv6 addresses, so these SMTP relays are unnecessary.

Which makes more sense: configuring separate IPv6 relays for every
application, or configuring one relay for the network stack?

Apparently there is some dispute about the RFC 2893 transition plan. Are
IPv4 addresses going to be able to talk to IPv6 addresses, or is every
existing Internet site going to have to acquire IPv6 addresses?

I object to imposing IPv6 transition requirements on SMTP, or on any
other application, until these fundamental issues have been settled. I
am amazed that this group has not drawn a coherent picture of how the
IPv6 transition is supposed to work.

---Dan

Date: Fri, 9 Nov 2001 16:17:32 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?
Cc: Bob Fink <[email-masked]>, [email-masked], [email-masked], NGtrans List <[email-masked]>
Sender: [email-masked]

On 11/9/01 at 5:01 PM -0500, Keith Moore wrote:

>1. in the "summary of IPv4 MX operation",
>    both RFC 2822 section 5 and RFC 1035 should be referenced

Typo: RFC 2821, not 2822.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: Bob Fink <[email-masked]>
cc: [email-masked], [email-masked], NGtrans List <[email-masked]>
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments? 
Date: Fri, 09 Nov 2001 17:01:34 -0500
Sender: [email-masked]

okay, I have fairly extensive comments about this document.  most of them 
do not address specific text in the document, for reasons which I hope
will become apparent to those who are willing to wade through the text below.

executive summary: it's a very good idea to have a document like this, but
I recommend delaying the publication this document until it undergoes
some restructuring and/or having it co-edited by an email expert.

in the first place, you really need to allow for a mechanism by which
v4-only hosts can communicate with v6-only hosts in the absence of
MX records.  in the second place there are just too many subtleties 
involved in email routing to get this right by simple editing of the
current document.

---------------------------------------------------------------------------

1. in the "summary of IPv4 MX operation",
   both RFC 2822 section 5 and RFC 1035 should be referenced
   and the document should make clear to the reader that these 
   are the standard specifications for MX lookup.

   it is somewhat risky to re-state the algorithm in this document
   at all, because there are some subtleties to it.  and they only
   get worse when you add IPv6 in the mix.

2. because there is a lot of uncertainty about the relationship
   between IPv4 and IPv6, it would probably help if the document 
   were to state a few things up front:

   - IPv4 and IPv6 share a common domain name space.  a service
     or host named by a domain name may be reachable via IPv4,
     IPv6, or both.  subject only to differences in reachability,
     a service that is accessible via both IPv4 and IPv6 and which
     can operate using either, should not be affected by whether 
     it is accessed via IPv4 or IPv6.  since email can operate over 
     both IPv4 and IPv6 this principle holds for email -
     [email-masked] refers to the same recipient and mail box 
     regardless of whether the mail travels via IPv4 or IPv6 or
     a mixture of the two.

   - we explicitly assume that everybody wants to be able to send 
     mail to everybody, regardless of whether they are reachable
     via IPv4 or IPv6 or both.  to the extent that a sender or
     a receiver wishes to impose policy on who can send mail to whom, 
     we assume that IPv4 vs. IPv6 is not a factor in that policy.

   - we specifically want to make sure there are easy ways to
     exchange mail between IPv4-only and IPv6-only hosts.

     however, we should not assume that every mail domain that has IPv4
     access can get IPv6 access (even though with 6to4 this should be easy);
     nor should we assume that every mail domain that has IPv6 access
     can get IPv4 access.    

     it is therefore necessary to specify means by which IPv4-only
     hosts can send mail to domains that lack IPv4 connectivity;
     and by which IPv6-only hosts can send mail to domains that lack
     IPv6 connectivity.   

     it is worth remembering that the MX mechanism was created
     and originally used to handle a very similar case - providing
     a means for hosts without IP access to receive Internet email.
     for this reason, using MX to specify transit between IPv4 and 
     IPv6 turns out to be fairly straightforward.  however there
     are some subtle operational concerns that need to be mentioned. 

   - this specification can only apply to MTAs that implement it;
     it cannot affect pre-existing MTAs.  however it is permitted
     to affect new MTAs, even those that are run on IPv4-only hosts,
     and there are things that even an IPv4- or IPv6-only MTA can
     do to ease delivery to the other kind of host.

     in particular, 

     since IPv6 addresses can be looked up using IPv4 DNS queries, and
     IPv4 addresses can be looked up using IPv6 DNS queries, a new MTA
     can distinguish between "no addresses" and "no addresses
     which are reachable" and treat the two cases differently.
     
     the first is a DNS configuration error, and the second is the
     inability to find a route from source to destination.
     
     the IPv4- or IPv6-only MTA may wish to employ one or more external 
     "last resort" relays which can deliver to the other kind of MTA.

3. So here is (informally) how I would modify the MX routing algorithm:

    definitions:

    "relaying MTA" is the MTA which is attempting to relay a message

    "recipient domain" is the domain named in the recipient address

    "mail exchanger" or "MX" is a host which is listed in DNS as
    a mail exchanger for the recipient domain.  

    "remote MTA" is a message transfer agent running on a mail exchanger.

    "MX domain" is the domain name listed for a mail exchanger.

    "MX address" is any of the IPv4 or IPv6 addresses listed in DNS
     for an MX domain.

    so these are instructions for a relaying MTA:

   + if there are no MXes listed in DNS for the recipient domain  

     - an IPv4-capable relaying MTA SHOULD attempt to relay to each of
       the IPv4 addresses listed for the recipient domain (via A records), 
       until it finds one which will accept the message, or it gets a 
       permanent error from the remote MTA, or it times out.

     - an IPv6-capable relaying MTA SHOULD attempt to relay to each of the
       IPv6 addresses listed for the recipient domain (via AAAA or A6 
       records), until it finds one which will accept the message, or it 
       gets a permanent error from the remote MTA, or it times out.

     - a relaying MTA with both v4 and v6 connectivity SHOULD
       attempt to relay to each (v4 or v6) address listed in DNS for the 
       recipient domain (via A or AAAA or A6 records) until it finds one
       which will accept the message, or it gets a permanent error from
       the remote MTA, or it times out.

     - the order in which connections should be attempted within 
       a list of (v4 or v6) addresses obtained in this manner
       is unspecified, and MAY be a configurable parameter
       of the relaying MTA.

     - if a v4-only relaying MTA finds no v4 addresses, or a v6-only 
       relaying MTA finds no v6 addresses, the relaying MTA MAY relay 
       such traffic to an explicitly-configured "external" MTA which 
       has connectivity to the other kind of IP and which has agreed 
       to forward traffic from the sending host or network to recipients 
       using the other kind of IP.  if no external relay has been configured, 
       the message should be bounced with an "5.4.4" (unable to route) 
       error.  if the external relay were unreachable after several attempts 
       and the relaying MTA gave up, the message should be bounced with a 
       "4.4.1" (no answer from host) or "4.4.2" (bad connection) error,
       as appropriate.

     - if no addresses of any kind were found for the recipient domain, 
       this would be a "5.1.2" (bad destination system address) error.  
       (this is exactly what you should get in an IPv4-only world if you 
       try to send to a recipient at a domain without any MX or A records 
       listed for that domain.)

       note however a subtlety - if any of the A or AAAA or A6 lookups 
       failed for temporary reasons - such as no response from any DNS 
       server - the condition would be treated as a temporary error,
       and the MTA should retry at a later time until it decided to give
       up.  under such conditions the error should be "4.4.3 (directory
       server failure)"

   + if there is at least one MX listed in DNS for the recipient domain,

     - sort the MX list according to increasing preference

     - attempt delivery to each of the MX domains in order of
       increasing preference, until either
       
       - the list of domains is exhausted
       - the message is accepted by the remote MTA 
       - the message is rejected by the remote MTA with a permanent
         failure error.

    - for each domain in the ordered MX list the relaying MTA SHOULD
      attempt to contact an SMTP server at that domain using 
      all IPv4 or IPv6 addresses listed for the remote MTA which are 
      reachable by the relaying MTA.  within a particular domain on the 
      ordered MX list, the order in which the (IPv4 or IPv6) addresses 
      are chosen is unspecified, and MAY be a configurable parameter
      of the relaying MTA.   

      however, precedence SHOULD be followed.  so a relaying MTA which
      has both IPv4 and IPv6 connectivity SHOULD attempt to deliver
      to a MX domain with lower preference before attempting to deliver
      to an MX domain with higher preference, even if the one with higher
      preference has better connectivity or the one with lower preference
      lacks the kind of connectivity preferred by the relaying MTA.

    - if after exhausting the list of MX domains, a relaying MTA 
      with only IPv4 connectivity finds there were only IPv6 MX 
      addresses, or a relaying MTA with only IPv6 connectivity
      finds that there were only IPv4 MX addresses, the relaying MTA
      MAY relay the message to an explicitly-configured, "external" 
      MTA which has connectivity to the other kind of IP and
      which has agreed to relay such traffic for the sending host.
      if no external relay has been configured, the message should be
      bounced with an "5.4.4" (unable to route) error. if the external 
      relay were unreachable after several attempts and the relaying 
      MTA gave up, the message should be bounced with a "4.4.1" (no 
      answer from host) or "4.4.2" (bad connection) error, as appropriate.

    - if no addresses of any kind are available (meaning that 
      lookups on each of the MX domains return no address records
      of any kind), the "5.4.3" (directory server failure) error is 
      the closest defined code for this condition.  (this is a 
      misconfiguration of DNS rather than a malfunction, and 5.4.3
      is really intended for malfunctions.  ideally there would be 
      a separate code to distinguish directory misconfiguration from 
      directory server malfunction)

      "5.1.2" SHOULD NOT be used for this case.  If no MX records
      exist for a recipient domain, and no address records exist for 
      that domain either, then it can be assumed that the domain is not 
      intended for use in email addresses.  However, if one or more MX
      records exist for a recipient domain then it is reasonable to
      assume that the domain is intended to be valid for email addresses, 
      and that there has been a failure of the zone administrator to 
      provide address records for those MX domains.

4. with the above in mind, it is possible to construct operational 
   recommendations for senders and receivers to maximize the potential
   for exchanging mail between IPv4 and IPv6:

- all sites:

  it is RECOMMENDED that all sites employ MTAs which meet these
  recommendations for v4/v6 mail routing, even if the site only
  supports IPv4 or IPv6 connectivity.

  the primary burden on a site that wishes to be receive mail from 
  IPv4 hosts is to provide at least one MX with v4 connectivity and to 
  list those MXes and their IPv4 addresses in DNS.

  similarly, the primary burden on a site that wishes to receive mail
  from IPv6 hosts is to provide at least one MX with v6 connectivity
  and to list those MXes and their IPv6 addresses in DNS.  (note that
  any site with IPv4 connectivity and global IPv4 addresses can 
  establish IPv6 connectivity using 6to4 without needing to establish
  a separate  connection)

  any other means of routing mail between v4 and v6 sites should be
  considered a secondary, rather than a primary, mechanism.

- v6-only sites:

  it is RECOMMENDED that v6-only sites provide at least one MX
  for their recipient domains which is reachable via IPv4.
  this MX MAY be external to the recipient site.

  if it is desired to use this MX only when the sender has no v6 
  connectivity, the MX which accepts v4 traffic can be listed with 
  a higher preference than all other MXes.

  this MX *must* either have some reliable means to relay mail to the 
  primary MX server, or it must otherwise handle incoming mail equivalently 
  to the primary MX server.  the mechanism by which this is accomplished is 
  unspecified.  one mechanism which will work is to provide at least
  one dual-stack MTA with both v4 and v6 connectivity as a mail exchanger.
  other mechanisms may also be feasible.

  it is RECOMMENDED that v6-only sites find some means of reaching 
  v4-only MTAs, by routing all externally-bound v4-only mail to an 
  external MTA which has agreed to relay such traffic.

  realistically, given the "head start" that IPv4 mail has had over 
  IPv6, it will generally be necessary for IPv6 sites to make arrangements
  for *both* incoming and outgoing IPv4 mail transfer.

- v4-only sites:

  it is RECOMMENDED that v4-only sites provide at least one MX
  for their recipient domains which is reachable via IPv6.
  this MX MAY be external to the recipient site.

  if it is desired to use this MX only when the sender has no v4
  connectivity, the MX which accepts v6 traffic can be listed with 
  a higher preference than all other MXes.

  this MX *must* either have some reliable means to relay mail to the
  primary MX server, or it must otherwise handle incoming mail equivalently 
  to the primary MX server.  the mechanism by which this is accomplished is
  unspecified.  one mechanism which will work is to provide at least
  one dual-stack MTA with both v4 and v6 connectivity as a mail exchanger.
  other mechanisms may also be feasible.

  (note that any site with v4 connectivity and globally-usable addresses
  can establish Ipv6 connectivity for such an MX, without needing to
  set up a separate connection, using 6to4.)

- sites with both IPv4 and IPv6 connectivity

  it is RECOMMENDED that sites with IPv4 and IPv6 connectivity provide
  one or more MXes that are reachable by v4 and one or more MXes that
  are reachable by v6.  

  these MXes MAY be located on the same, or different, hosts.  however, 
  different hosts supporting MTAs SHOULD be listed under different 
  domains.  all of the v4 or v6 addresses listed for a particular MX 
  domain SHOULD reach same host.  (this is needed for fail-over from 
  one SMTP server to another to work correctly)

- ISPs

  ISPs are encouraged to provide mechansisms to:

  - allow their IPv4-only customers to send mail to IPv6-only sites
  - allow their IPv6-only customers to send mail to IPv4-only sites
  - allow their IPv4-only customers to receive mail from IPv6-only sites
  - allow their IPv6-only customers to receive mail from IPv4-only sites

  support for outbound mail (from the ISP's customers to sites that
  would otherwise be unreachable) MAY be implemented by the ISP
  providing one or more external MTAs which can relay mail from the 
  customer's network to a destination network which would otherwise be 
  unreachable by the customer.  due to spamming and other concerns, 
  such MTAs SHOULD NOT be configured (or expected) to handle traffic 
  from arbitrary sources to arbitrary destinations, but ONLY cross-realm 
  (v4 to v6 or vice versa) traffic from that ISP's customers.  it would 
  be reasonable for the ISP to require that a standard (non-proprietary) 
  SMTP AUTH mechanism be used to verify the customer's authenticity. 

  other mechanisms for providing that connectivity might also be feasable.  

  if an ISP provides outgoing cross-realm relaying for its customers,
  each customer must configure its own MTAs to use those relays.
  ISPs MUST NOT modify DNS responses to automatically include such MXes
  in the results seen by customers' MTAs.

  support for inbound mail (to the ISP's customers) can be provided by
  the ISP providing one or more MTAs that are willing to act as secondary 
  mail exhangers for the ISP's customers, and which the customer advertises
  in its DNS records.  these MTAs MAY be ordinary MTAs with dual-stack
  capability, or they MAY be v4-to-v6 (or vice versa) protocol translators
  which are explicitly configured to reach the customer's MTA.
  
  such MTAs SHOULD NOT be configured (or expected) to handle traffic from 
  arbitrary sources to arbitrary destinations, but ONLY cross-realm (v4 
  to v6 or vice versa) traffic destined for that ISP's customers.  
  in order to prevent this from being exploited by spammers, it would be 
  reasonable for the ISP to assign a separate address and domain per 
  customer to be used for such purposes, and or MTAs provided by the
  ISP to refuse to accept incoming mail that did not have the proper
  destination IP address for that customer.

  if an ISP provides incoming cross-realm MX relaying for its customers,
  each customer must configure its own DNS zones to use those MXes.
  ISPs MUST NOT modify responses from customers' DNS servers to automatically
  include such MXes.

--------------------------------------------------------------------------

*whew*

I don't claim to have all of the above details correct, but I think that
the *right* solution looks more-or-less like this.  and I do think we
need to specify about this level of detail.  

I don't think that we can expect all customers to provide their own MXes
for both IPv4 and IPv6, and I don't think we can come up with a 
"one size fits all" solution for connectivity.  ISPs will in some cases
need to bridge the gap, but they are often in a good position to know
what their customers need.

Keith

Date: Fri, 09 Nov 2001 08:15:27 -0800
To: [email-masked], [email-masked]
From: Bob Fink <[email-masked]>
Subject: Re: ipv6-smtp-requirement comments?
Cc: NGtrans List <[email-masked]>
Sender: [email-masked]

Various SMTP list folk,

Itojun has issued the following in response to various comments on his 
"ipv6-smtp-requirement" I-D that was about to be forwarded to the IESG for 
Informational RFC.

The ngtrans chairs would like to forward this new -04 draft (see url below) 
to the IESG, but wish to have any response to this you may have first.

Please forward comments to the ngtrans list (cc'd above) by next Friday, 
November 16.

Thanks,

Alain Durand / Bob Fink / Tony Hain
ngtrans chairs

======
	Hello, this is about draft-ietf-ngtrans-ipv6-smtp-requirement.

	After getting comments from SMTP community (a couple of SMTP-related
	mailing lists), I have submitted a new revision of
	draft-ietf-ngtrans-ipv6-smtp-requirement (now 04).   It should be in
	the internet-draft repository as soon as editors do their thing.
	Comments and actions taken are summrized below.
	The changes are minor, and I don't think it necessary to go through
	ngtrans last call again.

itojun

- English needs to be improved
	the document went through proofread by a native English speaker
	(JJ Behrens of NTT MCL).
- the SMTP sender algorithm should be clarified a bit
	tweaked it a bit, added reference to relevant IPv4-only RFC
	(RFC2821) to make it clearer
- need to talk about situations where IPv4-only sender tries to deliver
   an email to IPv6-only MX
	added a little bit of text.

===
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group 
of the IETF.

	Title		: IPv6 SMTP operational requirements
	Author(s)	: M. Nakamura, J. Hagino
	Filename	: draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
	Pages		: 8
	Date		: 08-Nov-01
	
This document lists operational requirements for IPv6 SMTP and
IPv6-capable MX DNS records.  As IPv6 SMTP servers are deployed, it has
become apparent that certain configurations are necessary in
IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP
operation.  This document clarifies the problems that exist in the
transition period between IPv4 SMTP and IPv6 SMTP.  It also defines
operational requirements for stable IPv4/v6 SMTP operation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt

-end