Subject: Re: Follow-up work on NAT-PT

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Nov 2007 14:59:08 +1300

On 2007-10-30 11:54, Brian Dickson wrote:
> Brian E Carpenter wrote:
>> The IAB request specifically asks for a solution for IPv6-only
>> hosts. It's long been my view that the primary coexistence strategy
>> must be dual-stack, but I'm trying to answer the IAB's question.
>>
>>>
>>> Finally, from my reading the usefulness of SHANTI is only where the 
>>> IPv6-only host has an application that appreciates IPv4 parameters 
>>> (port and address) or the translation itself. Do we expect 
>>> application developers to widely cater for this scenario, or to make 
>>> the assumption that "if IPv4 matters we should use the IPv4 stack"?
>>
>> No, SHANTI will work out of the box for any application that runs
>> through a traditional NAT or NAPT without problems *and* has been
>> upgraded to AF_INET6 sockets. However, applications that require
>> an ALG with traditional NA(P)T will need to be tweaked, I think.
>> The question is whether that overhead is justified to get rid of
>> the problems of NAT-PT?
>>
>>     Brian
> I've been giving thoughts to some of the issues along similar lines.
> 
> Here's what I've been thinking of, in terms of a solution space:
> 
> Protocol translation that uses IPv6 as a transport, but doesn't do 
> anything other than present IPv4 on an IPv6-only host.

I'm not sure how this is different from Bump in the Stack (RFC 2767)
or Bump in the API (RFC 3338), as you describe it above.
Or are you closer to DSTM?
http://tools.ietf.org/id/draft-ietf-ngtrans-dstm-overview-00.txt

     Brian

> 
> The way to describe it in shorthand would be:
> PT-4-6-4
> 
> On the IPv6-only host, add an IPv4 "thing". (interface/driver/whatever).
> 
> There's some bootstrap issues regarding bringing up the IPv4 interface - 
> let's defer those for now...
> 
> When this IPv4 "thing" talks to another IPv4 host, it will be using IPv4 
> source/dest and src/dest ports.
> 
> Do IPv4-to-IPv6 protocol translation - but now, the extra "twist" - 
> embed the *port* in the IPv6 destination, *above* the IPv4 address.
> This lets us set up "generic" ALGs, based on covering aggregates for the 
> "special" address space we use for the place where 6-back-to-4 happens.
> And, we can then set up ALGs on a per-port basis, which are 
> more-specific addresses.
> And even more fine-grained port+IPv4 ALGs can be set up, e.g. when there 
> is a need to do 4-6-4 for RFC 1918 space.
> 
> Since the host sees IPv4 "natively", no DNS tricks are needed.
> 
> There are even a few advanced tricks that can be accomplished, like 
> reverse-port-mapping to request inbound port(s) and possibly inbound 
> port+IPv4 address "reservation".
> Combined with dynamic DNS, it may be possible to extend the usefulness 
> of a very small number of IPv4 addresses, to support a much larger of 
> "servers" who need reserved ports, although possibly only 
> intermittently. (Think SMTP for hosting, inbound with MX and relay.)
> 
> The implementation of things like DHCP (for IPv4) use well-know IPv4 
> "broadcast" address destination 255.255.255.255. But, having an IPv6 
> host listen on that address, transmogrified by the mapping including 
> port, means a specific IPv6 address can act as a DHCP server (or relay).
> 
> NAT stuff built to handle this has an added advantage - the IPv4 
> client-side addresses can overlap, since the presumption is that all the 
> hosts already have IPv6 - and can communicate via IPv6. So there would 
> not be any need for support for "tromboned" traffic between pairs of 
> hosts behind this 4-6-4-plus-NAT. The colliding addresses are 
> disambituated in IPv4 by port (assigned by the NAT), and in the NAT 
> back-end by IPv6 address.
> 
> There are details to work out, of course. But I think it could be an 
> interesting starting point, which by virtue of presenting an IPv4 
> interface to the client, avoids most of the NAT-PT issues.
> 
> Oh, yeah, one other good thing - there is no requirement that the ALGs 
> or NAT-PT exist on the same network, just that they be reachable via 
> IPv6 natively. So, a small network could point their "ALG default" at an 
> upstream, who then would handle all the NAT-PT stuff (presumably as 
> either a value-add, paid, or bundled service) for access to the V4 
> Internet.
> 
> Brian D
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Nov 2007 10:07:32 +1300

On 2007-11-09 07:22, Rémi Després wrote:
> Brian Dickson wrote :
>>> hosts...
>> ...
> If IPv6 hosts could be kept simple (i.e. unmodified for IPv6 to IPv4 
> connectivity), that would be a better perspective for IPv6 deployment.

I don't see that. IPv6 stacks are still in flux and being actively
worked on. In any case, my analysis of RFC 4966 is that without
adding state in the IPv6 host, most of the problems identified
with NAT-PT cannot be mitigated. draft-carpenter-shanti-01
covers this in some detail.

      Brian

> 
> One approach for this would be that the DNS would automatically return 
> IPv4 mapped addresses to IPv6 queries when they have no IPv6 address but 
> have at least one IPv4 address.
> Then boxes on the client-to-server paths which car support NAT for IPv4 
> connections (typically customer edge routers) can do the protocol 
> conversion.
> 
> The conversion would be a particular (simplified) NAT-PT (no 
> fragmentation, and the same ALGs as deemed useful in IPv4 NATs ).
> 
> As a matter of fact I proposed something in that direction in 2004, but 
> just before discussion on the subject stopped, NAT-PT being allover 
> deprecated. (ref. 
> file:///Users/Pro/Documents/_%20%20%20%20%20PRO%20-%20ORG/IETF/RD%20against%20NAT-PT%20deprecation.html 
> )
> 
> Rémi
> 
>

---

From: John Curran <[email-masked]>
Date: Thu, 8 Nov 2007 17:03:06 -0500

At 10:07 AM +1300 11/9/07, Brian E Carpenter wrote:
> In any case, my analysis of RFC 4966 is that without

Brian -
 
  How does an ISP grow their network (using IPv6 to connect
  customers) without some way to provide the minimal level
  of backward compatibility to the existing IPv4-connected
  Internet which is provided by NAT-PT?

/John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Nov 2007 11:25:38 +1300

>   Internet which is provided by NAT-PT?

I must confess that I've looked at the question much more from
the viewpoint of a campus or enterprise network, on the assumption
that ISPs only provide some combination of IPv4 and IPv6
transport. And there the answer for me has always been: upgrade
servers to dual stack, and install dual-stack application proxies
to fill any gaps.

I would envisage a similar approach for an ISP supporting
SOHO subscribers - that really isn't much different from
a campus network. The ISP will need dual-stack mail servers,
for example. Anyone providing services to the public will need
a dual stack, for that matter, if they want to be accessible.

However, for the residual cases, it's precisely because
of the issues with NAT-PT that I've just started working
on SHANTI. Whether that's of value is for the community
to say.

     Brian

---

From: John Curran <[email-masked]>
Date: Thu, 8 Nov 2007 18:27:51 -0500

>a dual stack, for that matter, if they want to be accessible.

At some point, ISP's will: 1) Be unable to readily obtain additional
IPv4 address space, 2) Want to keep growing, and 3) Want a
method for connecting up customers via IPv6-only which provides
some semblance of full Internet connectivity (including backward
reachability to IPv4 destinations).

From the ISP point of view, some of the key requirements are:

 - Has to require a minimal amount of special per-site
   (or per-site-host) configuration in order to provide
   the connectivity to Internet IPv4-only sites.

 - Allow for sharing of some IPv4 space that the ISP
   has set aside for such purposes.

 - Allow implementation of the same "site" policies
   (such as port-based firewall filters) on the IPv4
   backward-compatible connectivity that customers
   use today to provide nominal security.

Contrary to what a lot of folks think, I don't think that the
backwards-compatibility IPv4 connectivity really needs to
be general purpose, or application friendly, or support a
truly end2end model.   While NAT-PR is indeed imperfect
(as documented in RFC4966), it still provides minimal
backwards connectivity that is going to be desperately
needed for many providers.

>on SHANTI. Whether that's of value is for the community

If there's a way to improve the resulting connectivity
without create a raft of customer configuration and
support issues, it's probably of value to the community.

/John

---

From: [email-masked]
Date: Thu, 8 Nov 2007 19:44:02 -0500 (EST)

> http://tools.ietf.org/id/draft-ietf-ngtrans-dstm-overview-00.txt

It *does* bear some superficial resemblence to elements of all 3, but
is very different from any of them.

Both BIS and BIA, presume native IPv4 on the dual-stack host.
What they both offer, is the ability to offer a fake IPv4 path between
*two* IPv6 hosts. What I'm talking about is a means for an IPv6-only
host to access an IPv4 only host via one or more ALGs/NATs, by
presenting an IPv4 interface to the IPv6-only host.

This concept, 4-6-4, is a mechanism to provide what appears to the host
itself, as if it has native IPv4 connectivity (i.e. dual stack), and doing
something different from straight IPv4-in-IPv6 tunneling.

Instead of tunneling, or vanilla SIIT, it adds the twist which allows
identification of the specific ALG via IPv6 routing.

By directing traffic to the ALG on the native IPv6 network, the scaling
of both the individual ALGs, and the management of and placement of the
ALGs, scales much better. ALGs can be added on a per-port basis, can
be multiplex by IPv6-only load-balancers, or supported by any number of
networking tricks, devices, or topological niceties, all of which can
be IPv6-only, and (aside from the specific IPv6 prefixes used), ignorant
of the fact that any of this traffic is 4-6-4 traffic.

The one other significant difference is the concept of maintaining any
NAT state in the mapped V6 addresses, meaning v4 addresses can be used
simultaneously by multiple 4-6-4 client hosts, thus allowing much more
scalable deployment on the 1918 side of the NAT.

In fact, for maximum scalability, hosts in the 4-6-4 universe could all be
given identical IPv4 1918 addresses, and this would still work. Imagine
the ease of managing clients when they could all be configured with
192.168.1.2 as their IPv4 address. :-)

Brian D

---

From: John Curran <[email-masked]>
Date: Fri, 9 Nov 2007 23:39:22 -0500

At 5:26 PM +1300 11/10/07, Brian E Carpenter wrote:
>>truly end2end model.  
>But if it doesn't support *unknown* or even *future* applications,
>it is going to cause help desk calls (probably insoluble help
>desk calls, too). I realise that NAT does that today, but surely
>we'd like to do better?

We'd like to do better, and should if we can...   In any case,
there's still going to be a lot of ISP's saying to customers:
"Look, that site is only connected to the legacy Internet;
once they upgrade to the new stuff, you'll work fine. Why
don't you ask them why they're sooo far behind?"

>As far as I can see the configuration issues aren't major.
>All user systems served by the same SHANTI translator will
>need to know its IPv6 and IPv4 address by configuration -
>Yet Another DHCP Option could provide that.

That would definitely help...  please consider adding
consideration of such to your draft.

Thanks!
/John

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 10 Nov 2007 13:28:35 +0100

On 29 okt 2007, at 21:40, Brian E Carpenter wrote:

