Subject: [Softwires] Discussion on the requirements of Host Based Translation

From: Hui Deng <[email-masked]>
Date: Mon, 23 Nov 2009 15:19:04 +0800

Dear Alain and Sri,

I guess that you two have already read below draft:
http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt
This draft has been presented in detail during the last IETF meeting.

During the meeting, you two have standed up and said that
DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to
host direct communication.
I really cann't understand it, could you help to elbaroate more here
about details?

Many thanks for your kind explanation.
Best regards,

-Hui Deng

---

From: "Durand, Alain" <[email-masked]>
Date: Mon, 23 Nov 2009 11:53:41 -0500

Hui,

If I understand your requirements:
1. v6 only network 
2. v4 apps 
3. low encap overhead
4. direct ³shortcut² communications between 2 adjacent nodes

1 & 2 are already met by the current DS-lite
3 is a matter of opinion... Is an extra IPv4 header (20 byte) that much of a
deal?
When we looked at softwire hub&spoke a few years back, the wg consensus was
that the extra overhead of encapsulation was worth it.
You can use some form of header compression to mitigate this overhead. How
to use header compression in that case can be defined in softwire
4 could be a very straightforward extension of DS-lite. If you know the
common IPv6 prefix shared by adjacent nodes, you can directly tunnel to
them.
In practice, you¹ll have a default route to the AFTR and a subnet route for
the ³local² prefix.

  - Alain.

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Nov 2009 10:10:20 -0800

On Nov 23, 2009, at 08:53, Durand, Alain wrote:
> 
> 4 could be a very straightforward extension of DS-lite. If you know the common IPv6 prefix shared by adjacent nodes, you can directly tunnel to them.
> In practice, you’ll have a default route to the AFTR and a subnet route for the “local” prefix.

Also, to support the direct host-to-host tunneling, the DS-lite extension would need to allow for many DS-lite subscribers to share a single IPv4 private address realm.  I think DS-lite currently requires that each IPv6 subscriber is isolated within their own IPv4 private address realm, and therefore a twice-NAT44 gateway is required for IPv4-only applications to communicate between DS-lite subscribers.

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

---

From: "Durand, Alain" <[email-masked]>
Date: Mon, 23 Nov 2009 14:30:13 -0500

Yes... Whenever you do the shortcuts, you bump into the non trivial
questions to know who you are talking to...
Now, if v4 addresses are allocated via DHCPv4 over the IPv6 tunnel, this
problem can be solved. Is it worth the effort or not depend on how much the
shortcuts are going to save you...

  - Alain.

On 11/23/09 1:10 PM, "james woodyatt" <[email-masked]> wrote:

>> common IPv6 prefix shared by adjacent nodes, you can directly tunnel to them.
> Also, to support the direct host-to-host tunneling, the DS-lite extension
> would need to allow for many DS-lite subscribers to share a single IPv4
> private address realm.  I think DS-lite currently requires that each IPv6
> subscriber is isolated within their own IPv4 private address realm, and
> therefore a twice-NAT44 gateway is required for IPv4-only applications to
> communicate between DS-lite subscribers.
> 
> 
> --

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 24 Nov 2009 00:34:28 +0100

> shortcuts are going to save you...

Agree. Bumped hard into that once... :)

Jan Zorz

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 23 Nov 2009 16:18:24 -0800 (PST)

Hi Hui,

Adding to what Alain already said.

When you projected the slide that compared various transition
approaches, for the UE to UE bullet point, for the Gateway
Initiated Dual-stack lite solution, you have marked it as
"Unsupported or No". So, I asked the question, is it for
over-lapping or a non-overlapping case and from our conversations
offline and online both at Shanghai and at the IETF, you said
it was about non-overlapping case.

Now, for this case, in the proposal we have, any IPv4 traffic
from the UE, always hits the GGSN over the mobility tunnel. At
the GGSN, its a routing decision to forward the traffic to
the internet via CGN, over the CGN tunnel, or local foward. If
its a local forward, the packet is routed to the target UE/SGSN
over a different mobility tunnel. The GGSN is the anchor and
all traffic goes through that point and it can local forward.
That's how we can support this scenario.

