Subject: Enhanced SIIT

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Oct 2007 13:19:48 +0200

After a half serious post to the IETF list I decided to write a quick  
draft about the following:

Abstract

   This document describes an extension to the mechanism outlined in RFC
   2765 that allows IPv4 hosts to communicate with IPv6 hosts through a
   protocol translation device with full IPv6 compatibility.

   For this purpose, a new header is inserted between the IP header and
   the payload protocol such as TCP and UDP. The new header contains the
   bits truncated from the IPv6 address when the IPv6 address is
   translated into an IPv4 address in the 240.0.0.0/4 (class E) range.

http://www.muada.com/drafts/draft-van-beijnum-v6ops-esiit-00.txt

(I have no patience with the IETF tools right now, will retry that  
later.)

The idea is that hosts with IPv4 connectivity get to talk to IPv6  
hosts without anything NAT-like getting in the way. However, it does  
require some changes on the IPv4 side, but these can be deployed  
incrementally. The assumption is that these changes would be easier  
to deploy than a full IPv6 transition.

I would really like some feedback on whether this is something useful  
that deserves more attention or not.

---

From: "Todd T. Fries" <[email-masked]>
Date: Wed, 17 Oct 2007 07:51:02 -0500

My personal opinion is that if you require updating IPv4 hosts why not just
update them to IPv6 stack?  The duct tape and band-aids on IPv4 this draft
calls forth is sick at best in my opinion.

FWIW.
-- 
Todd Fries .. [email-masked]

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  1.700.227.9094 (IAXTEL)
|                                             \          250797 (FWD)
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Penned by Iljitsch van Beijnum on 20071017 13:19.48, we have:
| After a half serious post to the IETF list I decided to write a quick  
| draft about the following:
| 
| Abstract
| 
|   This document describes an extension to the mechanism outlined in RFC
|   2765 that allows IPv4 hosts to communicate with IPv6 hosts through a
|   protocol translation device with full IPv6 compatibility.
| 
|   For this purpose, a new header is inserted between the IP header and
|   the payload protocol such as TCP and UDP. The new header contains the
|   bits truncated from the IPv6 address when the IPv6 address is
|   translated into an IPv4 address in the 240.0.0.0/4 (class E) range.
| 
| http://www.muada.com/drafts/draft-van-beijnum-v6ops-esiit-00.txt
| 
| (I have no patience with the IETF tools right now, will retry that  
| later.)
| 
| The idea is that hosts with IPv4 connectivity get to talk to IPv6  
| hosts without anything NAT-like getting in the way. However, it does  
| require some changes on the IPv4 side, but these can be deployed  
| incrementally. The assumption is that these changes would be easier  
| to deploy than a full IPv6 transition.
| 
| I would really like some feedback on whether this is something useful  
| that deserves more attention or not.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Oct 2007 09:49:06 +1300

On 2007-10-14 06:28, Jari Arkko wrote:
> Thanks for this, Olaf. Indeed, we are considering follow-up work,
> and understanding the scenarios & possible need for producing
> a revised version of NAT-PT is on the Vancouver agenda (currently
> planned to be a discussion in V6OPS, with protocol work to fall
> out to an INT area WG).

In my opinion we have to be very systematic about this. The only way
that we can avoid the intrinsic problems of stateless translation
seems to be to have awareness at the IPv6 end that translation is
happening. (The underlying problem is how to reach legacy IPv4
hosts, who by definition can have no such awareness). That seems to
mean getting rid of the "less" in "Stateless IP/ICMP Translation",
so I think we need to go back to basics. I don't have any specific
proposals in mind, but I'm pretty sure that signalling between
the translator and the IPv6 host will be needed.

     Brian

---

From: Geoff Huston <[email-masked]>
Date: Thu, 18 Oct 2007 07:29:26 +1000

This is something potentially useful that I think deserves further 
review  - simply because the approach appears to provide the ability to 
use a stateless transform of the protocol header in the network.

It its current formulation it requires host protocol stack surgery, but 
it you look past the precise details and think about the essential 
differences between NATs with explicit bindings and held state and 
algorithmic transforms that do no require kept state then there is 
something here that could be a useful starting point.

So I'm of the view that it merits a little further attention.

Geoff

Iljitsch van Beijnum wrote:
> (I have no patience with the IETF tools right now, will retry that later.)
> 
> The idea is that hosts with IPv4 connectivity get to talk to IPv6 hosts 
> without anything NAT-like getting in the way. However, it does require 
> some changes on the IPv4 side, but these can be deployed incrementally. 
> The assumption is that these changes would be easier to deploy than a 
> full IPv6 transition.
>

---

From: Alain Durand <[email-masked]>
Date: Wed, 17 Oct 2007 15:35:08 -0600

> the translator and the IPv6 host will be needed.

We have been studying network-triggered translation vs end-device-triggered
translation. One thing that came out of that study is what happen when the
translator in the middle fails. If you have a model where mappings are
triggered by the end-devices, you are going to create a storm of mapping
requests to the fall-back translator.

   - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Oct 2007 10:56:40 +1300

> requests to the fall-back translator.

Yes, that seems correct. I don't see any reason why translation
should be initiated by the IPv6 host, but on the other hand, do
we want the translator to be a single point of failure?

    Brian

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 18 Oct 2007 13:35:44 +1000

> requests to the fall-back translator.

=> I don't know if anyone remembers this draft by Eirk and I some 7 years
ago:
http://tools.ietf.org/html/draft-ietf-ngtrans-siit-dstm-01

It did maintain the statelessness of the translator. The concern at the time
was that
allocating addresses based on external triggers (DNS lookup from some node
on the Internet)
was a serious DoS attack. But even if you remove that feature/bug, the  rest
of the draft still applies today, given a mechanism of allocating an IPv4
address to the IPv6 host. At the time we chose DSTM, but any mechanism would
work. I think it can be a good reference if the WG still wants to work with
translators.

Hesham

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Oct 2007 10:04:54 +0200

On 17-okt-2007, at 22:49, Brian E Carpenter wrote:

> happening.

Note that my draft goes in the opposite direction and imposes new  
requirements on the IPv4 side rather than the IPv6 side. I do agree  
that having an unmodified IPv4 host talk to an unmodified IPv6 host  
is problematic if you want to avoid NAT.

Being able to talk to unmodified IPv4 hosts is attractive in the  
short term because there are so many of them. But being able to keep  
IPv6 clean is attractive in the long term.

The effort to update either would be approximately the same, in my  
opinion, because all current OSes support both IP versions. The big  
difference would be in the appliances such as firewalls and load  
balancers.

The way I see it, the large value isn't in making a random IPv6 host  
talk to a random IPv4 host. Rather, it's allowing a random IPv6 host  
to talk to the infrastructures of large content networks that exist  
in IPv4 which seem to be having a hard time moving to IPv6.

As far as having the IPv6 host know about the translation: a very  
simple way to do this is with proxies. Today, applications need to  
know about proxies but I don't think it would be too hard to make the  
OS support this. I.e., when an IPv6-only host wants to set up a TCP  
session towards an IPv4-only host, the stack intercepts the request,  
connects to a proxy and asks the proxy to set up a session towards  
the IPv4 address in question. When the connection is there, the TCP  
session is given to the application.

---

From: "Todd T. Fries" <[email-masked]>
Date: Thu, 18 Oct 2007 06:49:16 -0500

'not too big a deal to modify a v4 host'

uh. what corner of academia are you smoking?

The bar to change IPv4 hosts to talk IPv6 is exactly the same as updating
the IPv4 protocol to talk some fancy backwards objectionable protocol
``enhancement'' that hides IPv6 under the hood.

If you're a v4 host wanting to talk to v6 land, visit:

	http://freedaemonconsulting.com.ipv4.sixxs.org/

If you're a v6 host wanting to talk to v4 land, visit:

	http://google.com.ipv6.sixxs.org/

Proxies are indeed a valid transition mechanism, they are in place and
working, today.

What you propose adds more bandaids to IPv4 and further muddies and confuses
the waters.

Do you not realize why IPv4 mapped addresses were a bad idea?

    http://ipv6samurais.com/ipv6samurais/openbsd-audit/draft-cmetz-v6ops-v4mapped-api-harmful-01.txt
    http://ipv6samurais.com/ipv6samurais/openbsd-audit/draft-itojun-v6ops-v4mapped-harmful-02.txt

I beg you to consider that your proposal is no different in that regard
with regards to security, but in addition, it is worse, as it changes the
IPv4 stack itself.

Ugh.

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting                      \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \          250797 (FWD)
|                                             \
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Penned by Iljitsch van Beijnum on 20071018 10:04.54, we have:
| On 17-okt-2007, at 22:49, Brian E Carpenter wrote:
| 
| >In my opinion we have to be very systematic about this. The only way
| >that we can avoid the intrinsic problems of stateless translation
| >seems to be to have awareness at the IPv6 end that translation is
| >happening.
| 
| Note that my draft goes in the opposite direction and imposes new  
| requirements on the IPv4 side rather than the IPv6 side. I do agree  
| that having an unmodified IPv4 host talk to an unmodified IPv6 host  
| is problematic if you want to avoid NAT.
| 
| Being able to talk to unmodified IPv4 hosts is attractive in the  
| short term because there are so many of them. But being able to keep  
| IPv6 clean is attractive in the long term.
| 
| The effort to update either would be approximately the same, in my  
| opinion, because all current OSes support both IP versions. The big  
| difference would be in the appliances such as firewalls and load  
| balancers.
| 
| The way I see it, the large value isn't in making a random IPv6 host  
| talk to a random IPv4 host. Rather, it's allowing a random IPv6 host  
| to talk to the infrastructures of large content networks that exist  
| in IPv4 which seem to be having a hard time moving to IPv6.
| 
| As far as having the IPv6 host know about the translation: a very  
| simple way to do this is with proxies. Today, applications need to  
| know about proxies but I don't think it would be too hard to make the  
| OS support this. I.e., when an IPv6-only host wants to set up a TCP  
| session towards an IPv4-only host, the stack intercepts the request,  
| connects to a proxy and asks the proxy to set up a session towards  
| the IPv4 address in question. When the connection is there, the TCP  
| session is given to the application.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Oct 2007 14:04:52 +0200

