Last Call Review of draft-ietf-v6ops-64share-09

Request Review of draft-ietf-v6ops-64share
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-02-21
Requested 2014-02-08
Authors Cameron Byrne, Dan Drown, Vizdal Ales
Draft last updated 2014-02-21
Completed reviews Genart Last Call review of -09 by Ben Campbell (diff)
Secdir Last Call review of -09 by Yaron Sheffer (diff)
Opsdir Last Call review of -09 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh 
State Completed Snapshot
Review review-ietf-v6ops-64share-09-opsdir-lc-kuarsingh-2014-02-21
Reviewed rev. 09 (document currently at 10)
Review result Has Nits
Review completed: 2014-02-21


OPS-DIR, Authors, Chairs and IESG,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

Overview:  I reviewed “draft-ietf-v6ops-64share-09” as part of the Ops Area Directorate in accordance with RFC5706.

Summary: This document describes the requirements to share a /64 IPv6 assigned from a 3GPP radio interface (UE) to the LAN.  The document covers the requirements for two use cases which are full described with in the document.

The document explains the drivers for this solution which are related to pre-3GPP Release-10 support for DHCPv6 (therefore the UE is unable to receive a prefix assignment from the network and therefore must rely on the pre-3GPP Release 10 IPv6 functionality.

[General Feedback]  The document covers a valid real world use case, and outlines a viable solution to overcome the gap in IPv6 functionality.

The document is well written and fully articulates the needed requirements to enable the intended solution.

[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

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.


Victor Kuarsingh