>> I'm interested to hear your thoughts on IPv6-only hosts (as opposed  
>> to dual-stack hosts) during the IPv4-to-IPv6 transition period. The  
>> work I've been doing up till now has made a fundamental assumption  
>> that we would see only v4-only and dual-stack hosts, assuming that  
>> only post IPv4 shutdown would we see an emergence of IPv6-only  
>> devices.

> must be dual-stack, but I'm trying to answer the IAB's question.

The problem with dual stack is that it doesn't solve anything: you  
still need just as much IPv4 as when running IPv4-only. Dual stack is  
important for server so that both IPv4-only and IPv6-only clients can  
use the service, but we need to move towards a situation where it's  
possible for a regular end-user PC to run IPv6-only without much loss  
of functionality (if any).

>> application developers to widely cater for this scenario, or to  
>> make the assumption that "if IPv4 matters we should use the IPv4  
>> stack"?

> upgraded to AF_INET6 sockets.

Ugh! Mixing IPv6 and NAT is something that I'd really like to avoid.

On monday I'll wrestle with xml2rfc once again, and if successful,  
I'll have a draft that suggests a slightly different way of doing  
this. (If anyone wants to mail me something I can use as an up-to-date  
xml2rfc template that would be much appreciated.)

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Nov 2007 17:26:32 +1300

John,

> reachability to IPv4 destinations).

Clearly!

>    the connectivity to Internet IPv4-only sites.

Sure. Assuming the ISP is running dual-stack routing, I believe
they'll need to configure things like mail and web servers
as dual-stack, and IM servers if they're offering that, but it's
hard for me to imagine that a local ISP will ever be able to solve
the problem of an IPv6-only subscriber accessing an IPv4-only Bloop server
on another continent, for arbitrary values of Bloop, unless there is
some help from the IPv6 host stack as well as a magic translator
box. (And this has nothing to do with IPv6 design details -
once you're sending packets that the IPv4-only server wasn't designed
to receive, you automatically have this problem.) I think we've
spent too long hoping that the world can be either pure IPv6-only
or pure dual stack - to solve this problem we need the IPv6-only
stack to be a little impure.

>    has set aside for such purposes.

Yes, which is why SHANTI includes NAPT-like port mapping.

>    use today to provide nominal security.

I can't see why that would be an issue. Ports work pretty
much the same in v4 and v6, and as noted, at least in my
proposal ports are handled exactly as in NAPT.

> While NAT-PR is indeed imperfect

As far as I can see the configuration issues aren't major.
All user systems served by the same SHANTI translator will
need to know its IPv6 and IPv4 address by configuration -
Yet Another DHCP Option could provide that. The
translator itself would be exactly where you'd put a NAT
and firewall today, and would be configured just like a NAPT.
No free lunch, of course.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Nov 2007 16:58:25 +1300

On 2007-11-10 08:04, Rémi Després wrote:
>> I don't see that. 
> Yet, if it is possible to propose operational solutions without 
> unnecessary additional layers of complexity, the industry and users 
> should benefit.
>> my analysis of RFC 4966 is that without
>> with NAT-PT cannot be mitigated.
> This is the important TECHNICAL point.
> A further analysis shows that :
> 1. Problems identified in RFC 4966 fall in fact into 3 categories.
> (a) Related to an Pv6-IPv4 DNS-ALG, if present
> (b) Related to fragmentation, if applicable
> (c) Identical to IPv4 NATrelated limitations
> 2. All can be eliminated  as follows:
> - With my proposal below (as I see it, a straightforward extension of 
> DNS to make IPv6 to IPv4 connections practical), problems (a) can 
> disappear.

See below, but basically that is my comclusion for the SHANTI scenario.

> - Limiting IPv6 to IPv4 connections to paths where MTUs are at least 
> 1500 (that of Ethernet) would be acceptable in the real world. Problems 
> (b) can then disappear.

This is probably realistic but it still means the IPv6 source needs to know
that limitation - SHANTI provides such knowledge to the IPv6 stack.
I can add that in the next version.

> - Applications of IPv6 to IPv4 connections can, and for the sake of 
> simplicity should be limited to that which are available to IPv4 hosts 
> behind NATs. Thus, problems (c) would disappear.

That's essentially the "don't behave worse than IPv4 NAPT" principle,
which I believe is mathematically inevitable in any case.
> 
>>>
>>> One approach for this would be that the DNS would automatically 
>>> return IPv4 mapped addresses to IPv6 queries when they have no IPv6 
>>> address but have at least one IPv4 address.

SHANTI recommends doing the equivalent of this in the resolver.
Then dual-stack hosts will still see A records, and can be mixed
on the same network with SHANTI hosts.

>>> Then boxes on the client-to-server paths which car support NAT for 
>>> IPv4 connections (typically customer edge routers) can do the 
>>> protocol conversion.

Yes, but they still have the ALG problem, and you have to be sure
the packets actually flow that way. SHANTI guarantees the packets are
routed to the translator, and pushes the ALG problem back where it belongs.

     Brian

---

From: Christian Huitema <[email-masked]>
Date: Sat, 10 Nov 2007 08:12:27 -0800

I don't think that we need to optimize for IPv6 only hosts. In practice, we can expect that IPv6 capable hosts will either be dual stack. Device designers will want to accommodate situations where their device connects to either an IPv6 network, or an IPv4 network. Implementing "dual stack" is not much harder than implementing "IPv6 only", so this is pretty much a no-brainer.

We need to optimize for reliability and operation support. There, we have to reconcile the tension between two goals: networks are simpler and easier to operate if they support one protocol instead of two; and, networks are simpler if they do not rely on complex and error prone gateways.

