Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
draft-ietf-v6ops-64share-10
Yes
(Joel Jaeggli)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Jari Arkko)
(Richard Barnes)
(Spencer Dawkins)
No Record
Note: This ballot was opened for revision 09 and is now closed.
Yes
(for -09)
Unknown
Yes
(2014-04-01)
Unknown
The new version of the draft addresses my DISCUSS, so I'm clearing. Thanks for the update! Former DISCUSS: This relates to Benoit's comment. I think the reason Benoit is confused is that this document doesn't clearly specify its scope, and if I am correct this should be easy to fix. As it is currently written, the document can be read in two different ways. The first way, which I _think_ is what is intended, is that the 3GPP node sets up a Wifi LAN of its own, with its own SSID, and manages that link as the sole router. The second way it can be read is that the 3GPP node joins an existing WiFi LAN and starts advertising a prefix on it. Both scenarios are useful, but the second one is harder to specify, and the current document is inadequate to the task, as Benoit has observed. But if I am right that the first scenario is the only one that this document intends to support, I think the document is fine as is. So the easy way to address this DISCUSS is to add a scoping statement in the introduction: OLD: 3GPP mobile cellular networks such as GSM, UMTS, and LTE have architectural support for IPv6 [RFC6459] , but only 3GPP Release-10 and onwards of the 3GPP specification supports DHCPv6 Prefix Delegation [RFC3633] for delegating IPv6 prefixes to a single LAN link. To facilitate the use of IPv6 in a LAN prior to the deployment of DHCPv6 Prefix Delegation in 3GPP networks and in User Equipment (UE), this document describes requirements and provides examples on how the 3GPP UE radio interface assigned global /64 prefix may be extended from the 3GPP radio interface to a LAN link. NEW: 3GPP mobile cellular networks such as GSM, UMTS, and LTE have architectural support for IPv6 [RFC6459] , but only 3GPP Release-10 and onwards of the 3GPP specification supports DHCPv6 Prefix Delegation [RFC3633] for delegating IPv6 prefixes to a single LAN link. To facilitate the use of IPv6 in a LAN prior to the deployment of DHCPv6 Prefix Delegation in 3GPP networks and in User Equipment (UE), this document describes requirements and provides examples on how the 3GPP UE radio interface assigned global /64 prefix may be extended from the 3GPP radio interface to a LAN link. There are two scenarios where this might be done. The first is where the 3GPP node sets up and manages its own LAN (e.g., an IEEE 802.11 SSID) and provides single-homed service to hosts that connect to this LAN. A second scenario is where the 3GPP node connects to an existing LAN and acts as a router in order to provide redundant or multi-homed IPv6 service. This document is intended to address the first scenario, and is not applicable to the second scenario, because the operational complexities of the second scenario are not addressed. Or something like that. Anyway, assuming that I'm correct in understanding where this document is intended to be used, I think a quick update will resolve this DISCUSS. If the document is intended to cover the second scenario, it's not ready for publication and will require substantial additional work, for the reasons Benoit has already stated.
No Objection
(for -09)
Unknown
No Objection
(for -09)
Unknown
No Objection
(2014-03-24 for -09)
Unknown
I am curious as to whether there was any discussion on how the UE may use RFC 4291 addresses out of the /64. Is there any expectations that UE vendors would want to do such a thing? If so, is it worth documenting that as a third example?
No Objection
(for -09)
Unknown
No Objection
(2014-03-26 for -09)
Unknown
I support Stephen's position
No Objection
(2014-03-26 for -09)
Unknown
A question for the shepherd. In the writeup, you say: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The draft is intended to be at, and requests, Informational status. Which of course doesn't answer the second question. This looks like protocol to me. Or maybe at least BCPish stuff. The fact that it's Informational probably means that it didn't get a lot of cross area review. (Heck, in the IESG, we don't even require more than the responsible AD to read Informational documents for them to pass.) So could you explain why this was sent up as Informational?
No Objection
(for -09)
Unknown
No Objection
(for -09)
Unknown
No Objection
(2014-03-24 for -09)
Unknown
- section 3, R-2: "MUST be tightly coupled" isn't clear to me. Would it be clear to implementers? - 4.1: does gateway here always only mean GGSN from 6459? 6459 mentions other gateways so I'm not sure. Nor am I sure if it matters, but no harm saying, if you can. - The secdir review [1] suggests making 6092 a SHOULD implement and calling out the potential privacy issue of sharing addresses as described. Those seem like good changes to make to me, and the authors seem happy to incorporate them so I'd hope a revision with those is planned. Is it? [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04627.html
No Record
(2014-03-27 for -09)
Unknown
- Note sure if this is a real problem or not I would like to speak with Joel and/or Ted. Maybe I overlooked something? draft-ietf-v6ops-64share-09 is only about LAN, and not wireless LAN, right? or LAN is used generically? I guess that with wireless LAN, the hosts might end up with MIF problems (RFC 6418). What if I introduce an UE 3GPP in my home, and this UE does wireless by default. Let's pretend that there is no authentication, and that the signal is stronger than my home WIFI, and that my hosts connect automatically to the UE's preferred signal, shall I now send all my traffic via 3GPP (and pay a lot)? Granted: a lot of IF in that statement, but could this mechanism be used to automatically attract all traffic to 3GPP? I'd like to remain in control of where my traffic goes. Background info, from the MIF charter: 6. The MIF working group will document either as part of the MIF API specification, as part of the MIF architecture document, or in a separate document, the issues and requirements for a high-level MIF user interface that would allow the user to exert control over how individual applications or application roles make use of different provisioning domains and network interfaces. Was it discussed in the WG? Or it's not different that IPv4 or - I like this formulation, which could be reused in the different documents. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. This document uses the normative keywords only for precision. Thanks. - Below is Victor's OPS DIR review. I don't think I've seen a reply to this. [OPS-DIR Suggestion] One of the key criteria in RFC5706 is to deal with co-existence. Therefore the document authors may want to add some addition text which discusses the UE (with code enabling this solution) behaviour if a Release-10 compliant gateway is present and an IPv6 prefix is supplied. In such a case, the initialization behaviours should include a check if a prefix (i.e. >64 like a /56) is received. Should that occur, the /64 share is not needed. This would cover the co-existence case where a UE may connect to multiple 3GPP networks (or a single one) where some gateways have Release10 functionality and some don’t. Additionally, perhaps a reference to the appropriate 3GPP document which outlines the UE IP attachment procedures can be made. This may help implements understood the full upstream network characteristics and UE detailed behaviour. Suggestion is reference to 3GPP Specification 29.061 (Section 11.2.1.3.2). Other then these two minor points, the document appears to be of quality meets the OPS-DIR requirements. [RFC5706 - Appendix A] [A.3] Operations Impact Feedback: The operational impact of enabling this function can cause broken IPv6 connectivity. The document addresses this issue by stating that there must be tight coupling of 3GPP radio internet state with the IPv6 enabled LAN (on the same UE). The enablement of the functions laid out in this document is consider beneficial to IPv6 deployment, and has a beneficial impact to cellular networks. [A.1] Operational Considerations Operational considerations are discussed and covered in detail within the document. Coexistence and backward compatibility is disused, and one recommendation was made to help improve the text in this regard. Fault condition are discussed and corresponding behaviour outlined. (i.e. tracking of RADIO interface). [A.2] Management Considerations Management of the UE is not inherently discussed, but that would be covered in normal 3GPP procedures. Configuration management is not discussed, but is also not relent and the procedures and conditions outline are dynamic in nature based on information received from the network.