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@xxxxxxxxx>: >> 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@xxxxxxxx>: >>>> >>>> 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@xxxxxxxx mailing lists by 2011-08-15. Exceptionally, comments may be >>>> sent to iesg@xxxxxxxx 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@xxxxxxxx >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/ietf >> >> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf