Subject: RE: (ngtrans) Re: ipv6-smtp-requirement comments?

From: "Christian Huitema" <[email-masked]>
Date: Sat, 10 Nov 2001 23:37:08 -0800

> > 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.

That is indeed the problem. 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. We should agree that the burden of transition is
on the IPv6 nodes, and possibly also on the IPv6 network providers:
during the initial phase, a large number of services will be IPv4 only,
and many IPv4 nodes will be hard to upgrade.

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. 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.
As Keith points out, there are three generic ways of providing the IPv4
capable servers in such lists: a version of NAT-PT in which an IPv4
address & port combination is wired to the corresponding address and
port of the IPv6 only server; the same using back to back TCP
connections; and an application level gateway. 

The ALG approach is the most economical, since one gateway using a
single IP address can serve multiple IPv6 domains. It is only possible
when the application protocol passes enough information, which hopefully
is the case of SMTP (complete e-mail address of recipients) and the
latest versions of HTTP (using the Host: header).

The second most economical approach is the use of SRV records, in which
case multiple ports on a single IPv4 address can be mapped to many IPv6
services. Too bad we cannot do it for either HTTP or SMTP...

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Nov 2001 09:24:49 -0500

> 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

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

Keith

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Nov 2001 08:16:03 -0800

Christian Huitema" <[email-masked]>
> only services, e.g. by using a NAT-PT server provided by the IPv6

actually, as this wg is responsible for thinking out the whole 'transition'
we probably need to think out that time when our grandchildren live in a
mostly v6 world and services need to interact with some small legacy v4
sites/hosts.

in general, it would be useful to lay out the stages through which we think
transition will go.  then, when discussing things such as smtp services, we
can understand how they will work at all stages.

From: Keith Moore <[email-masked]>
> 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.

i suspect the MX will help the smtp transition.  but there are no MX RRs
for other services.  SRV might help in some more cases, though we could
run into issues with the selection algorithm.  and i suspect that the dns
is not going to bail out every problem.

randy

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 11 Nov 2001 11:01:51 -0600

With respect to Children and IPv6....

You might want to study "The IPv6 Privacy Problem".
http://www.google.com/search?q=IPV6+Privacy+Problem
IPv8 Addressing solves that problem

Jim Fleming
http://www.IPv8.info

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Nov 2001 18:58:05 -0500

> mostly v6 world and services need to interact with some small legacy v4

that would seem to be far easier than making v6-based hosts/services
accessible to v4 - since there's no shortage of v6 addresses you can
simply assign a separate v6 address to each v4 host/service that needs
to be accessed from v6 and provide a packet translator, stream translator,
or ALG as appropriate.   there's no need to de-multiplex at the application
layer or play NAPT-style games with DNS.
 
Keith

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Nov 2001 16:04:24 -0800

> layer or play NAPT-style games with DNS.

as the v6 world starts, it hides behind nats.  but our grandchildren could
be in a world where those nats are not universal.  and the v4 folk can not
be assumed to put up v6 translators.  so where do you think the v4 nats
will be late in the game?

randy

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Nov 2001 20:13:20 -0500

> will be late in the game?

I'm actually not sure that the v6 world will start out hiding behind NATs -
it seems more likely to me that we will use v6 for a different set of 
applications than v4, and we will develop application-level solutions 
for those services must be accessible from both worlds.

as for translators that make legacy v4 devices accessible from v6 -
I suspect that by the time we are ready to abandon v4, general purpose 
devices will have been upgradable to dual-stack for a long time.
the less-adaptable appliances (printers, etc) will either be obsolete
by then, or we will have small "inline" single-device v4-to-v6 packet 
translators.  They might well have the form factor of a barrel or 
junction connector, be powered by the transmission line, and handle all of 
the network configuration automagically.  though such devices would in
some sense be NATs or NAT-PTs they would be far less complex than the v4 
NATs of today, since they wouldn't have to do any multiplexing or 
per-connection state management.  I don't think our grandchildren 
(if it takes that long before they are needed)  will find it difficult
to develop such things.

I suspect there will be a market for such translators among v4 folk  -
first because v4 folk will have some reasons to run v6 also
(in order to gain access to new v6-based applications) and because
at some point it will make sense to move everything to v6 in order
to simplify management.  

Keith

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Nov 2001 17:22:51 -0800

> I'm actually not sure that the v6 world will start out hiding behind NATs
> - it seems more likely to me that we will use v6 for a different set of
> applications than v4, and we will develop application-level solutions for
> those services must be accessible from both worlds.

sorry.  the v6 world already has begun behind nats.  as to the different set
of applications, the future tense is appropriate.

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Nov 2001 20:47:50 -0500

> sorry.  the v6 world already has begun behind nats. 

do you mean NAT-PT, or v6 NATs?

I'm not surprised if very early deployment of v6 uses NAT-PT, because there
aren't very many interesting v6-accessible services yet.  but I expect that 
this will not be a typical use of IPv6, because  NATted v4 seems more 
attractive to customers than v6 with NAT-PT.
 
> as to the different set of applications, the future tense is appropriate.

such applications exist today - they don't work over NATted v4 
I'm guessing that the users of such applications will find that they
can work well over IPv6, and this will help drive deployment of v6
but this is just speculation.

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 11 Nov 2001 20:10:15 -0600

----- Original Message -----
From: "Randy Bush" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, November 11, 2001 7:22 PM
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?

> > applications than v4, and we will develop application-level solutions
for
> of applications, the future tense is appropriate.

That sounds like a private intranet, that is not connected the "the
Internet".

[email-masked]
http://www.unir.com
http://www.unir.com/images/architech.gif
http://www.unir.com/images/headers.gif
http://www.unir.com/images/address.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp
http://www.ietf.org/mail-archive/ietf/Current/msg12213.html
http://www.ietf.org/mail-archive/ietf/Current/msg12223.html

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 12 Nov 2001 08:14:02 -0600

----- Original Message -----
From: "Randy Bush" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, November 11, 2001 7:22 PM
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments?

for
> of applications, the future tense is appropriate.

http://www.wwtld.org/progress_report2.html
10 October 2001:  ccTLD Network of Secondary Server was discussed and
decided that the ccTLD constituency should go forward with the so-called
"ccTLD Next-Generation Server Cluster" as an experiment.   A small committee
will be set up to explore the possibility of setting up a cluster of ccTLD
secondary servers.

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 Nov 2001 21:09:39 -0000

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: "Jim Fleming" <[email-masked]>
Date: Mon, 12 Nov 2001 15:23:15 -0600

----- Original Message ----- 
From: "D. J. Bernstein" <[email-masked]>
> should have been settled years ago.

What "IPv6 architecture" ??? No one seems to have a picture of it.

[email-masked]
http://www.unir.com

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 13 Nov 2001 01:43:27 +0100

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

Look at the bottom for a link to a nice explainatory picture... about
IPv6 and IPv4 communications.

> address for every IPv4 machine?
That's one of the good things of IPv6..... Router Solicitations ;)
And ofcourse the upcoming IPv6 capable DHCPv6... which also takes care
of DNS servers and other configurations (just like in the IPv4 world)
Though I like rtsol somewhat better... only thing missing is the DNS
servers which you don't get with them... but alas... :)

At this moment I can move my IPv6 enabled box to any network which has
an IPv6 enabled router in it,
then simply plug it in and... tada... the router advertisements will
give me an IP address and routes will get configured...
and I can have much fun... and fun is a good thing... especially if I
didn't have to do squat for it.

> entirely eliminate the administrative hassle.
Indeed... and it is... any IPv6 enabled application trying to contact
::ffff:192.168.42.13 for example
will simply be routed to the router which is dual homed and which will
do the NAT-PT process transaparently for both the remote IPv4 and the
local IPv6 machine.
No IPv4 on the local machine is needed for that... just one router
playing as NAT-PT...

> IPv4 universe has acquired IPv6 addresses.
::ffff:<ipv4> takes care of that...

> addresses in the IPv6 address space.
Tunneling, both 6to4 and 6in4, is just a yet another way to get one
connected....
People use IPv4-in-IPv4 tunneling too to get things done.

> should have been settled years ago.
It is settled.... some people simply don't see the light yet...

But to shed some light on this dark forest, I'd suggest everyone to
check the following picture which I created just to get rid of all these
strange questions...
http://unfix.org/projects/ipv6/IPv6andIPv4.gif

It nicely (at least I hope ;) illustrates:
 - IPv6 to IPv4 traffic using NAT-PT
 - IPv6 in IPv4 to IPv6 traffic using 6to4 and 6in4
 - IPv4 to IPv6 traffic using winsock5/6tunnel/...
 - native IPv6 well duh ;)
 - native IPv4 duh again...

I didn't take time to note the various RFC's which explain how
everything is implemented but those can be found quite easily at
www.faqs.org or similar sites.

If anyone, probably many will, have some comments/questions.... you know
my address... ;)

Greets,
 Jeroen

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 12 Nov 2001 19:11:20 -0600

Can we assume this it the "official" ICANN and IETF Architecture Picture ?

-----------------------------------------------------
From: "Jeroen Massar" <[email-masked]>
>  - native IPv4 duh again...
-----------------------------------------------------

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 Nov 2001 20:04:58 +0200 (EET)

> ::ffff:<ipv4> takes care of that...

Is it me or you that are confused, but I think you're describing SIIT, not 
NAT-PT?  AFAICS, in NAT-PT these would be 'PREFIX::<IPv4>'.

Personally, I'd never want to see mapped addresses on the wire.

-- 
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: Kenji Rikitake <[email-masked]>
Date: Tue, 13 Nov 2001 11:07:04 +0900

I second the reality view of Dan Bernstein, and:

In the message <[email-masked]>
at Mon, Nov 12, 2001 at 09:09:17PM -0000,
> 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