Subject: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6

From: <[email-masked]>
Date: Thu, 13 Feb 2014 05:45:00 -0800 (PST)

A new draft has been posted, at http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a look at it and comment.

---

From: Cb B <[email-masked]>
Date: Thu, 13 Feb 2014 05:53:54 -0800

> A new draft has been posted, at http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a look at it and comment.

This draft is suggesting modification to the 3GPP defined nodes such
as the eNodeB and PGW.  It would be better if these modifications to
3GPP defined nodes were examined in the 3GPP, not the IETF.

CB

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 Feb 2014 14:58:55 +0100 (CET)

On Thu, 13 Feb 2014, [email-masked] wrote:

> A new draft has been posted, at 
> http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a 
> look at it and comment.

This document makes me very confused.

Traditionally, the eNodeB has basically done GTP-RLC (or whatever protocol 
is used on the radio layer) conversion. All the setup has been done using 
3GPP protocols.

This document proposes to use DHCPv6oDHCPv4 with the eNodeB as a *client*. 
When I read the document, I don't understand what communication is done 
within the GTP tunnel, what is done outside the tunnel, and what role the 
eNodeB has in this.

In 4 for instance:

"The architecture described here addresses a typical use case, where
    an eNodeB's uplink supports IPv6 only and a UE using IPv4 in this
    eNodeB wants to access IPv4 Internet.  The network architecture is
    shown in Figure 1.  In this scenario, the UE can only use the IPv6
    network to access IPv4 services, so IPv4 services must be configured
    over IPv6."

I don't understand this statement. It's completely possible to set up an 
GTP tunnel over IPv6, which then can carry both IPv4 and IPv6 traffic. So 
it's not problem to support UEs with IPv4, IPv6 or DS uplinks, in current 
3GPP architecture, over a pure IPv6 mobile backhaul network.

I'm very confused what problem this document tries to solve.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Qi Sun <[email-masked]>
Date: Fri, 14 Feb 2014 10:10:23 +0800

Hi Mikael,

Thanks for your comments! Please see inline.
Please don't hesitate to point out if there is any mistake. Thank you!

//sorry for send it again (used an wrong mailbox previously)

On 2014-2-13, at 下午9:58, Mikael Abrahamsson wrote:

> Traditionally, the eNodeB has basically done GTP-RLC (or whatever protocol is used on the radio layer) conversion. All the setup has been done using 3GPP protocols.

[Qi] But the eNodeB still needs an IP address, which is allocated through DHCP. 

> This document proposes to use DHCPv6oDHCPv4 with the eNodeB as a *client*.

[Qi] When the eNodeB launches, it needs to setup the default bearer to get configuration. In this process, DHCPv6 is used for IPv6 configuration. So we are thinking if DHCPv4oDHCPv6 could be used to configure the eNodeB with an IPv4 address over the IPv6 network.

> When I read the document, I don't understand what communication is done within the GTP tunnel,

[Qi] Typically, it's the IPv4-GTP-IPv6 encapsulation and just data forwarding within the GTP tunnel. 

> what is done outside the tunnel,

[Qi] We think it could be the private-public IPv4 address translation (including source port mapping on the eNodeB), and the mapping lookup on the PGW when there are packets back to the UE from the IPv4 Internet.

> and what role the eNodeB has in this.

[Qi] The eNodeB could play the role of the "gateway" for the UEs, i.e. allocating private IPv4 addresses to the UEs and do the private-public IPv4 translation within a restricted port range. 

> I don't understand this statement. It's completely possible to set up an GTP tunnel over IPv6, which then can carry both IPv4 and IPv6 traffic. So it's not problem to support UEs with IPv4, IPv6 or DS uplinks, in current 3GPP architecture, over a pure IPv6 mobile backhaul network.
> 

[Qi] The proposal is trying to use tunneling mechanism (lw4over6) to help LTE networks and users to transition to pure IPv6. We intend to make use of the GTP tunnel for encapsulation and avoid modifications on the UEs. In addition, the PGW can avoid large scale NAT at the cost of assign shared public IPv4 addresses to the eNodeBs. 
The difference to the usage of xlat464 in LTE would be: no changes to UEs, and no large scale NAT (translation) on the PGW.

Maybe we are not depict the purpose precisely. Please feel free to comment. Thanks again.

Best Regards,
Qi

Dear ,

Best Regards,
Qi Sun

---

From: Qi Sun <[email-masked]>
Date: Fri, 14 Feb 2014 10:10:44 +0800

Hi,

Thanks for comments!

We are just trying to just add some existing functions (that are defined in the IETF) to LTE nodes. Would that be OK to discuss it in the IETF?

Best Regards,
Qi

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Feb 2014 08:21:46 +0100 (CET)

On Fri, 14 Feb 2014, Qi Sun wrote:

> [Qi] The eNodeB could play the role of the "gateway" for the UEs, i.e. 
> allocating private IPv4 addresses to the UEs and do the private-public 
> IPv4 translation within a restricted port range.

This is a fundamental change of the role of the eNodeB. You can't make 
that change in the IETF, you need to go to 3GPP to do this.

I imagine this has huge implications to how the control plane is handled, 
because now the eNodeB needs to intercept control plane messages to/from 
the UE to fake the bearer type of the GTP tunnel etc. Also, when doing 
handover, this information needs to follow.

So while I am all for changing how LTE works to have things more 
distributed, I don't see how this way would work in the manner described.

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 14 Feb 2014 09:51:32 +0100

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, February 13, 2014 2:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6
> 
> 
> http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6.
> Please take a look at it and comment.

IETF V6OPS is not the right place for such an architectural change. 
A problem statement may fit to start the discussion, but 3GPP SA1/SA2 
is the place to get this kind of change done.

Ales

---

From: Qi Sun <[email-masked]>
Date: Fri, 14 Feb 2014 10:00:50 +0800

Hi Mikael,

Best Regards,
Qi

---

From: Qi Sun <[email-masked]>
Date: Fri, 14 Feb 2014 10:03:24 +0800

Hi,

Thanks for comments!

Best Regards,
Qi