> 'not too big a deal to modify a v4 host'

The absolute size of the deal isn't in question, it's the relative  
size when comparing moving to IPv6 wholesale (not happening at a  
reasonable pace) vs a mechanism that lets unmodified IPv6 hosts talk  
to unmodified IPv4 hosts (NAT-PT, is now dead) vs a mechanism that  
lets unmodified IPv6 hosts talk to modified IPv4 hosts vs a mechanism  
that lets modified IPv6 hosts talk to unmodified IPv4 hosts.

Since all hosts that can be reasonably considered upgradable have  
both IPv4 AND IPv6 code on board the difference in scope between  
modifying one vs the other is small. Obviously changing deployments  
is rather different between IPv4 and IPv6.

> 	http://freedaemonconsulting.com.ipv4.sixxs.org/

There's more to life than HTTP. (I happen to be in a place that is  
blanketed by a wifi network that only supports port HTTP/port 80.  
This is almost useless.)

> Proxies are indeed a valid transition mechanism, they are in place and

Ok, we can agree on that part then.

> What you propose adds more bandaids to IPv4 and further muddies and  

I'm sure it will be much easier to go back to a clean architecture  
for IPv4 right after we stop running it.  :-)

> Do you not realize why IPv4 mapped addresses were a bad idea?

That's an unanswerable question, because knowing something (realizing  
it) implies the knowledge is true. I DO know that some people think  
that, and I vehemently disagree. Using separate APIs to talk IPv4 and  
IPv6 is an incredibly bad idea. Now that the IPv6 API is widely  
supported, applications should just use that one, whether the  
resulting packets are IPv4 or IPv6.

But how does this relate to the question at hand, exactly?

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 18 Oct 2007 14:18:45 +0200

Why not extend MIP?

One can assume that people would roam between v4 only and v6 only sites
in future.
could MIP not be a technology dealing with this?

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Iljitsch van Beijnum
Sent: Thursday, October 18, 2007 2:05 PM
To: [email-masked]
Cc: Brian E Carpenter; IPv6 Operations; Jari Arkko
Subject: Re: Enhanced SIIT

> 'not too big a deal to modify a v4 host'

The absolute size of the deal isn't in question, it's the relative size
when comparing moving to IPv6 wholesale (not happening at a reasonable
pace) vs a mechanism that lets unmodified IPv6 hosts talk to unmodified
IPv4 hosts (NAT-PT, is now dead) vs a mechanism that lets unmodified
IPv6 hosts talk to modified IPv4 hosts vs a mechanism that lets modified
IPv6 hosts talk to unmodified IPv4 hosts.

Since all hosts that can be reasonably considered upgradable have both
IPv4 AND IPv6 code on board the difference in scope between modifying
one vs the other is small. Obviously changing deployments is rather
different between IPv4 and IPv6.

> What you propose adds more bandaids to IPv4 and further muddies and 
> confuses the waters.

I'm sure it will be much easier to go back to a clean architecture for
IPv4 right after we stop running it.  :-)

That's an unanswerable question, because knowing something (realizing
it) implies the knowledge is true. I DO know that some people think
that, and I vehemently disagree. Using separate APIs to talk IPv4 and
IPv6 is an incredibly bad idea. Now that the IPv6 API is widely
supported, applications should just use that one, whether the resulting
packets are IPv4 or IPv6.

---

From: "Todd T. Fries" <[email-masked]>
Date: Thu, 18 Oct 2007 07:27:14 -0500

Penned by Iljitsch van Beijnum on 20071018 14:04.52, we have:
| On 18-okt-2007, at 13:49, Todd T. Fries wrote:
| 
| >'not too big a deal to modify a v4 host'
| 
| The absolute size of the deal isn't in question, it's the relative  
| size when comparing moving to IPv6 wholesale (not happening at a  
| reasonable pace) vs a mechanism that lets unmodified IPv6 hosts talk  
| to unmodified IPv4 hosts (NAT-PT, is now dead) vs a mechanism that  
| lets unmodified IPv6 hosts talk to modified IPv4 hosts vs a mechanism  
| that lets modified IPv6 hosts talk to unmodified IPv4 hosts.
| 
| Since all hosts that can be reasonably considered upgradable have  
| both IPv4 AND IPv6 code on board the difference in scope between  
| modifying one vs the other is small. Obviously changing deployments  
| is rather different between IPv4 and IPv6.
| 
| >If you're a v4 host wanting to talk to v6 land, visit:
| 
| >	http://freedaemonconsulting.com.ipv4.sixxs.org/
| 
| There's more to life than HTTP. (I happen to be in a place that is  
| blanketed by a wifi network that only supports port HTTP/port 80.  
| This is almost useless.)
| 
| >Proxies are indeed a valid transition mechanism, they are in place and
| >working, today.
| 
| Ok, we can agree on that part then.
| 
| >What you propose adds more bandaids to IPv4 and further muddies and  
| >confuses
| >the waters.
| 
| I'm sure it will be much easier to go back to a clean architecture  
| for IPv4 right after we stop running it.  :-)
| 
| >Do you not realize why IPv4 mapped addresses were a bad idea?
| 
| That's an unanswerable question, because knowing something (realizing  
| it) implies the knowledge is true. I DO know that some people think  
| that, and I vehemently disagree. Using separate APIs to talk IPv4 and  
| IPv6 is an incredibly bad idea. Now that the IPv6 API is widely  
| supported, applications should just use that one, whether the  
| resulting packets are IPv4 or IPv6.
| 
| But how does this relate to the question at hand, exactly?

The question I think is the wrong question.  I've read enough of the
discussion on this topic to realize the people discussing it here presume
that stateless communication between IPv4 and IPv6 is some holy grail that
must be achieved at all costs.

I'm stepping back a few paces and adding some water to your collective
faces and saying ... um, lets think about this for a second.

The question you are trying to answer is "How can we provide IPv6 to IPv4
stateless conversations so as to make things easier to transition?"

I agree with half of that statement, that making things easier to transition
is a useful thing.

However, any stateless transition mechanism is going to be as harmful as
IPv4 mapped IPv6 addressing given that you add an entire complex case to
firewalls and any security issues you wish to address.

If you get your wish and provide that any IPv6 host can talk to any IPv4
host with special extensions, suddenly you drop the collective pants on any
IPv4 host's firewall, just the same as the issues presented with IPv4 mapped
IPv6 addresses.  I think this is very much relevant here for this question
and this discussion.

To answer your other statement, I cannot see how you call the IPv6 api
something to transition to and once transitioned to, you cannot use
the IPv4 API.

There are some new standard functions, getaddrinfo() for example, that
support both protocols.  If you write your code properly, you need not
care which protocol you are talking to.  If you have an application that
keeps track of the IP address in some manner, then you'll need to add the
support for IPv6 but this hardly mandates removing the IPv4 address handling.

In either case, dual stack machines have the capability to talk to either
IPv6 or IPv4 depending on which addresses are available for the services
they wish to communicate with.

So, I might humbly submit that to make transition easy, one would need
to convince people there is a reason to rollout IPv6 support.

I have an understanding that at least in the US, major carriers (Sprint,
Level3, UUNet, AT&T, Verizon, etc..) are in various stages of implementing
IPv6 backbone services in order to meet the June 2008 deadline for the
US Government to be fully capable with IPv6.  They have incentive to keep
their carrier agreements with the government and adding IPv6 allows them
to do this.

So there is infrastructure in place that is transitioning to IPv6 as we speak.

The biggest holdup in the IPv6 transition in my humble opinion is the lack
of having IPv6 root dns servers in the advertised/example root.cache/root.hints
file.  Some brain cell in the back of my head reminds me that the transition
as stated ages ago suggested 'routers and dns servers first, hosts second'.
Why can we not get the dns part right, years after the transition has started?

Automagic solutions that require updates that have no experimental experience
and no reference to any security implications seems to me to be a last ditch
effort at doing the worst possible thing at this time.

What is so wrong with talking dual stack for a time, and upgrading like mad
during that time to enable as many people to have either native or tunneled
IPv6 access?

Hmm, that'd require work, not talk.  I get it.

Thanks,

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 18 Oct 2007 23:13:17 +1000

> could MIP not be a technology dealing with this?

=> See:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt
and 
http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-05.txt

Hesham

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Oct 2007 15:22:42 +0200

> must be achieved at all costs.

It's not so much the statelessness that's important, but the ability  
for people to go ahead with IPv6 and reduce their IPv4 footprint  
*now* rather than more or less be forced to wait until everyone else  
is dual stack. The problem with dual stack is that it provides no  
compelling benefits: you get all the complexity that's in IPv4, all  
the complexity that's in IPv6, and any complexity arising from their  
interaction to boot.

> firewalls and any security issues you wish to address.

Unfortunately, firewalls are used in such an abundant variety of  
harmful ways, that there is no reasonable way to accommodate their  
use in most IETF work. People shouldn't depend on firewalls as  
crutches that let them keep doing things that they shouldn't be doing.

> something to transition to and once transitioned to, you cannot use

I'm not saying you can't, I'm saying it doesn't make sense to use  
different code paths for IPv4 and IPv6.

> care which protocol you are talking to.

Right. That's exactly what I'm saying. But the OpenBSD people didn't  
want that, and made sure their kernel would only allow the IPv6 API  
to generate IPv6 packets. Fortunately, this is something that's no  
longer a system-wide setting these days (well, unless you use Windows  
XP, where v4 and v6 are separate protocols that shall never meet in  
an API) but something that applications can control.

[...]

> So there is infrastructure in place that is transitioning to IPv6  

