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

Dear Gang,

On Aug 9, 2011, at 7:14 PM, GangChen wrote:

> 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.

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

> 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

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.

> 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.

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).

> 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

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

> 
> BRs
> 
> Gang
> 
> 2011/8/5, Jouni <jounikor@gmail.com>:
>> 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:
>> 
>>> 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 <iesg-secretary@ietf.org>:
>>>> 
>>>> 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
>>>> ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be
>>>> sent to iesg@ietf.org 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
>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
>> 