Subject: Tunnel-to-NAT scenario

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jun 2008 11:09:11 +1200

Hi,

draft-bagnulo-behave-nat64-00.txt is being discussed
over on the BEHAVE list, and covers the case of an IPv6-only
initiator reaching an IPv4-only server.

I believe that we also need to come up with a solution for an
IPv4 initiator reaching a server with IPv6-only connectivity.
My question is whether we can be satisfied with a solution
that requires that server to be dual stack, so that it can
tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.
(Crude diagram below.)
That seems a lot simpler than developing complete MNAT-PT
or SHANTI solutions, which in can case can never really
offer more transparency that conventional NAT.

If so, we could incorporate a tunnel-to-NAT scenario in
draft-ietf-v6ops-nat64-pb-statement-req.

    Brian

+------+-----+-------+          +------+-----+          +-----+------+
|Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
|      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
+------+-----+-------+          +------+-----+          +-----+------+

---

From: Alain Durand <[email-masked]>
Date: Mon, 16 Jun 2008 20:21:23 -0400

Brian,

It appears that the 'crude diagram below' is identical to the latest
iteration of 464.

  - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jun 2008 13:06:48 +1200

Alain,

That's encouraging.

I think we need a decision at the level of the
problem statement, however.

   Brian

---

From: Alain Durand <[email-masked]>
Date: Mon, 16 Jun 2008 21:29:31 -0400

Brian,

Please note that this work (464pb statement & solution) is taken to
softwires.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 17 Jun 2008 03:42:21 -0400

On 6/17/08 3:38 AM, "Rémi Després" <[email-masked]> wrote:

> Alain Durand  - Le 6/17/08 3:29 AM :
>> Brian,
>> 
> is this to imply that the following drafts should from now on be
> discussed in Softwires?
> - draft-ietf-v6ops-nat64-pb-statement-req-00.txt
> - draft-bagnulo-behave-nat64-00.txt
> Any pointer to clarify where we stand would be useful.

No. I'm only talking about Nat464.

  - Alain.

---

From: Rémi Després <[email-masked]>
Date: Tue, 17 Jun 2008 09:38:22 +0200

Regards.

Rémi

---

From: Rémi Després <[email-masked]>
Date: Tue, 17 Jun 2008 10:43:43 +0200

> No. I'm only talking about Nat464.

Thanks.
Still ambiguous IMU on the "pb statement" part of 464, but OK.

BTW is there a place where what is meant by NAT464 or "464 NAT" is 
defined in more details than in 
http://www.arin.net/meetings/minutes/ARIN_XXI/PDF/tuesday/464-ARIN_Durand.pdf 
?

Rémi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Jun 2008 12:24:19 +0300

Softwires is taking the solution that involves tunneling private-space 
v4 over a v6-only cloud, and then doing a NAT towards the public v4 
Internet.

The rest should still be discussed in V6OPS. Are we done with the 
problem statement, by the way? I would recommend completing it and 
shipping it as an RFC as soon as possible.