On the other hand, none of the big content sites uses IPv6, very few  
end-user ISPs offer IPv6 and none of the common CPEs support IPv6.  
The same thing was true several years ago, but we are now making way  
more progress using up the remaining IPv4 space than adding IPv6 in  
these three areas.

> file.

Huh? Not to say that I'm happy with the glacial progress in that  
area, but how exactly would that help? Yes, with IPv6 root servers  
it's possible for a system that runs IPv6-only to reach another IPv6  
system without touching any IPv4 infrastructure if all the DNS  
servers in the delegation chain also support IPv6, but the problem is  
that you can't run IPv6-only anyway because then you don't have  
access to the top 100 web sites, any of the large IM networks, etc.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 18 Oct 2007 10:22:48 -0500

Thus spake "Brian E Carpenter" <[email-masked]>
> we want the translator to be a single point of failure?

If the translation is stateless, there is no reason why the translator would 
be a SPOF.  You'd just deploy several of them, and packets would flow 
through whichever one was up at any given time.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: [email-masked]
Date: Thu, 18 Oct 2007 10:48:32 -0500

Penned by Iljitsch van Beijnum on 20071018 15:22.42, we have:
> It's not so much the statelessness that's important, but the ability for 
> people to go ahead with IPv6 and reduce their IPv4 footprint *now* rather 
> than more or less be forced to wait until everyone else is dual stack. The 
> problem with dual stack is that it provides no compelling benefits: you get 
> all the complexity that's in IPv4, all the complexity that's in IPv6, and 
> any complexity arising from their interaction to boot.

I use the following every hour of my business operation:

 - afs
 - dns
 - http
 - smtp
 - imap
 - ssh
 - ipsec

Of these, I use all but the first with v6 where I can, and v4 where I can't.

afs has no IPv6 roadmap to my understanding.

I have a pda that I `did not realize' for several months that it had no v4
connectivity to the outside world simply because I did not use it .. I only
used a local v4 link to get to my afs server.

The compelling benefit to me is that I can access any system w/out port
forwarding or NAT in the v6 case.  If not, I can fall back to v4 if I have
to.

Irregardless of the mechanism, to access IPv4 networks from an IPv6 only
network, there must be an IPv4 host doing some sort of proxying or translation,
in that I am sure we can agree.  Whether you consider this a router or a
firewall or a proxy or something else, the name is the only thing changing
here, the underlying concept does not change this.

> Unfortunately, firewalls are used in such an abundant variety of harmful 
> ways, that there is no reasonable way to accommodate their use in most IETF 
> work. People shouldn't depend on firewalls as crutches that let them keep 
> doing things that they shouldn't be doing.

I love this.  This specifically states that NAT should never have gone through
IETF, in my understanding.

> I'm not saying you can't, I'm saying it doesn't make sense to use different 
> code paths for IPv4 and IPv6.

In applications, I wholeheartedly agree.  Proper coding ensures utilizing
IPv4 or IPv6 whichever is available, applications should never care unless
they specifically have to record or deal with addresses in some manner.

> Right. That's exactly what I'm saying. But the OpenBSD people didn't want 
> that, and made sure their kernel would only allow the IPv6 API to generate 
> IPv6 packets. Fortunately, this is something that's no longer a system-wide 
> setting these days (well, unless you use Windows XP, where v4 and v6 are 
> separate protocols that shall never meet in an API) but something that 
> applications can control.
>
> [...]

Um, I think you misunderstand.  I am an `OpenBSD' person, for whatever it
is worth.

For an application (client) you can code like this (good for the eye, not
guaranteed to compile):

int
connect_func(char *host, char *port)
{
	struct addrinfo hints, *ai, *aitop;
	int err, net;
	char strport[NI_MAXSERV];

	memset(&hints, 0, sizeof(hints));
	hints.ai_family = AF_UNSPEC;
	snprintf(strport, sizeof strport, "%u", port);
	if ((err = getaddrinfo(host, strport, &hints, &aitop)) != 0)
		fatal("%s: %s port %s", __progname, host, port, strerror(err));

	for (ai = aitop; ai; ai = ai->ai_next) {
		if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6)
			continue;
		if (getnameinfo(ai->ai_addr, ai->ai_addrlen,
		    ntop, sizeof(ntop), strport, sizeof(strport),
		    NI_NUMERICHOST|NI_NUMERICSERV) != 0) {
			error("getnameinfo failed");
			continue;
		}

		net = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
		if (net < 0)
			continue;

		if (connect(net, ai->ai_addr, ai->ai_addrlen) < 0) {
			close(net)
			continue;
		}
		break;
	}
	freeaddrinfo(aitop);
	return net;
}

Why do you have to insist the api is separate?  It looks pretty uniformly
integrated to me.

If you insist that it seems odd to have a server bind to a different address
familiy as a separate socket, well, that's a different discussion.  That
much is quite clear from the references you removed from my last email.

> end-user ISPs offer IPv6 and none of the common CPEs support IPv6. The same 
> thing was true several years ago, but we are now making way more progress 
> using up the remaining IPv4 space than adding IPv6 in these three areas.

