Skip to main content

Last Call Review of draft-ietf-v6ops-64share-09
review-ietf-v6ops-64share-09-opsdir-lc-kuarsingh-2014-02-21-00

Request Review of draft-ietf-v6ops-64share
Requested revision 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
I-D 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
Request Last Call review on draft-ietf-v6ops-64share by Ops Directorate Assigned
Reviewed revision 09 (document currently at 10)
Result Has nits
Completed 2014-02-21
review-ietf-v6ops-64share-09-opsdir-lc-kuarsingh-2014-02-21-00

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

regards,

Victor Kuarsingh