For the case of overlapping IP, we talked to many operators
and no one confirmed that they have a legacy application that
are supported in this mode. So, the general thought was to have a
sensible approach of using IPv6 transport for such applications.
Now, if we argue that we need to support over IPv4 transport,
we need to ask many questions, as how the application resolution
happens, how the application server delivers that information
and how it learns the NAT'd address of a UE ..etc. These are
unresolved questions both as a requirement and even for PNAT
if you pitch a solution based on host translation. As I see it,
its a new requirement and as Alain/Dan Wing pointed out, there
are potential ways to solve it. In simple terms, what ever you
do on the host, we can infact solve it on the network.

Now, moving to your other pointer and the motivation for the PNAT
work, you have listed:

a.) a need to support IPv6-only transport network
b.) support IPv4 legacy applications, over a IPv6 transport
c.) avoid airlink over-ahead
d.) enable UE to UE comminication.

For #a and #b, mobility architectures and the solution we have allow
the case where the access network and the core network is either
IPv4 or IPv6. There is no issue on this aspect.

For #c, our solution does not introduce any air link over-ahead, as
there is no tunnel from the UE. We dont have the host architecture, or
touch the UE.

For #d, the solution can support UE to UE over IPv4 or IPv6 transport,
for the non-overlapping case. For overlapping case, we will plug in the
feature as needed.

Also, I'd like to remind that your slide missed number of other bullet
points, for example, it should have had a bullet point, "Changes to
host architecture", with a marking "Yes" to PNAT solution, and "No" to
Gateway Initiated Dual-stack lite solution. Since, its not a trivial
design point that you can ignore.

Regards
Sri

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 00:25:35 +0800

Alain,

Thanks for your explanation, let me try to figure out what you are
proposing here:

2009/11/24 Durand, Alain <[email-masked]>:
> v6 only network
> v4 apps
> low encap overhead
> direct “shortcut” communications between 2 adjacent nodes
>
some mobile operators like us have different opinion on it

> to use header compression in that case can be defined in softwire
it is not that easy to do backward compatibility, and it's really hard
to use it today

> common IPv6 prefix shared by adjacent nodes, you can directly tunnel to
I don't understand here, are you suggesting all DS-Lite host has common IPv6
prefix? what kind of direct tunnel could be established?

> In practice, you’ll have a default route to the AFTR and a subnet route for
I don't understand here either, you are saying there are IPv4 subnet
route in the IPv6 only network?

Many thanks for the discussion

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 00:29:10 +0800

so DS-Lite need double translations of NAT44 to support host to host
communication?

-Hui

2009/11/24 james woodyatt <[email-masked]>:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 00:31:13 +0800

so you are proposing assign different IPv4 address to the DS-Lite host,
is this public or private?

I still don't understand how this tunneling could be setup between hosts?

thanks

-Hui

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 24 Nov 2009 11:33:53 -0500

This is only require if you do not have a unique IPv4 address per node.
What I'm suggesting is to allocate/derive a unique v4 address to each node.
It can be done either by running DHCPv4 over the DS-lite tunnel, or defining
an IPv4 allocation option for DHCPv6 or defining a mechanism to
automatically derive a unique v4 address from the DHCPv6 assigned v6
address.

  - Alain.

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 00:37:34 +0800

Hi, Sri,

1) Regarding overlapping case, I am assuming  that GW-Init-DS-Lite
assign the same Ipv4 address to the UE?
2) You are proposing add new bullet, but that is not our requirement,
we are not compare the solution, just do requirement gap analysis,
3) I got your point that host to host communication will be done by
Access router, you are assuming point to point to AR
other than shared link.

thanks for the discussion.

-hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 00:39:45 +0800

ok, suppose that you have such smart way to do IPv4 address assignment
(that is not adopted by IETF, just a remindness)
then how could you do host to host communication in the IPv6 only network?

-hui

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 24 Nov 2009 11:51:17 -0500