Is it really more efficient for an ISP to operate an IPv6 only network? If it is, then IPv4 services will have to be provided through some kind of overlay. On the provider side, the overlay will have connect to some IPv4 "gateways" that give access to the global IPv4 service. On the client side, the overlay will extend either all the way to the client itself, or terminate at the "access router".

If we just want to reuse old technology, the overlay can be built with simple tunnels. Access routers routinely support protocols like PPPoA or PPPoE. PPP over IPv6 (PPPo6?) would not be much of a stretch. It would also not look to strange on the ISP side, since after all ISP are quite used to support PPP servers.

If we don't like the hub and spoke nature of PPP, we can of course be creative and build the overlay with some form of automatic tunneling. But I am not sure that the automatic tunneling will actually reduce operation costs, or increase reliability.

-- Christian Huitema

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 10 Nov 2007 19:09:00 +0100

Softwires and usage of private IPv4 addresses, that was the reason we worked
on that !

I'm not yet convinced anything else is needed.

Regards,
Jordi

> De: Christian Huitema <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Sat, 10 Nov 2007 08:12:27 -0800
> Para: Iljitsch van Beijnum <[email-masked]>, Brian E Carpenter
> <[email-masked]>
> CC: David Miles <[email-masked]>, IPv6 Operations <[email-masked]>
> Conversación: Follow-up work on NAT-PT
> Asunto: RE: Follow-up work on NAT-PT
> 
> I don't think that we need to optimize for IPv6 only hosts. In practice, we
> can expect that IPv6 capable hosts will either be dual stack. Device designers
> will want to accommodate situations where their device connects to either an
> IPv6 network, or an IPv4 network. Implementing "dual stack" is not much harder
> than implementing "IPv6 only", so this is pretty much a no-brainer.
> 
> We need to optimize for reliability and operation support. There, we have to
> reconcile the tension between two goals: networks are simpler and easier to
> operate if they support one protocol instead of two; and, networks are simpler
> if they do not rely on complex and error prone gateways.
> 
> Is it really more efficient for an ISP to operate an IPv6 only network? If it
> is, then IPv4 services will have to be provided through some kind of overlay.
> On the provider side, the overlay will have connect to some IPv4 "gateways"
> that give access to the global IPv4 service. On the client side, the overlay
> will extend either all the way to the client itself, or terminate at the
> "access router".
> 
> If we just want to reuse old technology, the overlay can be built with simple
> tunnels. Access routers routinely support protocols like PPPoA or PPPoE. PPP
> over IPv6 (PPPo6?) would not be much of a stretch. It would also not look to
> strange on the ISP side, since after all ISP are quite used to support PPP
> servers.
> 
> If we don't like the hub and spoke nature of PPP, we can of course be creative
> and build the overlay with some form of automatic tunneling. But I am not sure
> that the automatic tunneling will actually reduce operation costs, or increase
> reliability.
> 
> -- Christian Huitema
> 
> 
> 
> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Nov 2007 13:41:53 +1300

On 2007-11-11 05:12, Christian Huitema wrote:
> I don't think that we need to optimize for IPv6 only hosts.

I've been repeatedly told that we need to, with "real estate"
usually being mentioned in the same breath. Otherwise, I'd
agree with you completely - dual stack everything, with
off the shelf IPv4 NAPT where you have to accommodate lack of
IPv4 addresses. But the IAB explicitly asked for a solution where
this is not the case.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Nov 2007 13:38:00 +1300

> Ugh! Mixing IPv6 and NAT is something that I'd really like to avoid.

I've been trying to avoid it since 1994. My conclusion is that
it is sadly impossible to avoid port translation, hence SHANTI.
Read it before you condemn it...

     Brian

---

From: Christian Huitema <[email-masked]>
Date: Sat, 10 Nov 2007 18:46:12 -0800

> IPv4 addresses. But the IAB explicitly asked for a solution where

We don’t have a real estate problem in PC-class machines, or even in PDA, smart phones and similar.

We do have a real estate problem in home routers, where we are witnessing a race to the bottom, but it is pretty hard to imagine home routers not supporting IPv4. So, if they support IPv6 at all, they will most certainly be dual stack.

I can imagine classes of devices that decide to go IPv6 only, but these will typically be single application devices, with no requirement to support IPv4.

In any case, real-estate arguments tend to be very speculative. The implementation size of any protocol can vary widely, based for example on trade-off between code size and performance.

What is the reasoning of the IAB? When they mention this requirement, do they have specific classes of devices in mind?

-- Christian Huitema

---

From: David Miles <[email-masked]>
Date: Sun, 11 Nov 2007 13:50:27 +1100

Brian, perhaps we need to better understand the reasoning behind the  
request and what "real estate" mean?

I'd like to think there is a day that IPv4 can be retired from a  
service provider's network. It is not necessarily the dual-stack  
nature of the access network that will increase the cost, but the  
amount of NAPT that may need to occur within the service provider to  
continue v4 ops in a address-depleted environment. During transition  
period there will be dual-stack and eventually v4-NAPT (for at least  
some customers).

My view is that:
- During transition dual stack should be what every new device  
supports (ie, IPv6-only stacks is a bad idea during the transition  
period)
- During transition we will see a move from IPv4 towards IPv6
- We should support connectivity for legacy clients as best we can  
until transition is complete