And why is it a bad thing to let the IPv4 space pressure convince the end-user
ISP's and CPE's from supporting IPv6?  Not that it should be the only means
of coersion, mind you .. ;-)

> Huh? Not to say that I'm happy with the glacial progress in that area, but 
> how exactly would that help? Yes, with IPv6 root servers it's possible for 
> a system that runs IPv6-only to reach another IPv6 system without touching 
> any IPv4 infrastructure if all the DNS servers in the delegation chain also 
> support IPv6, but the problem is that you can't run IPv6-only anyway 
> because then you don't have access to the top 100 web sites, any of the 
> large IM networks, etc.

How exactly it would help is because today unless I go hunt out (and anybody
else, for that matter) the actual IPv6 address of root nameservers, and then
add that to the hints file directly, I have an IPv6 capable name server that
only queries 2nd level name servers, not root servers, via IPv6.

If I want to run a nameserver on an IPv6 only network, I have to use a dual
stack fowarder or find one of the IPv6 only root servers my self.

If one wishes to boot strapping IPv6 islands into using IPv6 only, then I
believe that providing at least the core protocol (dns) for the internet for
IPv6 without relying on IPv4 root name servers by default, both as advertised
in the root.hints/root.cache file and in the default distribution of dns
server software.

Yes, there are many other places that rely on IPv4, but root dns server IPv6
address is not something we can control in the IPv6 islands.

Thanks,

---

From: Geoff Huston <[email-masked]>
Date: Fri, 19 Oct 2007 02:00:13 +1000

> we want the translator to be a single point of failure?

but if its stateless then the entire issue about single point of failure 
is not critical (Or have I got this entire stateless datagram forwarding 
model of packet switched networking entirely wrong? :-) )

---

From: Doug Barton <[email-masked]>
Date: Thu, 18 Oct 2007 14:21:49 -0700 (PDT)

On Thu, 18 Oct 2007, Iljitsch van Beijnum wrote:

> Being able to talk to unmodified IPv4 hosts is attractive in the short term 
> because there are so many of them.

Sure, but I think dual stack is the answer to this problem. I realize that 
the people who are highly motivated to push IPv6 adoption don't like that 
answer, but it IS a workable answer.

> But being able to keep IPv6 clean is attractive in the long term.

No argument there, but the existing solution actually does a better job of 
keeping things clean, and I think it does a better job of easing adoption 
personally.

> The effort to update either would be approximately the same, in my opinion, 
> because all current OSes support both IP versions.

If I'm Joe random business owner and I'm not interested in disrupting my 
network to add IPv6, I'm not going to be interested in disrupting my 
network to add SITT either. There is no business case for content 
providers to do what you are suggesting they do.

> The big difference would be in the appliances such as firewalls and load 
> balancers.

Another reason dual stack is a better solution. Add IPv6 capability 
when/where you need it, and (in 40 years) drop IPv4 when you don't 
anymore. If vendors get smart and put both in the same package, so much 
the better.

> The way I see it, the large value isn't in making a random IPv6 host talk to 
> a random IPv4 host. Rather, it's allowing a random IPv6 host to talk to the 
> infrastructures of large content networks that exist in IPv4 which seem to be 
> having a hard time moving to IPv6.

As one of my former colleagues says, that's a difference without a 
distinction. For at least 90% of the users on the 'net today you're 
talking about the same thing.

> As far as having the IPv6 host know about the translation: a very simple way 
> to do this is with proxies.

And now you've muddied up the IPv6 that you said at the beginning you 
wanted to keep clean.

FWIW, my opinion is that this idea is a non-starter on both ends of the 
wire.

Doug

-- 

 	If you're never wrong, you're not trying hard enough

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Oct 2007 11:24:49 +1300

> If the translation is stateless, there is no reason why the translator 
> would be a SPOF.  You'd just deploy several of them, and packets would 
> flow through whichever one was up at any given time.

But that fails miserably if the protocol in use is stateful in a way
that needs stateful translation in the NAT devices.

Think about NAPT for example. I don't see how that can fail over
statelessly from one box to another.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Oct 2007 11:27:53 +1300

On 2007-10-19 04:48, [email-masked] wrote:
...
> IETF, in my understanding.

It didn't. See RFC 2993 and 3027 for example. RFC 3022 is not a standard.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Oct 2007 11:36:41 +1300

> afs has no IPv6 roadmap to my understanding.

http://workshop.openafs.org/afsbpw07/talks/openafs_roadmap_BPW_2007.pdf
shows this as a "Development Project in Search of Support".

So, it needs somebody willing and able to work on it.

     Brian

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 18 Oct 2007 12:41:13 -1000 (HST)

>    http://ipv6samurais.com/ipv6samurais/openbsd-audit/draft-cmetz-v6ops-v4mapped-api-harmful-01.txt

I disagree.  From my own experience the issues brought up in the above are 
simply not important for the majority of network applications which don't 
really care whether a connection is made by IPv4 or IPv6 nor for the 
majority of users who shouldn't have to know anything about the underlying 
network.