Say you know both v4 & v6 prefixes associated to the scope.
Say you want to communicate with node B with that v4 scope.
You create a v6 address for B. That v6 address is reverse-derived from B's
v4 address. Now, you encapsulate the v4 packet into a v6 packet.
v6 src is yours, v6 dst is B's reverse-derived v6 address.

  - Alain.

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 24 Nov 2009 11:46:16 -0500

> it is not that easy to do backward compatibility, and it's really hard

There are games we can play to "port" the relevant v4 header fields in the
v6 header and remove the v4 header all together... As long as this is done
on a link between two consenting nodes, this is fine.

> prefix? what kind of direct tunnel could be established?

What I'm suggesting is to define a 'scope' in which nodes can talk directly
using the shortcuts. It makes little sense to 'short cut' with a node on the
other side of the country, but I understand why you'd want to do this
between two nodes that are behind the same base station.

Within the scope, each node has a unique v6 address and a unique v4 address.
(again, either derived from the v6 or assigned via DHCP). Net 10 should be
big enough for that.

You pass both v6 and v4 prefixes via DHCPv6 to all nodes within that scope.
That way, when a node sees that the IPv4 address returned by (say split) DNS
is within the v4 prefix, it can use the v6 prefix to 'tunnel/route' the
packets.

   - Alain.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 24 Nov 2009 09:38:55 -0800 (PST)

Hi Hui,

> assign the same Ipv4 address to the UE?

Sure, the same IPv4 address can be allocated as in DS lite base proposal.

> we are not compare the solution, just do requirement gap analysis,

Changes to the host is not a "requirement". But, its a cost for
a specific solution. When you are comparing multiple solutions,
its logical you present both the key positive and negative aspects
of the solution. Minor aspects, you can hide or ignore. But, host
change is a significant point of discussion, that you cant avoid
to discuss. But, its your slide and your call.

> Access router, you are assuming point to point to AR

Mobile architectures, CDMA, LTE, or WiMAX or based on point to point
link models on the access link. Mobile architectures is one of the
key areas where the Gateway Initiated DS lite solution can be applied.
For other architectures where shared links are in place, the access
router maintains the association between the MAC/IP/GRE Key, so it can
L2 forward the IP packet based on the state.

Regards
Sri

---

From: james woodyatt <[email-masked]>
Date: Tue, 24 Nov 2009 11:04:26 -0800

> This is only require if you do not have a unique IPv4 address per node.

I think you meant to say "a unique IPv4 address *realm* per node" there.

> What I'm suggesting is to allocate/derive a unique v4 address to each node.

A more flexible approach would be to derive a unique IPv4 private subnet for each DS-lite node in a given private address realm with a bijective mapping to its IPv6 address.

> automatically derive a unique v4 address from the DHCPv6 assigned v6

I don't see a good reason to muck with DHCPv6 here.

I'd suggest using DHCPv4 over the DS-lite tunnel.  That way a DS-lite gateway could use a DHCPv4 relay and serve addresses to its local IPv4 links.  The bijective mapping between IPv4 subnets and IPv6 addresses would permit DS-lite hosts and gateways to tunnel directly over IPv6 without passing through the service-provider NAT44 gateway.  Of course, DS-lite hosts and gateways could also use IPv4 stateful filtering for local host and network protection.  That's an orthogonal problem.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 24 Nov 2009 15:14:52 -0800 (PST)

Hi Hui, Sri,

----- Original Message ----
> From: Sri Gundavelli <[email-masked]>
> To: Hui Deng <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, November 24, 2009 11:38:55 AM
> Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation
> 
> Hi Hui,
> 
> 

Absolutely.

I would even go as far as to say that the packet should go upstream to an anchor node such as GGSN/P-GW in 3GPP or HA/LMA in WiMAX. Access router doing the host to host communication is possible only for Simple IP case in WiMAX at ASN-GW.

Regards,

Behcet

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 22:55:05 +0800

Besides the above email questions, more below
How this solution scale for huge number of subscriber?
wouldn't such scope definition is too complex,  not easy work for the
operations?

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 22:58:40 +0800