So, the last point is most interesting - support the legacy customer  
base. These are the customers who have not got devices that are dual- 
stack or who are accessing services/servers that are not yet IPv6- 
enabled. With 79% of the market running Windows XP (Net Applications  
Oct 2007) we need to consider how to transition the bulk of our  
customers to IPv6. The methods are (in order of preference from the  
Service Provider's perspective):
- Enable IPv6 in their existing OS
- Upgrade to a new OS
- Translation (along the lines of NAT-PT or the NAT46 component of  
draft-durand-ngtrans-nat64-nat46)

Translation of any kind should be last resort, but this is where I'm  
interested to get thoughts on NAT-PT revival for an IPv4-only host OS  
contacting an IPv6 server (with the same limitation as today's IPv4  
NA(P)T. I'm assuming that one day IPv4 resources will be too  
impractical (cost) to obtain so some business may be faced with IPv6- 
only connectivity for _servers_. Does anyone else think there may be a  
day when IPv4-only clients may exist (through provider NAPT) and  
because of v4 address shortages running a server on a well known port  
(http) may be restricted to IPv6 - to me this is a case for NAT46/NAT- 
PT - but its anyone's guess whether this day will come.

-d

On 11/11/2007, at 3:12 AM, Christian Huitema wrote:

> I don't think that we need to optimize for IPv6 only hosts. In  
> practice, we can expect that IPv6 capable hosts will either be dual  
> stack. Device designers will want to accommodate situations where  
> their device connects to either an IPv6 network, or an IPv4 network.  
> Implementing "dual stack" is not much harder than implementing "IPv6  
> only", so this is pretty much a no-brainer.
>
> We need to optimize for reliability and operation support. There, we  
> have to reconcile the tension between two goals: networks are  
> simpler and easier to operate if they support one protocol instead  
> of two; and, networks are simpler if they do not rely on complex and  
> error prone gateways.
>
> Is it really more efficient for an ISP to operate an IPv6 only  
> network? If it is, then IPv4 services will have to be provided  
> through some kind of overlay. On the provider side, the overlay will  
> have connect to some IPv4 "gateways" that give access to the global  
> IPv4 service. On the client side, the overlay will extend either all  
> the way to the client itself, or terminate at the "access router".
>
> If we just want to reuse old technology, the overlay can be built  
> with simple tunnels. Access routers routinely support protocols like  
> PPPoA or PPPoE. PPP over IPv6 (PPPo6?) would not be much of a  
> stretch. It would also not look to strange on the ISP side, since  
> after all ISP are quite used to support PPP servers.
>
> If we don't like the hub and spoke nature of PPP, we can of course  
> be creative and build the overlay with some form of automatic  
> tunneling. But I am not sure that the automatic tunneling will  
> actually reduce operation costs, or increase reliability.
>
> -- Christian Huitema
>
>
>
>
>

---

From: Christian Huitema <[email-masked]>
Date: Sat, 10 Nov 2007 19:19:14 -0800

> customers to IPv6.

If the concern is Windows XP, then we can devise specific solutions. Windows XP has some support for IPv6, but also has limitations. Specifically, Windows XP is not designed to run in an IPv6 only environment. For example, it performs name resolution over IPv4, and it has only limited support for IPv6 literal addresses. We can get a list of these limitations, and draft from there the minimal list of IPv4 functions that could be placed in the network to make things work. That could be an interesting project.

-- Christian Huitema

---

From: Gert Doering <[email-masked]>
Date: Sun, 11 Nov 2007 10:59:09 +0100

Hi,

> only", so this is pretty much a no-brainer.

I want to challenge that.  How are you going to implement "dual stack"
if no more IPv4 addresses are available?

Which is going to be a fairly typical scenario for new networks, some
years into the future.

(For the ISP backbone, dual stack is usually fairly easily done, because
the number addresses needed is small - but what about the end user networks?)

Gert Doering
-- 
Total number of prefixes smaller than registry allocations:  122119

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Christian Huitema <[email-masked]>
Date: Sun, 11 Nov 2007 07:35:43 -0800

> From: Gert Doering [mailto:[email-masked]]
> Sent: Sunday, November 11, 2007 1:59 AM
>

I meant "implementing dual stack in a device". Suppose you have built an IPv6 capable device. The added requirements for supporting IPv4 boils down to DHCPv4 client, ARP support, and a little bit of glue. That really is not a lot of "real estate".

-- Christian Huitema

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 11 Nov 2007 09:24:04 -0600

Thus spake "Gert Doering" <[email-masked]>
> Which is going to be a fairly typical scenario for new networks, some

It's trivial to _implement_ dual-stack, but it's going to get difficult to 
_deploy_ dual-stack in a few years.

The response I'm expecting -- so I'll save folks the effort -- is that 
people will dual-stack with RFC1918 and NAT on the v4 side.  My question is 
(still) why that is any better than v6-only hosts with NAT-PT.  All modern 
apps are version-agnostic, so they have to deal with the ugliness of NAT 
with either solution, and having v6-only hosts cuts the work required by 
leaf host/network admins in half.

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: Gert Doering <[email-masked]>
Date: Sun, 11 Nov 2007 16:50:01 +0100

Hi,

On Sun, Nov 11, 2007 at 07:35:43AM -0800, Christian Huitema wrote:
> I meant "implementing dual stack in a device". Suppose you have
> built an IPv6 capable device. The added requirements for supporting
> IPv4 boils down to DHCPv4 client, ARP support, and a little bit of
> glue. That really is not a lot of "real estate".

I agree - and I misunderstood this (as Stephen Sprunk also pointed out)
as "deploying in a network".  The network stack should not very hard.

Gert

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sun, 11 Nov 2007 18:17:07 +0200

Le Sunday 11 November 2007 17:24:04 Stephen Sprunk, vous avez écrit :
> All modern apps are version-agnostic,

What about the many non-modern applications still in use?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 11 Nov 2007 23:49:02 -0200

Same way as today do most of the end-users, private IPv4+NAT+IPv6 !

Applications that today work with IPv4+NAT keep working. New applications
take advantage of IPv6.

Regards,
Jordi

> De: Gert Doering <[email-masked]>
> Fecha: Sun, 11 Nov 2007 10:59:09 +0100
> Para: Christian Huitema <[email-masked]>
> CC: Iljitsch van Beijnum <[email-masked]>, Brian E Carpenter
> <[email-masked]>, David Miles <[email-masked]>, IPv6
> Operations <[email-masked]>
> Asunto: Re: Follow-up work on NAT-PT
> 
> Hi,
> 

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 11 Nov 2007 22:06:19 -0500

I'm a bit concerned about how solution-space-focused this discussion  
has been, especially when it is my understanding that we probably  
won't specify a solution in the v6ops WG.

Exactly what types of operational problems exist that we need to  
solve?  Why aren't the existing v4/v6 transition mechanisms  
sufficient to resolve those problems?  Where are the gaps that needs  
to be filled?

I really have no doubt that we could build a purer, cooler, "better"  
version of NAT-PT.  In fact, I even have my own thoughts on how we  
could do that.  But without understanding exactly what problem(s) we  
are trying to solve, I don't think that will be a very useful exercise.

Margaret

On Oct 28, 2007, at 7:48 PM, Brian E Carpenter wrote:

> 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).
>
> I realise this may be jumping the gun a bit, but since I won't be
> in Vancouver, here is a sketch of one possible direction.
>
>     Brian
>
> -------- Original Message --------
> Subject: I-D Action:draft-carpenter-shanti-00.txt
> Date: Sun, 28 Oct 2007 18:20:01 -0400
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : Shimmed IPv4/IPv6 Address Network Translation  
> Interface (SHANTI)
> 	Author(s)       : B. Carpenter
> 	Filename        : draft-carpenter-shanti-00.txt
> 	Pages           : 12
> 	Date            : 2007-10-28
>
> There is a pragmatic need for a packet-level translation mechanism
> between IPv4 and IPv6, for scenarios where no other mode of IPv4 to
> IPv6 interworking is possible.  The mechanism defined here uses a
> shim in both the translator and the IPv6 host to mitigate the
> problems introduced by stateless translation.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-carpenter-shanti-00.txt
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Nov 2007 17:33:17 +1300

> I meant "implementing dual stack in a device". Suppose you have built an IPv6 capable device. The added requirements for supporting IPv4 boils down to DHCPv4 client, ARP support, and a little bit o…

All true, but if you dispute the IAB's statement please
talk to the IAB. I've decided to stop being a purist on this
and see what can really be done to mitigate the problems with
NAT-PT. I suspect that if the IETF doesn't do this, then the
deprecation of NAT-PT will be a complete no-op.

     Brian

---

From: [email-masked]
Date: Mon, 12 Nov 2007 00:53:57 -0500 (EST)

> sufficient to resolve those problems?  Where are the gaps that needs

Here are what I perceive (not just personally, but from a variety of
input e.g. at NANOG, ARIN meetings in ABQ):

1) IPv4 access of *some* flavor from end-networks when end networks no
longer have the ability to get their own IPv4 space (which precludes use
of public IPv4 in a dual-stack environment)
2) Support for (1) from a large ISP perspective when the end-user or
end-network connectivity is not dual-stack
3) Support for all of the above when the end nodes number greater than the
number of IPs available under RFC 1918 (i.e. more IPs than one instance of
all private addresses can cover)

