Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-3gpp-eps-03.txt> (IPv6 in 3GPP Evolved Packet System) to Informational RFC

From: GangChen <[email-masked]>
Date: Fri, 5 Aug 2011 10:55:46 +0800

Hello Authors,

I think it is worth adding some texts to describe mobile CPE case, in
which CPEs with wireless modem use 3GPP access as uplink.

Gang

2011/8/2, The IESG <[email-masked]>:
>
> The IESG has received a request from the IPv6 Operations WG (v6ops) to
> consider the following document:
> - 'IPv6 in 3GPP Evolved Packet System'
>   <draft-ietf-v6ops-3gpp-eps-03.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-08-15. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    Use of data services in smart phones and broadband services via HSPA
>    and HSPA+, in particular Internet services, has increased rapidly and
>    operators that have deployed networks based on 3GPP network
>    architectures are facing IPv4 address shortages at the Internet
>    registries and are feeling a pressure to migrate to IPv6.  This
>    document describes the support for IPv6 in 3GPP network
>    architectures.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Jouni <[email-masked]>
Date: Fri, 5 Aug 2011 09:55:30 +0300

Dear Gang,

I would be inclined to say that within the 3GPP scope the client is always the "UE" and its form factor or the end usage scenario does not really matter. It does not change the way the UE is expected to behave from the 3GPP system point of view, unless there is a new functional requirement from 3GPP.

- Jouni

On Aug 5, 2011, at 5:55 AM, GangChen wrote:

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

---

From: Jouni <[email-masked]>
Date: Fri, 5 Aug 2011 10:15:59 +0300

I got one comment to our draft. Section 5.4 discusses some known neighbor discovery issues out there. I forgot to add one that I believe belongs here or then in Section 5.2; which one I am not sure yet. In Section 5.2 it is said that the GGSN/PGW provides an unique IID to the UE (i.e. guaranteed not to collide with GGSN/PGW's one) for the link-local address configuration. However, numerous modem drivers today fail (or don't even care) to deliver the received IID to the host OS stack and instead the driver comes up with its own (usually some imaginary MAC address based one..). Therefore, there is theoretical but very unlikely chance for link-local address collision between the UE and the gateway on the 3GPP link. Since the UE may or may not perform DAD this can be unnoticed during the address configuration phase.

- Jouni

---

From: GangChen <[email-masked]>
Date: Wed, 10 Aug 2011 00:14:25 +0800

Dear Jouni,

In mobile CPE case, MT and TE are separated. That would need
additional requirements in some particular cases, e.g. dynamic IPv6
address allocation.

According to the 3GPP specification, the UE shall build the link-local
address using the interface identifier provided by the PDN GW upon PDN
connection establishment. However, MT may not be able to transfer the
interface identifier to TE in the CPE cases. The only thing the IP
devices can do is to select the interface identifier by some other
means and then perform Duplicate Address Detection, as specified in
RFC 4862. The PDN GW shall then perform the DAD check based on the
Neighbor Solicitation messages sent by the UE.

Therefore, there are some implementation factors that may change UE
behaviour in the CPE context. IMHO, it would be beneficial to describe
CPE consideration in section 5.3. CPE case has already appeared to be
a valid scenario in 3GPP

BRs

Gang

2011/8/5, Jouni <[email-masked]>:
> Dear Gang,
>
> I would be inclined to say that within the 3GPP scope the client is always
> the "UE" and its form factor or the end usage scenario does not really
> matter. It does not change the way the UE is expected to behave from the
> 3GPP system point of view, unless there is a new functional requirement from
> 3GPP.
>
> - Jouni
>
>
>

---

From: jouni korhonen <[email-masked]>
Date: Tue, 9 Aug 2011 21:49:21 +0300

Dear Gang,

> additional requirements in some particular cases, e.g. dynamic IPv6

Separate MT & TE is part of the existing 3GPP specifications. There is nothing CPE specific in that.

> interface identifier to TE in the CPE cases. The only thing the IP

See my earlier mail: http://www.ietf.org/mail-archive/web/v6ops/current/msg10213.html
This is again not specific to a CPE case but rather a driver framework brokenness issue.

> Neighbor Solicitation messages sent by the UE.

A GGSN/PPGW is already supposed to perform a DAD check. Referring to 3GPP TS29.061 Section 11.2.1.3.4, which says:
"For IPv6 Address Autoconfiguration to work properly, network entities which act as an access router towards the MS/UE, i.e. PDN GW, Serving GW, and ePDG, shall be consistent with the RFCs specifying this process (for example RFC 4862 [83] and RFC 4861 [89]), unless stated otherwise in this or other 3GPP specifications."

And there is no text in specs that would state using "shall" that the PGW/GGSN/SGW must not perform DAD check or not to answer to an NS.. on a contrary (see text in Section 11.2.3.2 & 11.2.3.2a.. not that the text is the best regarding handling an NS but still).

> CPE consideration in section 5.3. CPE case has already appeared to be

I still cannot see any CPE specific considerations here. I witness same thing almost daily with my 3G dongle, which was the reason for http://www.ietf.org/mail-archive/web/v6ops/current/msg10213.html.

- Jouni