Subject: Re: I-D ACTION:draft-bagnulo-v6ops-6man-nat64-pb-statement-00.txt

From: Brian Carpenter <[email-masked]>
Date: Thu, 22 Nov 2007 15:55:42 +1300

[Repeated due to a stupid piece of anti-spammery:
Delivery to the following recipient failed permanently:

      [email-masked]

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 13): 550 deferred because 209.85.146.182 is in  a black list at qil.mail-abuse.com]

I guess we're going to discuss this draft on only
one list? This one?

> 1.  Introduction
> 
>    RFC 4966 published on July 2007 deprecates the NAT-PT tool, the
>    mechanism defined by the IETF to enable communications between IPv4
>    only nodes with IPv6 only nodes, letting the dual-stack approach as
>    the preferred mechanism to enable nodes to be able to communicate
>    with v6 and v4 nodes.  However, there are several reasons why the
>    dual stack approach may not be adequate for a number of scenarios.
>    For once, the dual-stack approach imposes the management of two
>    networks in a site, the v6 one and the v4 one, increasing the costs
>    of using IPv6.

I think that's a very weak argument in the next few years. The vast
majority of deployments will be dual stack routing - can you seriously
imagine doing anything else? If you want to make this argument, it should
surely be made only as a long term consideration.

>    In addition, as IPv4 public address space is
>    depleted, it will no longer possible to access to IPv4 public
>    addresses, making dual stack nodes even less attractive.  

Well, if I was implementing a new service, I would work very hard to
get a public IPv4 address for it, so I don't think this argument
works for servers and services for many years to come. It clearly
will apply to client systems much sooner. So I'd rather see the
problem expressed as: New populations of clients (and p2p hosts)
that have no public IPv4 address, but do have plentiful public
IPv6 addresses, which need to contact legacy servers (and p2p hosts)
that have a public IPv4 address (possibly NATted) but no IPv6 capability.

I don't think that changes the technical scenario.

> 3.  Supported application behavior
> 
>    The general purpose of NAT64 type of mechanisms is to enable
>    communication between a v4-only node and a v6-only node.  However,
>    there is wide range of type of communication, when considering how
>    they handle the IP addresses. 

That's true. But are we really aiming to solve all the scenarios
you describe? It seems to me that we probably can't, because
in any case the only safe assumption is that the legacy IPv4 system
is sitting behind a NAPT. And in any case, if we have a translator
with one IPv4 address fronting for 1000 IPv6 hosts, we automatically
inherit *all* the issues of NAPT, including dynamic port mapping
and the need for application level gateways for any address-dependent
applications.

Therefore, is there any point in having any goals that go beyond
"doing no more damage to connectivity than NAPT44 does today"?

In any case I am sure that we will end up with NAPT64, not NAT64.
Port mapping is inevitable.

    Brian

-- 
Regards
    Brian Carpenter
    University of Auckland

---

From: Christian Huitema <[email-masked]>
Date: Wed, 21 Nov 2007 21:46:29 -0800

> that have a public IPv4 address (possibly NATted) but no IPv6

What P2P hosts are we speaking of, exactly? As far as I know, there are very few PC-class hosts that cannot now run some form of IPv6, using a transition technology like Teredo or 6to4. P2P applications are thus very likely to use that.

I suggest that we limit the scope of the problem to enabling IPv6 only hosts to contact legacy IPv4 servers, assuming that these servers in fact have a global IPv4 address. Smaller problems are easier to solve...

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 Nov 2007 09:43:08 +0100

> What P2P hosts are we speaking of, exactly? As far as I know, there  
> are very few PC-class hosts that cannot now run some form of IPv6,  
> using a transition technology like Teredo or 6to4. P2P applications  
> are thus very likely to use that.

There are two types of peer-to-peer: the BitTorrent model, where you  
don't really care who you talk to because multiple peers have the same  
resource. As long as there is a reasonable group of dual stack peers  
there's no need for IPv4 and IPv6 peers to communicate. But with the  
VoIP model you need to be able to talk to any particular peer so here  
it's useful to have a way to make IPv6 peers talk to IPv4 peers and  
vice versa.

Also, users could be running services that aren't necessarily peer-to- 
peer applications. For instance, Apple's "back to my mac" or similar.

> I suggest that we limit the scope of the problem to enabling IPv6  
> only hosts to contact legacy IPv4 servers, assuming that these  
> servers in fact have a global IPv4 address. Smaller problems are  
> easier to solve...