What is *not* needed, IMHO, is any-any IPv4 over the above connection
requirments, e.g. the presumption is any two boxes above will be able to
see each other via IPv6 directly, so P2P stuff should work okay, and the
existing techniques for v4-only apps via private p2p ad-hoc ipv4 over ipv6
tunnels should be presumed to work fine.

The presumption should be:
clients accessing servers, where servers are IPv4, and clients are ipv6,
and the predominant component of the access side of the clients, including
possibly their ISP, and even their ISP's ISP, is v6 only.

(Please see my reply to Brian Carpenters query, several days ago, I will
flesh it out some more, but IPv4-IPv6-IPv4-IPv4NAT-(Internet-v4) with PT,
may be an ugly hack with good scaling characteristics and the ability to
do port-specific ALGs in a way that allows ISP/ISP support for ALGs, i.e.
very attractive scaling characteristics.

Brian D

---

From: Mark Smith <[email-masked]>
Date: Mon, 12 Nov 2007 18:57:10 +1030

> of public IPv4 in a dual-stack environment)

As people have already chosen not to get enough of their own IPv4
address space, i.e. have used RFC1918 addressing instead of giving all
their devices a world wide unique IPv4 address, solutions to this
problem have already been developed and deployed - NAT/NAPT and ALGs such as web
proxies.

> end-network connectivity is not dual-stack

NAT/NAPT and ALGs can do that with RFC1918, and of course, already are.

> all private addresses can cover)

How common will this case be? I'm only aware of one organisation who's
having this problem, and that is a cable Internet company, and I'm
guessing their problem is with their OAM private addresses for the CPE
- I'd assume they've given the subscriber side of the CPE public
addresses. While I don't know much about their situation, if it is
plain cable CPE TFTP provisioning, I think they could address this
problem by accepting less than full OAM reachability inside their
network - having multiple OAM domains where each domain has it's own
instance e.g. of 10/8. Theirs is a corner case, and their issue isn't an
Internet connectivity / Internet application problem.