Hi ,Sri,

> Sure, the same IPv4 address can be allocated as in DS lite base proposal.
if you have same IPv4 address, how could route packet directly each other?

> to discuss. But, its your slide and your call.
I guess that we are talking different things, you are always asking comparision.
but I am talking about the requirements gap analysis.

> L2 forward the IP packet based on the state.
Let's discuss it step by step. for the same IP address, how access
router directly
route each other for the host?

Regards,

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 22:59:40 +0800

Hi, Behcet,

so there are most  other cases, they don't support direct routing.

thanks

-Hui

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 25 Nov 2009 10:03:31 -0500

It is actually fairly easy to scale... Use a copy of Net 10 for each of your
access router...
In the end, this all depend on your access topology, where the first L3 node
is and where you intend to put the AFTR.
If both are co-located, then solution like gateway initiated DS-lite or
simply assigning a regular IPv4 address are really much simpler.
If the AFTR is a little further inside the network,  the complexity price to
pay for shortcuts may not be justified. If the AFTR is way inside the
network, then shortcuts may be useful. Note: The Œv4 scopes¹ does not have
to match the AFTR scope... It has to match the scope of the entity that
proxy-manages IP address allocation, typically the first L3 router acting as
DHCP-relay.

  - Alain.

On 11/25/09 9:55 AM, "Hui Deng" <[email-masked]> wrote:

>>>>>>> >>>>>> In practice, you¹ll have a default route to the AFTR and a subnet
route
>>>>>>> >>>>>> for

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 22:52:10 +0800

Let's continue discuss and will summarize after

> on a link between two consenting nodes, this is fine.
==> what u suggest here is still same as the header compression.

> is within the v4 prefix, it can use the v6 prefix to 'tunnel/route' the
if the application generate IPv4 packet, and finally you will be use
IPv6 to transmit this packet,
isn't this a translation?

Secondly, when the receiver host got this packet, how could he know
this is normal IPv6 packet
or IPv4-translated-IPv6 packet?

thanks again

-Hui

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 25 Nov 2009 10:07:41 -0500

On 11/25/09 9:52 AM, "Hui Deng" <[email-masked]> wrote:
> --> No, this is tunneling. You preserver the v4 header. If header compression
> removes it, it it put back in place on the receiving side
> 
> --> This is not translated, but tunneled. The packet arrives to a tunnel
> interface that will de-capsulate the v6 header and present the v4 packet to
> the v4 app. Think about 6to4 or 6rd, but with the reverse encap.
> 
>     - Alain.
>

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 23:42:19 +0800

inline please

2009/11/25 Durand, Alain <[email-masked]>:
> --> No, this is tunneling. You preserver the v4 header. If header
> compression removes it, it it put back in place on the receiving side
I don't know this is tunnleing, then how this tunneling is setup
between two hosts directly?
Are you assuming what kind of destination address the source host can
get (IPv4 A record or IPv6 AAAA record)?

> the v4 app. Think about 6to4 or 6rd, but with the reverse encap.
Same questions above, are you assuming the destination have to support
it as well?

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 25 Nov 2009 23:47:04 +0800

Inline please

> It is actually fairly easy to scale... Use a copy of Net 10 for each of your
then inter access router doesn't work

> is and where you intend to put the AFTR.
exactly, for my knowledge, this L3 node is not the same location as NAT.

> network, then shortcuts may be useful. Note: The ‘v4 scopes’ does not have
isn't it sounds complexity network operation, it will be quite hard to
support roaming.

-Hui
>>>>>>> In practice, you’ll have a default route to the AFTR and a subnet
>>>>>>> route
>>>>>>> for
>>>>>>> the “local” prefix.
>>>>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Nov 2009 08:27:17 -0800

Hi Hui,

> if you have same IPv4 address, how could route packet directly each other?

You are talking about the UE to UE for the overlapping IPv4 case. As I
explained in my long email earlier, we support the case for UE to UE
non-overlapping case. For the case of overlapping there are no legacy
applications that operate in that mode and there are no requirements either.
Our approach is to suggest IPv6 transport for such scenario. There are also
other ways to solve the problem, such as implicit IPv6 tunnels as
Alain/Dan's draft, or stateful mode on the gateway.

But, I thought you always agreed, you are talking about the non-overlapping
case only ? Departure from that stand and PNAT can now do that ? Fine. How
does that work for PNAT ?

- How does the application server learn the IPv4 address of the UE ?
- How does the peer IP resolution happen ?
- If the address is delivered inside the application payload, how do you
handle that ? Where is the mapping state maintained ?
- What new ALG's is this requiring ?
- Can you give the flow ?

And, why is this a legacy requirement ?

> but I am talking about the requirements gap analysis.

:) No, we are talking about the slide that you compared and graded different
solutions. But, fine, I will let it go. But, all the features that we talked
about other than non-overlapping UE to UE, we both support. For overlapping
IP and UE to UE, we can identify the requirements first.

> route each other for the host?

Yes. See above, #1.

Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 28 Nov 2009 16:12:53 -0800 (PST)

Hi Alain,
  In the so-called access model, the host uses IPv4-in-IPv6 tunnel. My question is, can an unmodified host do this, i.e. send and receive encapsulated/decapsulated packets? Or do we need a "Softwire Client" at each host?

--behcet

>
>From: "Durand, Alain" <[email-masked]>
>Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; "Cao, Zhen" <[email-masked]>; [email-masked]
>Sent: Wed, November 25, 2009 9:07:41 AM
>Re: Discussion on the requirements of Host Based Translation >
>
>
>>>>--> No, this is tunneling. You preserver the v4 header. If header compression removes it, it it put back in place on the receiving side
>>
>>>>--> This is not translated, but tunneled. The packet arrives to a tunnel interface that will de-capsulate the v6 header and present the v4 packet to the v4 app. Think about 6to4 or 6rd, but with the reverse encap.
>>
>>>>    - Alain.
>>
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 28 Nov 2009 16:18:55 -0800 (PST)

Hi Hui,

----- Original Message ----
> From: Hui Deng <[email-masked]>
> To: "Durand, Alain" <[email-masked]>
> Cc: ietf softwire <[email-masked]>
> Sent: Wed, November 25, 2009 9:47:04 AM
> 2009/11/25 Durand, Alain :

In general this is true. However by carefully placing AFTR we can handle mobility. In 

draft-sarikaya-softwire-dslitemobility-01

we have collocated AFTR with either HA or LMA. Also you need to coordinate NAT operations with binding cache searches.

In fact DS-Lite becomes a good match with PMIPv6 or DSMIP protocols.

Regards,

Behcet

---

From: Hui Deng <[email-masked]>
Date: Mon, 30 Nov 2009 14:40:23 +0800

Hi, Sri,

Inline

> Alain/Dan's draft, or stateful mode on the gateway.
For non-overlapping IPv4 case, how IPv4 address assgined to the UE,
will it based on v6 only PDP or v4v6 PDP?
could you help to point out Alain/Dan's draft, thanks,

> And, why is this a legacy requirement ?
There are misunderstanding about what we require, I will point out in
the seperate email.

thanks

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 30 Nov 2009 19:21:39 -0800

Hi Hui,

Please see inline.

> could you help to point out Alain/Dan's draft, thanks,

UE will be assigned a single Dual-stack PDN bearer, with PDP context of type
v4v6. This will allow the network to carry both v4 and v6 UE packets.

Now, the access network from SGSN to GGSN, or the core network from GGSN to
CGN, can be IPv6-only. Only, the UE is dual-stack supported, with this we
are logically restricting the use of IPv4 to UE and on the CGN, removing its
traces any where else in the network. IPv4 essentially becomes a mere state
on the CGN and on the UE with no IPv4 routing in the network, so it provides
a simple migration path to IPv6-only network.

I will let Alain and Dan provide the pointers to their draft, its not my
work.

> There are misunderstanding about what we require, I will point out in

Ok. I will look for these answers in the other email :)

Regards
Sri