Doing that in the requirements phase would be too soon, in my opinion.

If you look at

http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-02.txt

section 4, you'll see that providing access from IPv4 clients to IPv6  
services is arguably simpler than the other way around...

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Nov 2007 09:41:05 +1300

On 2007-11-22 18:46, Christian Huitema wrote:
> What P2P hosts are we speaking of, exactly? 

Ones that are behind an ISP that not only doesn't support IPv6,
but also has "security" in place that blocks IPv6 tunnels of
all kinds. In this case, a dual stack host has no IPv6 capability.

If that's a null set, I agree with you. But is it?

     Brian

> As far as I know, there are very few PC-class hosts that cannot now run some form of IPv6, using a transition technology like Teredo or 6to4. P2P applications are thus very likely to use that.
>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 22 Nov 2007 16:41:55 -0800

> If that's a null set, I agree with you. But is it?

There certainly are hosts behind such firewalls. But then, firewalls don't just block tunnels. They typically do that to implement a policy. And I believe there is a very large overlap between policies that block tunnels and policies that block P2P applications. The subset of hosts that could do P2P but would not be able to to tunnels is probably very small.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Nov 2007 13:58:33 +1300

> There certainly are hosts behind such firewalls. But then, firewalls don't just block tunnels. They typically do that to implement a policy. And I believe there is a very large overlap between poli…

It's my understanding that many p2p applications revert to running over
http when they can't find any kind of layer 3 connectivity. In the case
we're discussing, that would mean http over IPv4. If there's a dual
stack http proxy on the path, that would fix it.

However, I'd like to hear from the SIP community on this point.
How will p2p SIP work in a mixed network?

     Brian

---

From: Remi Denis-Courmont <[email-masked]>
Date: Fri, 23 Nov 2007 09:27:19 +0100

On Fri, 23 Nov 2007 13:58:33 +1300, Brian E Carpenter

> How will p2p SIP work in a mixed network?

https://datatracker.ietf.org/drafts/draft-ietf-sipping-v6-transition/

chapter 4, in particular:

   Pragmatism dictates that IPv6 user agents undertake the greater

   burden in the transition period.  Since IPv6 user agents are not

   widely deployed yet, it seems appropriate that IPv6 user agents

   obtain IPv4 addresses instead of mandating an upgrade on the

   installed IPv4 base.  Furthermore, IPv6 user agents are expected to

   be dual-stacked and thus also support IPv4, unlike the larger IPv4-

   only user agent base that does not or cannot support IPv6.

   An IPv6 node SHOULD also be able to send and receive media using IPv4

   addresses, but if it cannot, it SHOULD support STUN relay usage [8].

   Such a relay allows the IPv6 node to indirectly send and receive

   media using IPv4.

-- 

Rémi

---

From: David Miles <[email-masked]>
Date: Fri, 23 Nov 2007 22:27:12 +1100

> servers in fact have a global IPv4 address. Smaller problems are  

I'm strongly in favour of Dual Stack for this requirement - again, why  
introduce translation between IPv6 hosts and legacy servers when every  
OS I can think of that supports IPv6 also supports IPv4 through dual  
stack.
My view is that Dual Stack adequately addresses the need for continued  
IPv4 support using existing techniques such as NAPT. After all, if we  
come up with a "translation" protocol for IPv6 to IPv4 then we have  
not absolved ourselves from solving the issue for non-IPv6 hosts. In  
an IPv4 address depleted world, non-IPv6 devices still need to work!  
Why have NAT (in the service provider) for IPv4 hosts, and IPv6-to- 
IPv4 translation for other hosts (likely both existing in the same  
household)? Is this not adding complexity for no obvious business  
benefit?

The only scenario that I can see that we should at least discuss, is a  
day when IPv4 addresses are scarce to the point that one cannot assign  
a server a public v4 address, but we can assign it an IPv6 address. In  
this case an IPv6 host can communicate with the IPv6 server without  
issue, but an IPv4 client cannot. I have always wondered why we are so  
fascinated with NAT64 instead of the reverse, NAT46? Even if we did  
have NAT64 there is still a form of NAPT not dissimilar to today's  
IPv4 implementations, so why not just use NAPT in the service provider  
with Dual Stack?