1 x "Class A", 16 x "Class B", and 256 x "Class C"s is an awful lot of
private address space that could be used with web proxies and ALGs. Do
you think ISPs would go to such extreme efforts to avoid deploying
IPv6 that they'd approach exhausting the RFC1918 address space? I'd
suggest they'd probably have gone out of business by then, as their
customers would have abandoned them for their competitors who're providing
"better Internet" by using IPv6.

Regards,
Mark.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 11 Nov 2007 20:47:11 +0100

You say that in response to:

>> with simple

This is an excellent approach if/when a host with only native IPv6  
connectivity needs full, unrestricted IPv4 connectivity, and this  
connectivity, along with the IPv4 address that goes with it, can  
reasonably made available.

The trouble with this approach is that it still requires IPv4 address  
provisioning, while the interesting aspect of NAT is that the address  
of the host behind the NAT is of no interest to anyone. So the IPv4  
provisioning step can easily be optimized away.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 11 Nov 2007 20:52:43 +0100

> Read it before you condemn it...

I'm not condemning it. And I've already read it.  :-)

I'll have a draft of the approach that I wrote about on october 19 on  
monday. It's like SHANTI in a lot of ways. One important difference is  
that host can use AF_INET sockets to talk to IPv4 destinations, so  
applications have the option of limiting the application of NAT code  
to AF_INET sockets or the situation where they detect an RFC 1918  
source address. (And applications that don't yet support AF_INET6 also  
work.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 12 Nov 2007 10:17:26 +0100

On 12 nov 2007, at 4:06, Margaret Wasserman wrote:

> solve?

The problem is that there is no operational problem: IPv6 deployment  
can still generously be rounded down to 0.

> Why aren't the existing v4/v6 transition mechanisms sufficient to  
> resolve those problems?  Where are the gaps that needs to be filled?

As per the above, that's a somewhat philosophical question. For a  
large content site deploying IPv6 is non-trivial, and you can't really  
ease into it. So as long as all the users are on IPv4, few of the  
content people are going to do IPv6. You don't need much IPv4 space  
for serving up content so the IPv4 depletion per se isn't going to  
push the content people to IPv6.

For ISPs this is very different: for them, it's much more doable to  
give some of their customers IPv6 without needing to convert the  
infrastructure for their current customers (obviously I'm talking big  
picture here, I'm not saying it's completely trivial). Also, the IPv4  
depletion WILL hit ISPs. The problem is that ISPs can't give their  
customers IPv6-only connectivity while the content is still only  
reachable through IPv4.

Now here's the philosophical issue: is it better to run IPv6-only +  
translation to IPv4, or is it better to have dual stack IPv6 + NATed  
IPv4?

As someone who used to configure routers for a living, my answer is:  
ditch IPv4 in as many corners of your network as possible, routing  
just IPv6 is much simpler. But I don't think this sentiment is  
universally shared.

An argument that many people aren't going to buy into would be that if  
IPv4/NAT and IPv6 must be provisioned separately this probably means  
that in a lot of instances, just IPv4/NAT will be provisioned and even  
with no new IPv4 addresses available we may not see much IPv6 adoption.

Another argument is that if ISPs are going to do NAT, this pretty much  
means that most customers, who run their own NAT, are going to be  
behind two layers of NAT, which is worse than just one layer of NAT.  
The reason for this is that there is no easy way for an ISP to  
provision multiple IPv4 addresses on a single customer link. With  
IPv6+translation you can use DHCPv6 prefix delegation to give users  
enough IPv6 space for all their hosts and only the translator does a  
single round of NAT.

In my opinion, we shouldn't try to get consensus on whether  
IPv6+translation is better than dual stack IPv6+IPv4/NAT, but just go  
ahead and make the best IPv6+translation solution we can and let the  
operators choose what they want to deploy.

---

From: John Curran <[email-masked]>
Date: Mon, 12 Nov 2007 08:18:40 -0500

At 10:17 AM +0100 11/12/07, Iljitsch van Beijnum wrote:
>As per the above, that's a somewhat philosophical question. For a large content site deploying IPv6 is non-trivial, and you can't really ease into it. So as long as all the users are on IPv4, few of the content people are going to do IPv6. You don't need much IPv4 space for serving up content so the IPv4 depletion per se isn't going to push the content people to IPv6.

Agreed.

>For ISPs this is very different: for them, it's much more doable to give some of their customers IPv6 without needing to convert the infrastructure for their current customers (obviously I'm talking big picture here, I'm not saying it's completely trivial). Also, the IPv4 depletion WILL hit ISPs. The problem is that ISPs can't give their customers IPv6-only connectivity while the content is still only reachable through IPv4.

Also agreed.

>Now here's the philosophical issue: is it better to run IPv6-only + translation to IPv4, or is it better to have dual stack IPv6 + NATed IPv4?
>
>As someone who used to configure routers for a living, my answer is: ditch IPv4 in as many corners of your network as possible, routing just IPv6 is much simpler. But I don't think this sentiment is universally shared.

Agreed; the ISP's I speak with aren't 'ditching IPv4' within their 
backbones; i.e. they see dual-stack for their *backbone* network
infrastructure as somewhat inevitable.   This is not the case for
the ISPs distribution infrastructure, and/or what is finally used to
connect individual customers.  No big new IPv4 address blocks
from the RIR's means no way to assign such blocks to a given
metro region, and this means IPv6 has to be used for expansion.

>An argument that many people aren't going to buy into would be that if IPv4/NAT and IPv6 must be provisioned separately this probably means that in a lot of instances, just IPv4/NAT will be provisioned and even with no new IPv4 addresses available we may not see much IPv6 adoption.

