IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)
draft-ietf-v6ops-3gpp-eps-08

[Ballot discuss]
This is a great document, thank you for writing it. I will vote Yes as soon as the following issues are clarified:

The document says:

  However, there
  are network drivers that fail to pass the Interface Identifier to the
  stack and instead synthesize their own Interface Identifier (usually
  a MAC address equivalent).  If the UE skips the Duplicate Address
  Detection (DAD) or has other issues with the Neighbor Discovery
  Protocol (see Section 5.4), then there is a small theoretical chance
  that the UE configures exactly the same link-local address as the
  GGSN/PDN-GW.  The address collision may then cause issues in the IP
  connectivity.

This is true, except that I am not sure about the part that issues in IP connectivity may arise. The global prefix is not used by the GGSN at all (this is guaranteed in the specs), so the only issue could be in the use of link local addresses.

What kind of problems have you seen with this? Since there are no services with a GGSN, its hard to see what actual traffic might be impacted. Local use of link locals with other devices on the same connection could be impacted, of course, you would think that the terminal would use a different address if it was unable to allocate a link local address. Or if it did not get a problem in allocating such an address, the communication would be local and the collision would be undetected. Please expand on what the failure mode is here.

  Currently several operating systems and their network drivers can
  make the 3GPP PDP Context to appear as an IEEE802 interface/link to
  the IP stack.  This has few known issues, especially when the IP
  stack is made to believe the underlying link has link-layer
  addresses.  First, the Neighbor Advertisement sent by a GGSN as a
  response to an address resolution triggered Neighbor Solicitation may
  not contain a Target Link-Layer address option (as suggested in
  [RFC4861] Section 4.4).  Then it is possible that the address
  resolution never completes when the UE tries to resolve the link-
  layer address of the GGSN, thus stalling all IPv6 traffic.

  Second, the GGSN may simply discard all address resolution triggered
  Neighbor Solicitation messages (as hinted in [RFC3316] Section 2.4.1
  that address resolution and next-hop determination are not needed).
  As a result the address resolution never completes when the UE tries
  to resolve the link-layer address of the GGSN, thus stalling all IPv6
  traffic.

I don't think there is anything that we can really do on the GGSN side about this. Since there are no link layer addresses, it would be bad to insert them in the messages. It seems that the reasonable implementation approach would be to have the layer that simulates a 802 network fake the necessary addresses and address resolution messages. If you agree, can you say so? Currently it seems that you may be saying RFC 3316 should be changed. If you mean that instead, please say so clearly.

[Ballot comment]
I have no objection to the publication of this document.

---

I find myself in agreement with Stephen. the document reads well, but
having gone to the trouble to write this guide, I think you could have
taken it one step further and described the security issues as well
(not that I have a clue what they are, but that is why I would find the
description helpful).

---

Section 1
OLD
  There are many
  factors that can be attributed to the lack of IPv6 deployment in 3GPP
  networks.
NEW
  The lack of IPv6 deployment in 3GPP networks can be attributed to
  many factors.

[Ballot comment]
- While I agree that this document doesn't *introduce* any security
related concerns, neither does it tell the reader about any, which
is a real pity.  Are the authors saying that there are no security
(or privacy) concerns about 3GPP's use of IPv6, nor any new issues
that need(ed) addressing? That seems unlikely. Or, are the authors
saying that no-one deploys any security for IPv6 in 3GPP - which
would be perhaps more believable but even more unfortunate.  In
either case, I'd have expected more than one sentence.

Other than the above, I quite liked this, (at least... more than any
3GPP thing I've read before:-) and think it could be very useful.

- SGSN and GGSN are used in the intro before the terminology
section, an English phrase for what they do might be better there,
e.g. "various gateways" might do it.

- 2.2: many APNs have various IPv4 addresses and username/pwd
pairs that are publicly known.  I don't know if there's any IPv6
information associated with publicly known APNs (or that ought
to be) but if there were that might be of interest. I thought I
might see something about that in 8.4 as well but didn't, or at
least I didn't get it, if its there.

typo spotting:
- HSS definition: s/got introduced/was introduced/
- 8.3: s/in order the roaming/in order for the roaming/

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv6 in 3GPP Evolved Packet System) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 in 3GPP Evolved Packet System'
  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@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be
sent to iesg@ietf.org 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.

Document Shepherd Writeup for draft-ietf-v6ops-3gpp-eps-01

Prepared 6/15/2011

1.a

Joel Jaeggli, v6ops co-chair is the document shepherd for draft-ietf-v6ops-3gpp-eps-01

1.b

The document has been extensively reviewed. Because the draft documents the usage of IETF technologies in the 3GGP evolved packet system, contribution from parties involved in both IETF and 3GGP processes was required. Cameron Byrne a domain expert not affiliated with the authors performed a review on the final version of the draft.

1.c

The document shepherd has no concerns that additional review is required. The external standards being informatively referenced are stable so to the extent that ambiguity existed in interpretation the authors and the working group are satisfied that the documentary effort is sufficiently complete.

1.d

The document shepherd has no substantive concerns with the current draft.

1.e

Working group consensus was solidly in favor of acceptance as a working group document and shortly thereafter in last calling the document, the document spent about of time in v6ops prior to acceptance as a WG document.

1.f

No appeals are expected.

1.g

Idnits throws two comments, one regarding the definition of the term GGSN which is defined in section 2.1 terminology the other related to an up-to-date informative reference. the only warning is related to the submission date being greate than 45 days in the past. There are no errors.

1.h

All references are informative.

1.i

IANA considerations section is present, no requests to IANA will be made as a result of this draft.

1.j

No formal language is present in the document.


1.k

Technical Summary

The increased use of data services, growth of subscribers in 3GPP
based mobile networks, and the impending exhaustion of available IPv4
addresses from the registries is driving the need to specify the
transition to IPv6 solutions in 3GPP network architectures. This
document describes the support for IPv6 in 3GPP network architectures
and a solution to transition to IPv6 using a dual-stack approach.

Working Group summary

WG Acceptance was requested and then validated through survey during and after IETF 80. Last Call was initiated on May 15 2011 and completed May 29th 2011.

Document quality

The document contributions represent an effort to inform implementors and users of the 3GPP platforms of 3GPP utilization of IETF standards in a fashion that is operationally relevant and validates the contribution of that IETF input into the Evolved Packet System. The upshot should be a better understanding of 3GPP EPS without the necessity or overhead of participating in an additional standards body.