I'm all for limiting the scope as suggested, but I would like to table  
the issue of a legacy IPv4 host wishing to connect to an server that  
has a valid IPv6 address. Ie, an unsolicited inbound session from the  
IPv4 "client" to an IPv6 "server".

Does anyone consider this a reasonable scenario to consider?

-David

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 23 Nov 2007 14:44:12 +0100

On 23 nov 2007, at 12:27, David Miles wrote:

> again, why introduce translation between IPv6 hosts and legacy  
> servers when every OS I can think of that supports IPv6 also  
> supports IPv4 through dual stack.

Because that way operators need to keep running two versions of IP  
side by side. since everything is reachable over IPv4 anyway, this  
provides essentially zero benefit over the situation where you just  
have IPv4. This means people won't deploy IPv6 but will stick with  
IPv4 even when the layers of NAT are piled on.

With IPv6+NAT-PT on the other hand, the network can be IPv6-only which  
has a number of benefits over an IPv4 network, especially when IPv4  
addresses are scarce.

> After all, if we come up with a "translation" protocol for IPv6 to  
> IPv4 then we have not absolved ourselves from solving the issue for  
> non-IPv6 hosts.

Which issue?

> In an IPv4 address depleted world, non-IPv6 devices still need to  
> work!

They do, you just can't add new ones.

> The only scenario that I can see that we should at least discuss, is  
> a day when IPv4 addresses are scarce to the point that one cannot  
> assign a server a public v4 address, but we can assign it an IPv6  
> address. In this case an IPv6 host can communicate with the IPv6  
> server without issue, but an IPv4 client cannot. I have always  
> wondered why we are so fascinated with NAT64 instead of the reverse,  
> NAT46?

See section 4 of

---

From: Norbert Bollow <[email-masked]>
Date: Fri, 23 Nov 2007 16:51:05 +0100 (CET)

> IPv4 even when the layers of NAT are piled on.

I think I'm getting convinced that your "modified NAT-PT" approach
http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-02.txt
is essentially the way to go.

My only concern is that there is not much time left until IPv4 address
depletion will start causing real problems, and we don't even have a
"finished" RFC for "modified NAT-PT" yet.

How do you see the timeline with regard to getting more feedback on
this I-D, publishing the RFC, implementation and deployment?

Greetings,
Norbert.

-- 
Norbert Bollow <[email-masked]>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org

---

From: David Miles <[email-masked]>
Date: Sat, 24 Nov 2007 11:35:16 +1100

On 24/11/2007, at 12:44 AM, Iljitsch van Beijnum wrote:

> With IPv6+NAT-PT on the other hand, the network can be IPv6-only  
> which has a number of benefits over an IPv4 network, especially when  
> IPv4 addresses are scarce.

I disagree. This approach would require every host within the service  
provider's network to support IPv6. Further, I see a driver for IPv6  
as described below - NAT breaks end-to-end connectivity, IPv6 provides  
an alternative.
>> IPv4 then we have not absolved ourselves from solving the issue for  

What will you do with those devices that do not support IPv6?
> They do, you just can't add new ones.

I'm somewhat confused - are you suggesting the operator runs two  
versions of IP side by side?

-d

---

From: Gert Doering <[email-masked]>
Date: Sat, 24 Nov 2007 13:29:41 +0100

Hi,

> versions of IP side by side?

For the ISPs (as "Internet Operators") this is what I would expect to
happen.

In the core network, v4+v6 in parallel is not hard.

Where it starts to cause more work is things like "getting firewall rules
in sync" and such - but for the basic packet forwarding, this is really not
a major problem.

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

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: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 Nov 2007 13:12:36 +0100

> this I-D, publishing the RFC, implementation and deployment?

That's a good question. I haven't paid attention to any instances of  
the IETF moving fast with a protocol RFC, so I can pretty much only  
guess. But I'd say it would take about a year to reach consensus and a  
stable specification if there is sufficient interest, except that  
carving out a block of IPv4 space for the IPv4-to-IPv6 part could take  
more time.

As for implementations: the IPv4-to-IPv6 part requires some changes to  
existing translators. The IPv6-to-IPv4 part probably doesn't, but I'm  
not completely sure about that. On the (IPv6) host side, the IPv4-to- 
IPv6 part can work for the most part without changes. But the IPv6-to- 
IPv4 part requires changes fairly deep inside the TCP/IP stack, which  
will probably take a considerable amount of time to roll out on  
operating systems like Windows and Mac OS even if Microsoft and Apple  
give this some priority. The problem here is that you don't get much  
benefit until both translators are deployed in the network and  
operating systems are modified to make use of them.