The actual protocol work (like Marcelo's draft on nat64, for instance) 
will happen elsewhere. The IESG is currently looking at rechartering 
BEHAVE WG to do this work.

Jari

---

From: Rémi Després <[email-masked]>
Date: Tue, 17 Jun 2008 11:42:14 +0200

A variety variety of 464 configurations, with pros and cons, are being 
discussed.
IMO they deserve some clarification.
(464 is taken here as meaning "any scenario where a source v4 packet has 
to be delivered to a destination in v4, possibly modified, via a v6-only 
zone.)

Let:
- Cx     mean  Client using x packets (4 or 6)
- Sy     mean  Server using y packets (4 or 6)
- 4p     mean  private IPv4 (10... etc)
- 4/6    mean  v4 in v6 encap-decap
- NATxy  mean  NAT with x inside to y outside
- Bc     mean IPv4 plus Address and port Borrowing Protocol-Client
- Bs     mean IPv4 plus Address and port Borrowing Protocol-Server

Then we have (at least) the following scenarios:

1.
(C4 4)--4p--(NAT44 4/6)--6--(4/6+ S4)
     The "Tunnel to NAT scenario" above of Brian
     (where the server needs a modified dual stack).

2.
(C4 4)--4p--(NAT46 6)--6--(6 NAT64)--4--(4 S4)
     The "464NAT demo at IETF71" of Alain, ref 
http://www.arin.net/meetings/minutes/ARIN_XXI/PDF/tuesday/464-ARIN_Durand.pdf.

3.
(C4 4)--4p--(NAT44 4/6)--6--(4/6 NAT44)--4--(4 S4)
     The SNAT of Ralph Droms, ref 
http://tools.ietf.org/id/draft-droms-softwires-snat-00.txt.

4.
(C4 4)--4p--(NAT44 Bc 4/6)--6--(4/6 Bs 4)--4--(4 S4)
     My NAT44+APBP scenario, ref sec. 2 of 
http://tools.ietf.org/id/draft-despres-v6ops-apbp-00.txt.

5.
(C4 Bc 4/6)--6--(4/6 Bs)--4--(4 S4)
     My APBP-E2E scenario,  sec 5.2 of 
http://tools.ietf.org/id/draft-despres-v6ops-apbp-00.txt.

Using some kind of shorthand like this one would IMO help identifying 
which scenario does what.

Regards.

Rémi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 17 Jun 2008 13:14:17 +0200

> tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.

[...]

How does the tunneling help? The actual packet mangling should be  
simple enough, the problem is that the client can't express the IPv6  
destination in an IPv4 packet without modifications to the IPv4 client  
(and those modifications would be unlikely to work through middleboxes).

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 17 Jun 2008 13:10:23 +0200

On 17 jun 2008, at 11:24, Jari Arkko wrote:

> Softwires is taking the solution that involves tunneling private- 
> space v4 over a v6-only cloud, and then doing a NAT towards the  
> public v4 Internet.

I have a problem with that.

In my opinion, it's an open question whether tunneling is a better  
approach than translation for this use case (IPv4 clients connecting  
to IPv4 servers through an IPv6 network). Doing the work in softwires  
de facto answers that question through process rather than consensus.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Jun 2008 14:47:36 +0300

Iljitsch,

> de facto answers that question through process rather than consensus.
Softwires have been told that they shall employ tunneling to cross the 
v6-only cloud. The NAT that I mentioned comes only after this; its 
almost completely a separate component (except for the fact that you 
need to know which tunnel interface packets came on to deal with 
overlapping RFC1918 space at the customer sites).

I hope no one is no longer arguing that we should do a double NAT. I 
think that would be wrong because tunneling ensures that your IPv4 
traffic is as intact as possible. Yes, it may eventually get NATted, but 
I do not want to create technology that forces you to do it no matter 
what is at the other end. For instance, with a tunnel-based crossing of 
the v6-only cloud customers sites that have public IPv4 space will not 
see any NAT effects.

Jari

---

From: Rémi Després <[email-masked]>
Date: Tue, 17 Jun 2008 14:35:34 +0200

Jari Arkko  - Le 6/17/08 1:47 PM :
> ... tunneling ensures that your IPv4 traffic is as intact as 
> possible.

In this respect, The APBP-E2E scenario of draft-despres-v6ops-apbp-00
sec. 5.2 goes *one step further* than Tunnel-to-NAT.

When a (modified) dual stack client connects to a v4-only server:
- v4 packets are unchanged E2E.
- The (dual stack) client application sees its public v4 address, so 
that no NAT is needed.

It then seems that, if and when time comes to discuss the APBP protocol, 
after the problem statement, Softwires would be the right place.

Regards.

Rémi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 17 Jun 2008 14:40:06 +0200

On 17 jun 2008, at 13:47, Jari Arkko wrote:

> traffic is as intact as possible. Yes, it may eventually get NATted,  
> but I do not want to create technology that forces you to do it no  
> matter what is at the other end. For instance, with a tunnel-based  
> crossing of the v6-only cloud customers sites that have public IPv4  
> space will not see any NAT effects.

I agree that in the case of passing IPv4 through IPv6 without NAT  
tunneling is better. However, the case that we're discussing here is  
the one where there is also NAT involved. In that case, pretty much  
all the fields in the IPv4 header are mangled/ignored anyway, so there  
is no real value in carrying them across the IPv6 cloud intact.

Basically, by borrowing 32 bits of the IPv6 destination in the IPv6  
header, we can compress away the entire IPv4 header because none of  
the fields in there are needed later.

By going one step further and also adjusting the transport checksums  
it's possible to use the same NAT64 that also serves IPv6 hosts that  
want to talk to IPv4 destinations, which saves implementing two sets  
of translators or translators that support two different types of  
translation.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Jun 2008 16:00:28 +0300

Remi,

> It then seems that, if and when time comes to discuss the APBP 
> protocol, after the problem statement, Softwires would be the right 
> place.

Does APBP involve host changes?

The work put to SOFTWIRE is a very specific task: cross the v6-only 
cloud using tunneling, allow optional fairly standard NATting at the 
other side to handle overlapping RFC1918 space, no changes at all in the 
subscriber sites or hosts. That WG has a lot of expertise in getting 
tunneling like this to work.

However, generally speaking other protocol work will go elsewhere, as 
soon as we know what that work is. The reason why SOFTWIRE is having a 
head start is that they are attacking a separable, reasonably well 
understood part of the overall space that fits the profile of an 
existing WG. We are looking at rechartering BEHAVE for the rest of the work.

Jari

---

From: Remi Denis-Courmont <[email-masked]>
Date: Tue, 17 Jun 2008 15:21:50 +0200

On Tue, 17 Jun 2008 11:09:11 +1200, Brian E Carpenter

> (Crude diagram below.)

Operating systems will continue to ship with IPv4 built-in for as long as

it is useful (i.e. very long). On top of that, IPv6 and IPv4 support tend

to be intertwined if only for the sake of dual-stack functions (mapped

addresses, address selection, automatic transition mechanism setup, etc).

So I guess we can assume IPv4 support for as long as it is potentially

useful. This may also be a self-realizing prophecy: if dual-stack is needed

on IPv6-only nodes, IPv6-only nodes will continue to have dual-stack.

> offer more transparency that conventional NAT.

Indeed.

-- 

Rémi Denis-Courmont

http://www.remlab.net

---

From: Rémi Després <[email-masked]>
Date: Tue, 17 Jun 2008 15:49:24 +0200

> Does APBP involve host changes?
- No host change is "required". If there is none, the scenario that fits 
is NAT44+APBP in the CPE.
- In the APBP-E2E scenario, a dual stack client connects to a v4-only 
server. (The "change" in the dual stack, i.e. the APBP client support, 
is the price to get E2E v4 connections from a site hat has no public v4 
address.)

> subscriber sites or hosts. 
- "No change at all in the subsriber sites" seems strange to me.
IMU something has at least to be said for tunnels to be established and 
released, and for v4 packets to be routed to the tunnels.
- But I understand that, provided the softwires machinery is already 
present in the CPE, this can be a small change.

> existing WG. We are looking at rechartering BEHAVE for the rest of the 
- Any WG is fine. The only concern is that respective scopes of Softwire 
and Behave aren't, at the end, both so restrictive that a solution like 
APBP, that uses tunnels and doesn't use NATs in all cases, has no place 
to be discussed.

Regards.

Rémi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Jun 2008 17:15:32 +0300

Remi,

> - "No change at all in the subsriber sites" seems strange to me.

Obviously there has to be a change in the border between the subscriber 
site and the v6-only network. The tunneling box needs to do something. 
But no changes in the hosts in the subscriber side, for instance.

>> soon as we know what that work is. The reason why SOFTWIRE is having 
>> a head start is that they are attacking a separable, reasonably well 
> - Any WG is fine. The only concern is that respective scopes of 
> Softwire and Behave aren't, at the end, both so restrictive that a 
> solution like APBP, that uses tunnels and doesn't use NATs in all 
> cases, has no place to be discussed.
Right. On initial look, your mechanism seems more of a general nature 
than the specific case sent to SOFTWIRE.

Jari

---

From: Rémi Després <[email-masked]>
Date: Tue, 17 Jun 2008 18:37:16 +0200

Jari Arkko  - Le 6/17/08 4:15 PM :

> ... On initial look, your mechanism seems more of a general nature 
IMHO it has more similarities with the work of SOFTWIRE than you have 
found:
- It has tunnels the endpoint of which can be in hosts or router CPEs.
- For the v4-v6 coexistence ad hoc functions are needed in both router 
CPEs and in ISP infrastructures.

The main difference with Tunnel-to-NAT, for the same 464 paths, is that 
NAT44 is in CPEs rather than in the ISP infrastructure.
- The disadvantage is more work left on specification (but IMO not so 
complex)
- The main advantage is a better scalability. (And the next advantage is 
E2E native IPv4 in client hosts that support APBP).

Anyway, it seems too early to decide where APBP would fit.
Discussing it in Dublin would IMO make sense.

Rémi

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 17 Jun 2008 20:19:57 +0300

> the v6-only cloud customers sites that have public IPv4 space will not

Yeah. In practice, there may very well already be two NATs:
- the cheap off-the-shelf access point plugged in next to the 464 CPE [1],
- the hyper-NAT at the ISP end of the 464.

So you're talking about triple NAT :)
Indeed, that might not be such a great idea.

[1] However fully-feature the ISP-provided CPE may be, a significant 
proportion of users will keep doing this.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jun 2008 09:45:25 +1200

Iljitsch,

On 2008-06-17 23:14, Iljitsch van Beijnum wrote:
> How does the tunneling help?

Er, it gets IPv4 packets across the IPv6-only network.

> The actual packet mangling should be simple
> enough, the problem is that the client can't express the IPv6

That's why you go to a traditional v4-to-v4 NAT at the boundary.
No new mangling code is needed. From the v4 point of view this
is bog standard NAPT with configured port mapping. I'll have to
look at Alain's draft to see if he's already written up the
whole thing, or if I need to write more.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 18 Jun 2008 00:02:17 +0200

> is bog standard NAPT with configured port mapping.

So if you're an IPv4 client and I'm an IPv6 server with address  
2001:db8:31::1, what do you put in the destination address of the IPv4  
packets you send to me?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jun 2008 10:07:44 +1200

> No. I'm only talking about Nat464.

And I was referring to draft-ietf-v6ops-nat64-pb-statement.

If 464 solves this problem, fine, but we should keep the
overview in v6ops, I believe.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jun 2008 10:18:08 +1200

> 2001:db8:31::1, what do you put in the destination address of the IPv4

The public address of the NAT to which you are tunneling. Of course,
that NAT has to be configured to forward port N through a tunnel
to whatever IPv4 address 2001:db8:31::1 has borrowed.

(draft-despres-v6ops-apbp-00.txt would automate the borrowing
process, if you don't want to configure it.)

This doesn't get rid of NAPT nastiness for supporting servers.
But if someone insists on running a server for IPv4 clients that
doesn't have its own public IPv4 address, that nastiness is
intrinsic. The question is what's the simplest way to deal
with it.

    Brian