I'm going to elaborate a bit on this: we *will* see ISP's squeezing
IPv4 address space out of every corner of their infrastructure, and
from their downstream customers who had provider assigned (PA)
IP space, and from anyplace else they can get better utilization,
and then reusing the IPv4 pieces within their infrastructure with
something resembling a hard customer requirement that the
customer run NAT internally and live behind a handful of IPv4
addresses.  Whether or not IPv6 will also be available over that
connection depends entirely on the vision of the ISP, and might
be rather depressing for the next few years.

Eventually, ISP's run out of internal and delegated already routed
IPv4 address space remnants, and things begin to get very, very
interesting.  For a short-time, I imagine that there may be some
ISP's who succeed in obtaining new, large, significant IPv4 address
space blocks from sources unknown, and immediately deploy them
for customer growth as described above.  This also works for a short
while, only with whatever expense is occurred obtaining the blocks
added to the operational expense.  The routing impact of this is also
minimal, as it adds many new customers for each new block routed,
and resembles our existing suboptimal-but-working routing dynamics.

FYI - one would hope that the new customers being offered connectivity
behind a handful of IPv4 addresses & NAT is also being offered IPv6
(but then again, it's possible that the IPv6 network upgrade budget
went instead into finding those new IPv4 address blocks... ;-) 

At some point in time, the ability to connect new customers with any
form of provider allocated IPv4 space simply becomes untenable.  For
a while, customers will still be able to get connected with IPv4, under
the innovative "BYOA" (bring your own address) plan.  This is where
the fun really starts, since customers only value IPv4 uniqueness,
and hierarchical original and aggregatability aren't likely foremost in
the mind of the corporate IT manager who's been told to get the
company connected at any cost.  We go through an interesting
period of attempting to add high numbers of very small customer
provided IPv4 blocks completely lacking in hierarchy to the routing
tables, until it becomes painfully obvious that this doesn't work.

At this point (and not much prior in some unfortunate cases), ISP's
will realize the need connect new customers via just IPv6, and have
their customer obtain access to the 'legacy' IPv4-connected portion
of the Internet via some form of NAT-PT or equivalent translation
(with all the downsides that such entails).

>Another argument is that if ISPs are going to do NAT, this pretty much means that most customers, who run their own NAT, are going to be behind two layers of NAT, which is worse than just one layer of NAT. The reason for this is that there is no easy way for an ISP to provision multiple IPv4 addresses on a single customer link. With IPv6+translation you can use DHCPv6 prefix delegation to give users enough IPv6 space for all their hosts and only the translator does a single round of NAT.
>
>In my opinion, we shouldn't try to get consensus on whether IPv6+translation is better than dual stack IPv6+IPv4/NAT, but just go ahead and make the best IPv6+translation solution we can and let the operators choose what they want to deploy.

Thank you.  That's the only responsible approach for the IETF
to take on this issue, since the alternative of insisting on just
dual-stack presumes perfect forecasting of the actual business
situation of every ISP five years from now...

/John

---

From: james woodyatt <[email-masked]>
Date: Mon, 12 Nov 2007 11:01:56 -0800

On Nov 12, 2007, at 01:17, Iljitsch van Beijnum wrote:
> The problem is that there is no operational problem: IPv6  
> deployment can still generously be rounded down to 0.

Some of us would argue that's an operational *solution*, not a problem.

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 12 Nov 2007 20:31:28 +0100

Hi,

> Some of us would argue that's an operational *solution*, not a problem.

So what's your approach to handling the "there won't be any new IPv4
addresses to distribute to customers after a not-so-far-distant point
in the future"?

I'm fairly serious about this - we *will* run into this, and so far, IPv6
seems to be the only solution.  No matter how many rough edges it has
today.

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Mon, 12 Nov 2007 12:05:10 -0800

On Nov 12, 2007, at 11:31, Gert Doering wrote:
>
> So what's your approach to handling the "there won't be any new  
> IPv4 addresses to distribute to customers after a not-so-far- 
> distant point in the future"?

Reduce, reuse, recycle.

> I'm fairly serious about this - we *will* run into this, and so  
> far, IPv6 seems to be the only solution.  No matter how many rough  
> edges it has today.

I'm deadly derious about this too.  If customers demand to use IPv4  
when addresses are in short supply, then I'm sure markets (or  
alternative mechanisms) will find prices for exchanging used  
addresses at which transactions will clear.

If network operators continue not deploying IPv6 services, then  
customer demand for IPv6 service will be met increasingly by tunnels  
over the existing IPv4 infrastructure between endpoint nodes.  This  
is happening today with dual-stack nodes.  The problem before us is  
how to make it happen with IPv6-only nodes.

Some organizations are likely to deploy IPv6-only networks in the  
coming years for reasons mainly unrelated to IPv4 address shortages.   
They will almost certainly end up using some combination of SIIT and  
whatever follows from the work on NAT-PT as their gateway to the  
legacy IPv4 public internet.  The less the IPv4/NAT-based ISP  
community knows about that, the *better*, if you ask me.  If all that  
traffic looks to them exactly like the IPv4/NAT traffic they know and  
love today, all the better.  It keeps them from mucking with things  
that don't belong to them.

Administrators of those gateways between legacy IPv4 and local IPv6- 
only networks will probably need to care about how such gateways  
work, so I think V6OPS is a good place for discussions to that end.    
That said, I disagree with Mr. van Beijnum: it is not an  
*operational* problem that ISP's are not deploying IPv6 service.  It  
is, one could argue, a crude solution to an otherwise thorny problem,  
i.e. how to make the operator community feel warm and comfortable in  
the face of the IPv6 autoconfiguration architecture being difficult  
for them to understand and control.