Alternatively, individual ISPs could roll out translators in their  
network and provide customers with CPEs that perform IPv4-to-IPv6  
translation as outlined in section 5 of the draft. These CPEs only  
have to implement SIIT without the NAT part plus some address  
management, so implementing that wouldn't have to take forever. The  
fact that both ends are under the control of the same entity will  
certainly help get things off the ground faster.

I would guess it's reasonably possible (but not a given) to have  
something on the market in 2 years

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 Nov 2007 20:12:30 +0100

> surely be made only as a long term consideration.

but if you hav to do v4, why would you even bother doing v6 at all?  
It is merely an additional cost

> and the need for application level gateways for any address-dependent
but current nat traversal mechanisms enable some of these forms of  
communication even through nats, right?

maybe the requirement should be that we support all the application  
behavours that are currently supported by v4 nat traversal  
techniques, (as oposed to just support the application behaviours  
supported by v4 nats)

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 Nov 2007 20:19:03 +0100

> servers in fact have a global IPv4 address. Smaller problems are  

but this is what basic NAT-PT (FC 2766) does and the actual  
limitations why it was moved to historic don't apply to the basic NAT- 
PT but to the extended scenario, when it supports communications from  
v4 to v6...

so, one option would be to just cut the basic nat pt of RFC 2766 and  
just standarize that part (again)

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 Nov 2007 22:35:57 +0100

On 24 nov 2007, at 1:35, David Miles wrote:

>>> IPv4 then we have not absolved ourselves from solving the issue  
>>> for non-IPv6 hosts.

> What will you do with those devices that do not support IPv6?

Today, the assumption is that all services are available over IPv4. I  
expect this situation to continue for some time, probably even one or  
two years beyond the moment that the first IPv4 address request must  
go unsatisfied because of the depletion. During that time, IPv4-only  
hosts shouldn't have any problems, except of course those introduced  
by measures to conserve IPv4 addresses such as NAT.

At some point, either some services will be available over IPv4 and  
some over IPv6, or the assumption will be that all services are  
availble over IPv6. At that point, IPv4 hosts will need to use  
additional mechanisms but they'll still probably have trouble reaching  
certain services. This is a natural consequence of not adopting new  
technologies within a reasonable timeframe, and I don't think the IETF  
should go out of its way to create workarounds for this.

> versions of IP side by side?

Every ISP that is in business today obviously runs IPv4. In my  
opinion, they should also be running IPv6 within the next three years.  
So that would be a "yes". However, if I were to build an enterprise  
network, I would certainly see if I could limit IPv4 to the places  
where the services run and only do IPv6 in the access part. Running  
just IPv6 is simpler because addressing issues pretty much go away:  
there is no need for routes running OSPF etc to have addresses in the  
same IP subnet. You have more subnets than VLANs, simply encode the  
VLAN ID in the subnet bits and you've numbered all your IP subnets.  
Each of those is a /64 so they can all hold as many hosts as you can  
cram into them, no need to think about how large to make a subnet.  
With EUI-64 addressesing, you don't have to keep track of which router  
holds the .1 address, which holds the .2 address and so on.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 Nov 2007 10:54:19 +0100

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2007 13:36:36 +1300

Marcelo,

On 2007-11-25 08:12, marcelo bagnulo braun wrote:
> but if you hav to do v4, why would you even bother doing v6 at all? It 
> is merely an additional cost

When an ISP can no longer assign IPv4 addresses to new customers, it will
undoubtedly run v4 and v6 in coexistence to service old and new customers
respectively. At that point it will certainly be running major services
like email, http (proxy) and VoIP in dual stack mode - the question is how
to deal with services that aren't naturally dual stacked.

> behavours that are currently supported by v4 nat traversal techniques, 
> (as oposed to just support the application behaviours supported by v4 nats)

Yes. It's another "first do no harm" requirement.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2007 13:41:27 +1300

On 2007-11-24 00:27, David Miles wrote:
>> I suggest that we limit the scope of the problem to enabling IPv6 only 
>> hosts to contact legacy IPv4 servers, assuming that these servers in 
>> fact have a global IPv4 address. Smaller problems are easier to solve...
> 
> OS I can think of that supports IPv6 also supports IPv4 through dual stack.

