Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
draft-ietf-v6ops-64share-10

Note: This ballot was opened for revision 09 and is now closed.

(Joel Jaeggli) Yes

(Ted Lemon) (was Discuss) Yes

Comment (2014-04-01)
No email
send info
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.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-03-24 for -09)
No email
send info

- 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

(Brian Haberman) No Objection

Comment (2014-03-24 for -09)
No email
send info
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?

(Kathleen Moriarty) No Objection

Comment (2014-03-26 for -09)
No email
send info
I support Stephen's position

(Pete Resnick) No Objection

Comment (2014-03-26 for -09)
No email
send info
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?

(Benoît Claise) No Record

Comment (2014-03-27 for -09)
No email
send info
- 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.