I think Section 3.7 of the API has actually made it relatively easy for 
most developers to add IPv6 capability to various apps that were 
previously IPv4-only.  If the recommendations in the above had been 
followed I think you'd actually see a slowdown in updates to various apps 
since developers would be forced to write/debug significantly more complex 
code.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 18 Oct 2007 12:47:23 -1000 (HST)

> of having IPv6 root dns servers in the advertised/example root.cache/root.hints

Important yes but I don't think it's the biggest holdup.  Next to the 
routing infrastructure, the biggest holdup is the lack of IPv6 support in 
many apps.  Dual-stack networks and hosts can get along fine without IPv6 
root.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 18 Oct 2007 17:53:58 -0500

> that needs stateful translation in the NAT devices.

That's the problem with _any_ stateful translation or firewalling.  Any sort 
of hard state in the network is fragile, which is why SIIT was defined to be 
stateless, AIUI.  If one wants to "enhance" SIIT by making it stateful, 
don't use the same name because that's a fundamental violation of what SIIT 
is -- it's even in its name.

> statelessly from one box to another.

That's not stateless translation.  There _are_ stateful NAPT boxes that can 
do failover because they share state, and that technology could be applied 
to a stateful variant of SIIT if desired.

S

---

From: james woodyatt <[email-masked]>
Date: Thu, 18 Oct 2007 16:25:32 -0700

On Oct 17, 2007, at 13:49, Brian E Carpenter wrote:
>
> I don't have any specific proposals in mind, but I'm pretty sure  
> that signalling between the translator and the IPv6 host will be  
> needed.

Yeah, but that's not a big deal, right?  It's not like we haven't  
already capitulated completely to the need for IPv6 nodes to signal  
nodes in the network charged with keeping track of application  
state-- why not just embrace the horror and learn to love the  
stateful packet mangler?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Oct 2007 17:50:42 -0600

> state-- why not just embrace the horror and learn to love the

Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb

   - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Oct 2007 13:22:01 +1300

Hesham,

> work. I think it can be a good reference if the WG still wants to work with

I didn't consciously remember that draft, but DSTM+NAT4 did occur to
me the other day as a possibility. However, I don't think there's any
real need for the DSTM server and the SIIT or NAT4 box to be separate
- the main point is to define how the IPv6 end knows that it's being
forced from native IPv6 mode to translated mode, and knows what the
other end's view of the source and destination addresses is. (It sounds
a bit like shim6 at that point, with the legacy IPv4 host only being able
to handle IPv4 ULIDs.)

      Brian

---

From: Nathan Ward <[email-masked]>
Date: Fri, 19 Oct 2007 13:41:07 +1300

On 19/10/2007, at 11:53 AM, Stephen Sprunk wrote:

> That's not stateless translation.  There _are_ stateful NAPT boxes  
> that can do failover because they share state, and that technology  
> could be applied to a stateful variant of SIIT if desired.

I'll just close my un-sent email, then.

For sake of clarity, I'll note that my interpretation of NAPT is  
Network Address and Port Translation, not " " Protocol ".

I don't think updating IPv4 hosts is feasible at this point - the  
reason I'm not putting AAAA records in parallel with my A records for  
my web content is that NAPTing non-RFC1918 IPv4 breaks 6to4 for 1-2%  
of my users.
About 4% of my users are versions of Windows without IPv6 capability.

I'm told that IE7.0 is being pushed out to Windows XP machines  
automatically now, yet 54% of Windows machines that hit my are  
running IE6.0.

What both these thing tell me is that even if vendors did make this  
available, a large number of people aren't going to run the updates  
to get the code.

While this solution may be the cleanest on paper, we're at the point  
where we need to be deploying practical, realistically achievable  
solutions for these problems, instead of introducing complexity in to  
legacy parts of the network. My view is that the path of least  
resistance is to create an extension for IPv6 to do this, as opposed  
to an extension to IPv4.

The approach of using some kind of proxy was proposed, and that's my  
preferred solution at this stage if some kind of IPv6 host to IPv4  
host scheme is deemed needed - the drawback is that it doesn't allow  
IPv4 hosts to establish new connections to IPv6 hosts, only IPv6 ->  
IPv4. While it's my preferred solution, I'm still on the fence as to  
whether it's worth doing. As an aside, this might be easier if TCP  
and UDP ports for most applications didn't have default values..

My solution to one day not having IPv4 addresses to assign to end  
users (home broadband/dial users) right now, is to run dual-stack,  
where the v4 part of the stack is NAPTed. It's not ideal, as users  
are going to be double NAPTed if they have their own unit doing it at  
home, but it won't prevent them from getting to regular content  
providers which is the the first requirement from my POV.
As I've noted recently, P2P clients are now becoming IPv6 aware so  
from an end user's POV, that stuff is still likely to work for them  
for the most part. Realistically, so few of those people are going to  
be running SIP, and even fewer are going to be running SIP UA's not  
provided by their service provider, that I'm really not concerned  
about that.
Depending on people's businesses, they can look at offering enhanced  
plans with a 'real' IPv4 address, or maybe it's stuck on freely for  
customers who call helpdesk with problems with certain applications -  
sticking my finger in the air tells me that the majority simply won't  
care.