Because, as already noted, some IPv6-capable hosts (whether servers or
P2P participants) may find themselves stuck in an IPv4-only world. I'd
guess that many Vista hosts are in this situation today.

> come up with a "translation" protocol for IPv6 to IPv4 then we have not 
> absolved ourselves from solving the issue for non-IPv6 hosts. In an IPv4 
> address depleted world, non-IPv6 devices still need to work! Why have 
> NAT (in the service provider) for IPv4 hosts, and IPv6-to-IPv4 
> translation for other hosts (likely both existing in the same 
> household)? Is this not adding complexity for no obvious business benefit?
> 
> day when IPv4 addresses are scarce to the point that one cannot assign a 
> server a public v4 address, but we can assign it an IPv6 address. In 
> fascinated with NAT64 instead of the reverse, NAT46? Even if we did have 
> NAT64 there is still a form of NAPT not dissimilar to today's IPv4 
> implementations, so why not just use NAPT in the service provider with 
> Dual Stack?
> 
> the issue of a legacy IPv4 host wishing to connect to an server that has 
> a valid IPv6 address. Ie, an unsolicited inbound session from the IPv4 
> "client" to an IPv6 "server".
> 

Absolutely, that is the inbound scenario in the Shanti draft,
for example.

    Brian

---

From: David Miles <[email-masked]>
Date: Mon, 26 Nov 2007 23:37:49 +1100

I had not considered the example of the enterprise where what you  
describe makes a lot of sense.

 From a carrier perspective once we move to dual-stack it seems  
unlikely that we would move towards an alternative for v4 (be it NAT64  
or other). I suspect that once dual-stack has been adopted a carrier  
would be reluctant to change as there is minimal (financial) effort.  
In the enterprise space it would seem reasonable to do as you suggest,  
to employ NAT64 given the majority of the applications would be v6- 
enabled.

This leaves the question of NAT46 and what role it should play in a  
transition? Once we pass the point of v4/v6 equilibrium are there  
cases where legacy IPv4 devices may wish to access resources that can  
only support unsolicited inbound connections over IPv6 (servers). The  
alternative to use a public IPv4 address may not be possible if v4 is  
in short supply.

As always adoption of technology will be driven by three related  
attributes: cost, complexity and benefit (or revenue for a carrier).  
For a new network who's applications can be mostly IPv6 (and where OS  
support a v6-only approach) it may make sense to avoid IPv4  
completely. For a network which supports applications that are  
predominately IPv4 a change to IPv6 with translation would be  
difficult to justify, and I'd think we are more likely to see a dual- 
stack approach.

Regards,

-David

On 25/11/2007, at 8:54 PM, Iljitsch van Beijnum wrote:

>>>> After all, if we come up with a "translation" protocol for IPv6  
>>>> to IPv4 then we have not absolved ourselves from solving the  
>>>> issue for non-IPv6 hosts.
>
>>> Which issue?
>
> Today, the assumption is that all services are available over IPv4.  
> I expect this situation to continue for some time, probably even one  
> or two years beyond the moment that the first IPv4 address request  
> must go unsatisfied because of the depletion. During that time, IPv4- 
> only hosts shouldn't have any problems, except of course those  
> introduced by measures to conserve IPv4 addresses such as NAT.
>
> additional mechanisms but they'll still probably have trouble  
> reaching certain services. This is a natural consequence of not  
> adopting new technologies within a reasonable timeframe, and I don't  
> think the IETF should go out of its way to create workarounds for  
> this.
>
> opinion, they should also be running IPv6 within the next three  
> years. So that would be a "yes". However, if I were to build an  
> enterprise network, I would certainly see if I could limit IPv4 to  
> the places where the services run and only do IPv6 in the access  
> part. Running just IPv6 is simpler because addressing issues pretty  
> much go away: there is no need for routes running OSPF etc to have  
> addresses in the same IP subnet. You have more subnets than VLANs,  
> simply encode the VLAN ID in the subnet bits and you've numbered all  
> your IP subnets. Each of those is a /64 so they can all hold as many  
> hosts as you can cram into them, no need to think about how large to  
> make a subnet. With EUI-64 addressesing, you don't have to keep  
> track of which router holds the .1 address, which holds the .2  
> address and so on.
>