Bleak? Maybe. I really don't see a realistic alternative (save for  
slight modifications of the above) to get us through the next 5 (or  
so) years.

--
Nathan Ward

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 19 Oct 2007 10:34:50 +0200

> Why do you have to insist the api is separate?  It looks pretty  

Ok, should have been more clear: the issue is when you bind() to ANY  
do you get both incoming IPv4 and IPv6 requests or only one type?

> familiy as a separate socket, well, that's a different discussion.

Ok.

>> The same

> of coersion, mind you .. ;-)

It would be pretty bad if we run out of IPv4 space and STILL we're  
not ready to roll out IPv6 because IPv6 CPEs can't be had or software  
doesn't support IPv6.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 19 Oct 2007 10:37:08 +0200

> I disagree.

++

---

From: "Todd T. Fries" <[email-masked]>
Date: Fri, 19 Oct 2007 04:47:55 -0500

I personally think that handling the three case:

	a) normal v4 address
	b) v4 mapped v6 address
	c) v6 address

is more complex than handling the two cases:

	a) normal v4 address
	b) normal v6 address

Agree or not, harmful is the stance the world has taken.

Lamenting the past does not move us to faster adoption of IPv6.

We need an `adopt IPv6' movement... i.e. action.

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 19 Oct 2007 11:32:50 -1000 (HST)

> is more complex than handling the two cases:

And those two cases are more complex than coding for a single socket and 
internal address representation.

> Agree or not, harmful is the stance the world has taken.

I'm sure a software developer can make the necessary code do his/her 
bidding - where it matters.  My point is that for the majority of code out 
there, it usually doesn't really matter.

> We need an `adopt IPv6' movement... i.e. action.

Concur, and I would also add that we don't want to add unnecessary 
impediments to that movement.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Alastair Johnson <[email-masked]>
Date: Tue, 23 Oct 2007 14:31:00 +1000

Nathan,

Nathan Ward wrote:
> preferred solution at this stage if some kind of IPv6 host to IPv4 host 
> scheme is deemed needed - the drawback is that it doesn't allow IPv4 
> hosts to establish new connections to IPv6 hosts, only IPv6 -> IPv4. 
> While it's my preferred solution, I'm still on the fence as to whether 
> it's worth doing. As an aside, this might be easier if TCP and UDP ports 
> for most applications didn't have default values..
> 
> My solution to one day not having IPv4 addresses to assign to end users 
> (home broadband/dial users) right now, is to run dual-stack, where the 
> v4 part of the stack is NAPTed. It's not ideal, as users are going to be 
> double NAPTed if they have their own unit doing it at home, but it won't 
> prevent them from getting to regular content providers which is the the 
> first requirement from my POV.

At least one carrier that I am aware of is currently looking closely at 
an approach similar to yours.

Essentially, they are looking at dual-stacking the broadband access 
platforms to support IPv4 and IPv6 to the CPE[1]; then enabling their 
data centers and infrastructure for IPv6 support for their networks (eg. 
AAAA responses only to their customers).  At the same time, an 
infrastructure deployment plan and architecture is developed for 
service-provider wide IPv4 NAPT.

At 'd-day' for IPv4 exhaustion, the infrastructure is in place to 
support service provider wide IPv4 NAPT which allows the SP to continue 
supporting single and dual stack customers.  There are the obvious 
problems with dual/multi NAT layers[2].  The customers can access IPv6 
enabled content locally if they are dual stack to their desktop; as well 
as native IPv6 content on the wider Internet.  The SP also sees the 
opportunity to perhaps recover v4 addresses from legacy plant (dialup or 
whatever), and use these to provide an up-sell to a 'static IPv4 /32' if 
you want a real address.  The product evolution here is likely to be 
that you pay a premium for a real v4 address where the SP can allocate 
it, and a reduced amount for NAPT v4 address.

The CPE[1] must support 4-to-6 NAT-PT of some kind.  There is no planned 
facility for 6-to-4 NAT-PT as any host which is IPv6 enabled should also 
be IPv4 enabled and can get access to exclusive v4 resource through the 
SP-NAPT in place.  Allowing for all the legacy IPv4 only hosts that 
customers may run to access IPv6 resource through the CPE seems to be a 
suitable approach.

This seems to be a reasonably pragmatic approach to the problem, but of 
course it requires the "big SP-NAPT" box and the development of a NAT-PT 
standard.

aj.

[1] For this case, the Service Provider dictates the CPE use and manages 
it.  Using 240/4 for this "private IPv4 infrastructure" could well work 
as all devices are modern and SP controlled.
[2] There is the possibility for NAT evolution here to support the 
concept of uPNP across network boundaries.  This is somewhat dependent 
on being able to trust the CPE, but given [1] this is less of a problem.