draft-ietf-v6ops-rfc3316bis-02.txt   draft-ietf-v6ops-rfc3316bis-03.txt 
IPv6 Operations (V6OPS) J. Korhonen, Ed. IPv6 Operations (V6OPS) J. Korhonen, Ed.
Internet-Draft Renesas Mobile Internet-Draft Renesas Mobile
Obsoletes: 3316 (if approved) J. Arkko, Ed. Obsoletes: 3316 (if approved) J. Arkko, Ed.
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: November 7, 2013 T. Savolainen Expires: November 28, 2013 T. Savolainen
Nokia Nokia
S. Krishnan S. Krishnan
Ericsson Ericsson
May 6, 2013 May 27, 2013
IPv6 for 3GPP Cellular Hosts IPv6 for 3GPP Cellular Hosts
draft-ietf-v6ops-rfc3316bis-02.txt draft-ietf-v6ops-rfc3316bis-03.txt
Abstract Abstract
As the deployment of third and fourth generation cellular networks As the deployment of third and fourth generation cellular networks
progresses, a large number of cellular hosts are being connected to progresses, a large number of cellular hosts are being connected to
the Internet. Standardization organizations are making Internet the Internet. Standardization organizations have made Internet
Protocol version 6 (IPv6) mandatory in their specifications. Protocol version 6 (IPv6) mandatory in their specifications.
However, the concept of IPv6 covers many aspects and numerous However, the concept of IPv6 covers many aspects and numerous
specifications. In addition, the characteristics of cellular links specifications. In addition, the characteristics of cellular links
in terms of bandwidth, cost and delay put special requirements on how in terms of bandwidth, cost and delay put special requirements on how
IPv6 is used. This document considers IPv6 for cellular hosts that IPv6 is used. This document considers IPv6 for cellular hosts that
attach to the General Packet Radio Service (GPRS), Universal Mobile attach to the General Packet Radio Service (GPRS), Universal Mobile
Telecommunications System (UMTS), or Evolved Packet System (EPS) Telecommunications System (UMTS), or Evolved Packet System (EPS)
networks (Hereafter collectively referred to as 3GPP networks). This networks (Hereafter collectively referred to as 3GPP networks). This
document also lists out specific IPv6 functionality that needs to be document also lists out specific IPv6 functionalities that need to be
implemented in addition what is already prescribed in the IPv6 Node implemented in addition what is already prescribed in the IPv6 Node
Requirements document. It also discusses some issues relating to the Requirements document. It also discusses some issues related to the
use of these components when operating in these networks. This use of these components when operating in these networks. This
document obsoletes RFC 3316. document obsoletes RFC 3316.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 7, 2013. This Internet-Draft will expire on November 28, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Cellular Host IPv6 Features . . . . . . . . . . . . . . . 6 1.3. Cellular Host IPv6 Features . . . . . . . . . . . . . . . 6
2. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Internet Protocol Version 6 . . . . . . . . . . . . . . . 7 2.1. Internet Protocol Version 6 . . . . . . . . . . . . . . . 7
2.2. Neighbor Discovery in 3GPP Networks . . . . . . . . . . . 7 2.2. Neighbor Discovery in 3GPP Networks . . . . . . . . . . . 7
2.3. IPv6 Stateless Address Autoconfiguration . . . . . . . . . 8 2.3. Stateless Address Autoconfiguration . . . . . . . . . . . 8
2.4. Stateless Address Autoconfiguration in 3GPP Networks . . . 8 2.4. IP version 6 over PPP . . . . . . . . . . . . . . . . . . 9
2.5. IP version 6 over PPP in 3GPP Networks . . . . . . . . . . 9 2.5. Multicast Listener Discovery (MLD) for IPv6 . . . . . . . 10
2.6. MLD in 3GPP Networks . . . . . . . . . . . . . . . . . . . 9 2.6. Privacy Extensions for Address Configuration in IPv6 . . . 10
2.7. Privacy Extensions for Address Configuration in IPv6 . . . 10 2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . . 10
2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . . 10 2.8. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10
2.9. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10 2.9. Router preferences and more specific routes . . . . . . . 11
2.10. Router preferences and more specific routes . . . . . . . 10 2.10. Neighbor Discovery and additional host configuration . . . 11
2.11. Neighbor Discovery and additional host configuration . . . 11
3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Extension header considerations . . . . . . . . . . . . . 11 3.1. Extension header considerations . . . . . . . . . . . . . 11
4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative references . . . . . . . . . . . . . . . . . . . 14 8.1. Normative references . . . . . . . . . . . . . . . . . . . 14
8.2. Informative references . . . . . . . . . . . . . . . . . . 15 8.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 16 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 16
Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 17 Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 17
B.1. Version draft-ietf-v6ops-rfc3316bis-02 . . . . . . . . . . 17 B.1. Version draft-ietf-v6ops-rfc3316bis-03 . . . . . . . . . . 17
B.2. Version draft-ietf-v6ops-rfc3316bis-01 . . . . . . . . . . 17 B.2. Version draft-ietf-v6ops-rfc3316bis-02 . . . . . . . . . . 18
B.3. Version draft-ietf-v6ops-rfc3316bis-00 . . . . . . . . . . 17 B.3. Version draft-ietf-v6ops-rfc3316bis-01 . . . . . . . . . . 18
B.4. Version draft-ietf-v6ops-rfc3316bis-00 . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Technologies such as GPRS (General Packet Radio Service), UMTS Technologies such as GPRS (General Packet Radio Service), UMTS
(Universal Mobile Telecommunications System), Evolved Packet System (Universal Mobile Telecommunications System), Evolved Packet System
(EPS), CDMA2000 (Code Division Multiple Access 2000) and eHRPD (EPS), CDMA2000 (Code Division Multiple Access 2000) and eHRPD
(Enhanced High Rate Packet Data) are making it possible for cellular (Enhanced High Rate Packet Data) are making it possible for cellular
hosts to have an always-on connection to the Internet. IPv6 hosts to have an always-on connection to the Internet. IPv6
[RFC2460] has become essential to such networks as the number of such [RFC2460] has become essential to such networks as the number of
cellular hosts is increasing rapidly. Standardization organizations cellular hosts is increasing rapidly. Standardization organizations
working with cellular technologies have recognized this and made IPv6 working with cellular technologies have recognized this and made IPv6
mandatory in their specifications. mandatory in their specifications.
Support for IPv6 and the introduction of UMTS started with 3GPP Support for IPv6 and the introduction of UMTS started with 3GPP
Release-99 networks and hosts. For detailed description of IPv6 in Release-99 networks and hosts. For the detailed description of IPv6
3GPP networks including the Evolved Packet System, see [RFC6459]. in 3GPP networks including the Evolved Packet System, see [RFC6459].
1.1. Scope of this Document 1.1. Scope of this Document
For the purposes of this document, a cellular interface is considered For the purpose of this document, a cellular interface is considered
to be the interface to a cellular access network based on the to be the interface to a cellular access network based on the
following standards: 3GPP GPRS and UMTS Release-99, Release-4 to following standards: 3GPP GPRS and UMTS Release-99, Release-4 to
Release-11, and EPS Release-8 to Release-11 as well as future UMTS or Release-11, and EPS Release-8 to Release-11 as well as future UMTS or
EPS releases. A cellular host is considered to be a host with such a EPS releases. A cellular host is considered to be a host with such a
cellular interface. cellular interface.
This document complements the IPv6 node requirements [RFC6434] in This document complements the IPv6 node requirements [RFC6434] in
places where clarifications are needed with discussion on the use of places where clarifications are needed the with discussion on the use
these selected IPv6 specifications when operating over cellular of these selected IPv6 specifications when operating over a cellular
interfaces. Such a specification is necessary in order for the interface. Such a specification is necessary in order to enable the
optimal use of IPv6 in a cellular environment. The description is optimal use of IPv6 in a cellular network environment. The
made from a cellular host point of view. Complementary access description is made from a cellular host point of view.
technologies may be available in the cellular host, but those are not Complementary access technologies may be supported by the cellular
discussed in detail. Important considerations are given in order to host, but those are not discussed in detail. Important
eliminate unnecessary user confusion over configuration options, considerations are given in order to eliminate unnecessary user
ensure interoperability and to provide an easy reference for those confusion over configuration options, ensure interoperability and to
implementing IPv6 in a cellular host. It is necessary to ensure that provide an easy reference for those who are implementing IPv6 in a
cellular hosts are good citizens of the Internet. cellular host. It is necessary to ensure that cellular hosts are
good citizens of the Internet.
This document is informational in nature, and it is not intended to This document is informational in its nature, and it is not intended
replace, update, or contradict any IPv6 standards documents or the to replace, update, or contradict any IPv6 standards documents or the
IPv6 node requirements [RFC6434]. IPv6 node requirements [RFC6434].
This document is mainly targeted towards the implementers of cellular This document is primarily targeted to the implementers of cellular
hosts that will be used with the cellular networks listed in the hosts that will be used with the cellular networks listed in the
scope. The document provides guidance on which IPv6 related scope. The document provides guidance on which IPv6 related
specifications are to be implemented in such cellular hosts. Parts specifications are to be implemented in such cellular hosts. Parts
of this document may also apply to other cellular link types, but of this document may also apply to other cellular link types, but
this document does not provide any detailed analysis on other link this document does not provide any detailed analysis on other link
types. This document should not be used as a definitive list of IPv6 types. This document should not be used as a definitive list of IPv6
functionality for cellular links other than those listed above. functionalies for cellular links other than those listed above.
Future changes in 3GPP networks that impact host implementations may Future changes in 3GPP networks that impact host implementations may
result in updates to this document. result in updates to this document.
There are different ways to implement cellular hosts: There are different ways to implement cellular hosts:
o The host can be a "closed" device with optimized applications, o The host can be a "closed" device with optimized build-in
with no possibility to add or download applications that can have applications, with no possibility to add or download applications
IP communications. An example of such a host is a very simple that can have IP communications. An example of such a host is a
form of a mobile phone. very simple form of a mobile phone.
o The host can be an open device, e.g., a "smart phone" where it is o The host can be an open device, e.g., a "smart phone" where it is
possible to download applications to expand the functionality of possible to download applications to expand the functionality of
the device. the device.
o The cellular radio modem part can be separated from the host IP o The cellular radio modem part can be separated from the host IP
stack with an interface. On example of such host is a laptop stack with an interface. One example of such host is a laptop
computer that uses a USB cellular modem for the cellular access. computer that uses a USB cellular modem for the cellular access.
If a cellular host has additional interfaces on which IP is used, If a cellular host has additional IP capable interfaces, (such as
(such as Ethernet, WLAN, Bluetooth, etc.) then there may be Ethernet, WLAN, Bluetooth, etc.) then there may be additional
additional requirements for the device, beyond what is discussed in requirements for the device, beyond what is discussed in this
this document. Additionally, this document does not make any document. Additionally, this document does not make any
recommendations on the functionality required on laptop computers recommendations on the functionality required on laptop computers
having a cellular interface such as an embedded modem or a USB modem having a cellular interface such as an embedded modem or a USB modem
stick, other than recommending link specific behavior on the cellular stick, other than recommending link specific behavior on the cellular
link. link.
This document discusses IPv6 functionality as of the time when this This document discusses IPv6 functionality as of the time when this
document has been written. Ongoing work on IPv6 may affect what is document has been written. Ongoing work on IPv6 may affect what is
required of future hosts. required of future hosts.
Transition mechanisms used by cellular hosts are not described in Transition mechanisms used by cellular hosts are not in the scope of
this document and are left for further study. The primary transition this document and are left for further study. The primary transition
mechanism supported by 3GPP is dual-stack [RFC4213]. Dual-stack mechanism supported by the 3GPP is dual-stack [RFC4213]. Dual-stack
capable bearers were added to GPRS starting from 3GPP Release-9 and capable bearer support has been added to GPRS starting from the 3GPP
to EPS starting from Release-8 [RFC6459], whereas in earlier releases Release-9 and to EPS starting from the Release-8 [RFC6459], whereas
3GPP multiple single IP version bearers had to be used to support the earlier 3GPP releases required multiple single IP version bearers
dual stack. to support dual-stack.
1.2. Abbreviations 1.2. Abbreviations
2G Second Generation Mobile Telecommunications, such as GSM and 2G Second Generation Mobile Telecommunications, such as GSM and
GPRS technologies. GPRS technologies.
3G Third Generation Mobile Telecommunications, such as UMTS 3G Third Generation Mobile Telecommunications, such as UMTS
technology. technology.
4G Fourth Generation Mobile Telecommunications, such as LTE 4G Fourth Generation Mobile Telecommunications, such as LTE
technology. technology.
3GPP 3rd Generation Partnership Project. Throughout the document, 3GPP 3rd Generation Partnership Project. Throughout the document,
the term 3GPP (3rd Generation Partnership Project) networks the term 3GPP (3rd Generation Partnership Project) networks
refers to architectures standardized by 3GPP, in Second, Third refers to architectures standardized by 3GPP, in Second, Third
and Fourth Generation releases: 99, 4, and 5, as well as future and Fourth Generation releases: 99, 4, and 5, as well as future
releases. releases.
APN Access Point Name. The APN is a logical name referring to a APN Access Point Name. The APN is a logical name referring to a
GGSN and/or a PGW, and an external network. GGSN and/or a PGW, and an external network.
EPC Evolved Packet Core. EPC Evolved Packet Core.
skipping to change at page 6, line 37 skipping to change at page 6, line 39
SGW Serving Gateway. The user plane equivalent of an SGSN in EPS SGW Serving Gateway. The user plane equivalent of an SGSN in EPS
(and the default router for 3GPP IPv6 cellular hosts when using (and the default router for 3GPP IPv6 cellular hosts when using
PMIPv6). PMIPv6).
TE Terminal Equipment, for example, a laptop attached through a TE Terminal Equipment, for example, a laptop attached through a
3GPP handset. 3GPP handset.
UMTS Universal Mobile Telecommunications System. UMTS Universal Mobile Telecommunications System.
WLAN Wireless Local Area Network. WLAN Wireless Local Area Network.
1.3. Cellular Host IPv6 Features 1.3. Cellular Host IPv6 Features
This specification defines IPv6 features for cellular hosts in three This document lists IPv6 features for cellular hosts that are split
groups. into three groups.
Basic IP Basic IP
In this group, basic parts of IPv6 are described. In this group, a list of the basic IPv6 features essential for
cellular hosts are described.
IP Security IP Security
In this group, the IP Security parts are described. In this group, the IP Security related parts are described.
Mobility Mobility
In this group, IP layer mobility issues are described. In this group, IP layer mobility issues are described.
2. Basic IP 2. Basic IP
For most parts refer to the IPv6 Node Requirements document For most parts refer to the IPv6 Node Requirements document
[RFC6434]. [RFC6434].
2.1. Internet Protocol Version 6 2.1. Internet Protocol Version 6
The Internet Protocol Version 6 (IPv6) is specified in [RFC2460]. The Internet Protocol Version 6 (IPv6) is specified in [RFC2460].
This specification is a mandatory part of IPv6. A cellular host must This specification is a mandatory part of IPv6. A cellular host must
conform the generic IPv6 Host Requirements [RFC6434], unless conform to the generic IPv6 Host Requirements [RFC6434], unless
specifically pointed out otherwise in this document. specifically pointed out otherwise in this document.
2.2. Neighbor Discovery in 3GPP Networks 2.2. Neighbor Discovery in 3GPP Networks
A cellular host must support Neighbor Solicitation and Neighbor A cellular host must support Neighbor Solicitation and Neighbor
Advertisement messages. Some further notes on how these are applied Advertisement messages [RFC4861]. Some further notes on how these
in the particular type of an interface can be useful, however: are applied in the particular type of an interface can be useful,
however:
In GPRS, UMTS and EPS networks, some Neighbor Discovery messages can In 3GPP networks, some Neighbor Discovery messages can be unnecessary
be unnecessary in certain cases. GPRS, UMTS and EPS links resemble a in certain cases. GPRS, UMTS and EPS links resemble a point-to-point
point-to-point link; hence, the cellular host's only neighbor on the link; hence, the cellular host's only neighbor on the cellular link
cellular link is the default router that is already known through is the default router that is already known through Router Discovery.
Router Discovery. The cellular host always solicits for routers when The cellular host always solicits for routers when the cellular
the cellular interface is enabled (as described in [RFC4861], Section interface is brought up (as described in [RFC4861], Section 6.3.7).
6.3.7).
There are no link layer addresses. Therefore, address resolution and There are no link layer addresses on the 3GPP cellular link
next-hop determination are not needed. If the cellular host still technology. Therefore, address resolution and next-hop determination
attempts the address resolution e.g., for the default router, it must are not needed. If the cellular host still attempts to do the
be understood that the GGSN/PGW may not even answer the address address resolution e.g., for the default router, it must be
understood that the GGSN/PGW may not even answer the address
resolution Neighbor Solicitations. And even if it does, the Neighbor resolution Neighbor Solicitations. And even if it does, the Neighbor
Advertisement is unlikely to contain the Target link-layer address Advertisement is unlikely to contain the Target link-layer address
option as there are no link-layer addresses. option as there are no link-layer addresses on the 3GPP cellular link
technology.
The cellular host must support Neighbor Unreachability Detection The cellular host must support Neighbor Unreachability Detection
(NUD) as specified in [RFC4861]. Note that the link-layer address (NUD) as specified in [RFC4861]. Note that the link-layer address
considerations above also apply to the NUD. The NUD triggered considerations above also apply to the NUD. The NUD triggered
Neighbor Advertisement is also unlikely to contain the Target link- Neighbor Advertisement is also unlikely to contain the Target link-
layer address option as there are no link-layer addresses. The layer address option as there are no link-layer addresses. The
cellular host should also be prepared for a router (i.e., GGSN/PGW) cellular host should also be prepared for a router (i.e., GGSN/PGW)
initiated NUD. However, it is unlikely a router to host NUD should initiated NUD. However, it is unlikely a router to host NUD should
ever take place on a GPRS, UMTS and EPS links. See Appendix A for ever take place on a GPRS, UMTS and EPS links. See Appendix A for
more discussion on the router to host NUD. more discussion on the router to host NUD.
In GPRS, UMTS and EPS networks, it is very desirable to reduce any In 3GPP networks, it is desirable to reduce any additional periodic
additional periodic signaling. Therefore, the cellular host should signaling. Therefore, the cellular host should include a mechanism
include a mechanism in upper layer protocols to provide reachability in upper layer protocols to provide reachability confirmations when
confirmations when two-way IP layer reachability can be confirmed two-way IP layer reachability can be confirmed (see [RFC4861],
(see [RFC4861], Section 7.3.1). These confirmations would allow the Section 7.3.1). These confirmations would allow the suppression of
suppression of NUD-related messages in most cases. NUD-related messages in most cases.
Host TCP implementation should provide reachability confirmation in Host TCP implementation should provide reachability confirmation in
the manner explained in [RFC4861], Section 7.3.1. the manner explained in [RFC4861], Section 7.3.1.
The widespread use of UDP in 3GPP networks poses a problem for The widespread use of UDP in 3GPP networks poses a problem for
providing reachability confirmation. As UDP itself is unable to providing reachability confirmation. As UDP itself is unable to
provide such confirmation, applications running on top of UDP should provide such confirmation, applications running on top of UDP should
provide the confirmation where possible. In particular, when UDP is provide the confirmation where possible. In particular, when UDP is
used for transporting DNS, the DNS response should be used as a basis used for transporting DNS, the DNS response should be used as a basis
for reachability confirmation. Similarly, when UDP is used to for reachability confirmation. Similarly, when UDP is used to
skipping to change at page 8, line 30 skipping to change at page 8, line 37
the peer, they have also reached the neighbor. the peer, they have also reached the neighbor.
When UDP is used for transporting SIP, responses to SIP requests When UDP is used for transporting SIP, responses to SIP requests
should be used as the confirmation that packets sent to the peer are should be used as the confirmation that packets sent to the peer are
reaching it. When the cellular host is acting as the server side SIP reaching it. When the cellular host is acting as the server side SIP
node, no such confirmation is generally available. However, a host node, no such confirmation is generally available. However, a host
may interpret the receipt of a SIP ACK request as confirmation that may interpret the receipt of a SIP ACK request as confirmation that
the previously sent response to a SIP INVITE request has reached the the previously sent response to a SIP INVITE request has reached the
peer. peer.
2.3. IPv6 Stateless Address Autoconfiguration 2.3. Stateless Address Autoconfiguration
IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. IPv6 Stateless Address Autoconfiguration is defined in [RFC4862].
This specification is a mandatory part of IPv6 and also the only This specification is a mandatory part of IPv6 and also the only
mandatory method to configure an IPv6 address in a 3GPP cellular mandatory method to configure an IPv6 address in a 3GPP cellular
host. host.
2.4. Stateless Address Autoconfiguration in 3GPP Networks
A cellular host in a 3GPP network must process a Router Advertisement A cellular host in a 3GPP network must process a Router Advertisement
as stated in [RFC4862]. The Router Advertisement contains a maximum as stated in [RFC4862]. The Router Advertisement contains a maximum
of one prefix information option and the advertised prefix cannot of one prefix information option with lifetimes set to infinite (both
ever be used for on-link determination (see [RFC6459], Section 5.2). valid and preferred lifetimes). The advertised prefix cannot ever be
used for on-link determination (see [RFC6459], Section 5.2) and the
lifetime of the advertised prefix is tied to the PDP Context/PDN
Connection lifetime. Keeping the forward compatibility in mind there
is no reason for the 3GPP cellular host to have 3GPP specific
handling of the prefix information option(s) although 3GPP
specifications state that the Router Advertisement may contain a
maximum of one prefix information option and the lifetimes are set to
infinite.
Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero,
as each delegated prefix is unique within its scope when advertised as each assigned prefix is unique within its scope when advertised
using the 3GPP IPv6 Stateless Address Autoconfiguration. In using the 3GPP IPv6 Stateless Address Autoconfiguration. In
addition, the default router (GGSN/PGW) will not configure any addition, the default router (GGSN/PGW) will not configure any
addresses on its interfaces based on prefixes advertised to IPv6 addresses on its interfaces based on prefixes advertised to IPv6
cellular hosts on those interfaces. Thus, the host is not required cellular hosts on those interfaces. Thus, the host is not required
to perform Duplicate Address Detection on the cellular interface. to perform Duplicate Address Detection on the cellular interface.
Furthermore, the GGSN/PGW will provide the cellular host with an Furthermore, the GGSN/PGW will provide the cellular host with an
interface identifier that must be used for link-local address interface identifier that must be used for link-local address
configuration. The link-local address configured from this interface configuration. The link-local address configured from this interface
identifier is guaranteed not to collide with the link-local address identifier is guaranteed not to collide with the link-local address
that the GGSN/PGW uses. Thus, the cellular host is not required to that the GGSN/PGW uses. Thus, the cellular host is not required to
perform Duplicate Address Detection for the link-local address either perform Duplicate Address Detection for the link-local address on the
on the cellular interface. cellular interface.
See Appendix A for more details on 3GPP IPv6 Stateless Address See Appendix A for more details on 3GPP IPv6 Stateless Address
Autoconfiguration. Autoconfiguration.
2.5. IP version 6 over PPP in 3GPP Networks 2.4. IP version 6 over PPP
A cellular host in a 3GPP network that supports PPP, must support the A cellular host in a 3GPP network that supports PPP on the interface
IPv6CP interface identifier option. This option is needed to be able between the MT and the TE, must support the IPv6CP interface
to connect other devices to the Internet using a PPP link between the identifier option. This option is needed to be able to connect other
cellular device (MT) and other devices (TE, e.g., a laptop). The MT devices to the Internet using a PPP link between the cellular device
performs the PDP Context activation based on a request from the TE. (MT, e.g., a USB dongle) and other devices (TE, e.g., a laptop). The
This results in an interface identifier being suggested by the MT to MT performs the PDP Context activation based on a request from the
the TE, using the IPv6CP option. To avoid any duplication in link- TE. This results in an interface identifier being suggested by the
local addresses between the TE and the GGSN/PGW, the MT must always MT to the TE, using the IPv6CP option. To avoid any duplication in
reject other suggested interface identifiers by the TE. This results link-local addresses between the TE and the GGSN/PGW, the MT must
in the TE always using the interface identifier suggested by the always reject other suggested interface identifiers by the TE. This
GGSN/PGW for its link-local address. results in the TE always using the interface identifier suggested by
the GGSN/PGW for its link-local address.
The rejection of interface identifiers suggested by the TE is only The rejection of interface identifiers suggested by the TE is only
done for creation of link-local addresses, according to 3GPP done for creation of link-local addresses, according to 3GPP
specifications. The use of privacy addresses [RFC4941] for unique specifications. The use of privacy addresses [RFC4941] or similar
local IPv6 unicast addresses (ULA) [RFC4193] and global addresses is technologies for unique local IPv6 unicast addresses (ULA) [RFC4193]
not affected by the above procedure. The above procedure is only and global addresses is not affected by the above procedure.
concerned with assigning the interface identifier used for forming
link-local addresses, and does not preclude TE from using other
interface identifiers for addresses with larger scopes (i.e., ULAs
and global).
2.6. MLD in 3GPP Networks 2.5. Multicast Listener Discovery (MLD) for IPv6
Within 3GPP networks, hosts connect to their default routers (GGSN/ Within 3GPP networks, hosts connect to their default routers (GGSN/
PGW) via point-to-point links. Moreover, there are exactly two IP PGW) via point-to-point links. Moreover, there are exactly two IP
devices connected to the point-to-point link, and no attempt is made devices connected to the point-to-point link, and no attempt is made
(at the link-layer) to suppress the forwarding of multicast traffic. (at the link-layer) to suppress the forwarding of multicast traffic.
Consequently, sending MLD reports for link-local addresses in a 3GPP Consequently, sending MLD reports for link-local addresses in a 3GPP
environment may not always be necessary. environment is not necessary, although sending those cause no harm or
interoperability issues.
MLD is needed for multicast group knowledge that is not link-local. MLD is needed for multicast group knowledge that is not link-local.
2.7. Privacy Extensions for Address Configuration in IPv6 2.6. Privacy Extensions for Address Configuration in IPv6
Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
should be supported. RFC 4941, and privacy in general, is important or other similar technologies may be supported by a cellular host.
for the Internet. Cellular hosts may use the temporary addresses as Privacy in general, is important for the Internet. In 3GPP networks
described in RFC 4941. However, the use of the Privacy Extension in the lifetime of an address assignment depends on many factors such as
an environment where IPv6 addresses are short-lived may not be radio coverage, device status and user preferences. As a result also
necessary. At the time this document has been written, there is no the prefix the cellular host uses is a subject to frequent changes.
experience on how long-lived cellular network address assignments
(i.e., attachments to the network) are. The length of the address
assignments depends upon many factors such as radio coverage, device
status and user preferences. Additionally, the use of temporary
address with IPsec may lead to more frequent renegotiation for the
Security Associations.
Refer to Section 7 for a discussion of the benefits of privacy Refer to Section 7 for a discussion of the benefits of privacy
extensions in a 3GPP network. extensions in a 3GPP network.
2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
As of 3GPP Release-11 The Dynamic Host Configuration Protocol for As of 3GPP Release-11 The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address
autoconfiguration. The IPv6 stateless autoconfiguration still autoconfiguration. The IPv6 stateless autoconfiguration still
remains the only mandatory address configuration method. However, remains the only mandatory address configuration method. However,
DHCPv6 may be useful for other configuration needs on a cellular DHCPv6 may be useful for other configuration needs on a cellular
host. e.g. Stateless DHCPv6 [RFC3736] may be used to configure DNS host. e.g. Stateless DHCPv6 [RFC3736] may be used to configure DNS
and SIP server addresses, and DHCPv6 prefix delegation [RFC3633] may and SIP server addresses, and DHCPv6 prefix delegation [RFC3633] may
be used to delegate a prefix to the cellular host for use on its be used to delegate a prefix to the cellular host for use on its
downstream non-cellular links. downstream non-cellular links.
2.9. DHCPv6 Prefix Delegation 2.8. DHCPv6 Prefix Delegation
Starting from Release-10 DHCPv6 Prefix Delegation was added as an Starting from Release-10 DHCPv6 Prefix Delegation was added as an
optional feature to the 3GPP system architecture [RFC3633]. The optional feature to the 3GPP system architecture [RFC3633]. The
prefix delegation model defined for Release-10 requires that the /64 prefix delegation model defined for Release-10 requires that the /64
IPv6 prefix assigned for the cellular host on the 3GPP link must IPv6 prefix assigned to the cellular host on the 3GPP link must
aggregate with the shorter delegated IPv6 prefix. The cellular host aggregate with the shorter delegated IPv6 prefix. The cellular host
should implement the Prefix Exclude Option for DHCPv6 Prefix should implement the Prefix Exclude Option for DHCPv6 Prefix
Delegation [RFC6603] (see [RFC6459], Section 5.3 for further Delegation [RFC6603] (see [RFC6459], Section 5.3 for further
discussion). discussion).
2.10. Router preferences and more specific routes 2.9. Router preferences and more specific routes
The cellular host should implement the Default Router Preferences and The cellular host should implement the Default Router Preferences and
More-Specific Routes extension to extension to Router Advertisement More-Specific Routes extension to Router Advertisement messages
messages [RFC4191]. These options me be useful for cellular hosts [RFC4191]. These options may be useful for cellular hosts that also
that also have additional interfaces on which IPv6 is used. have additional interfaces on which IPv6 is used.
2.11. Neighbor Discovery and additional host configuration 2.10. Neighbor Discovery and additional host configuration
The DNS server configuration is learned from 3GPP link layer The DNS server configuration is learned from the 3GPP link layer
signaling. However, the cellular host should also implement the IPv6 signaling. However, the cellular host should also implement the IPv6
Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6 Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6
is still optional for cellular hosts, and learning the DNS server is still optional for cellular hosts, and learning the DNS server
addresses from the link layer signaling can be cumbersome when the MT addresses from the link layer signaling can be cumbersome when the MT
and the TE are separated using other techniques than PPP interface. and the TE are separated using other techniques than PPP interface.
The cellular host should also honor the MTU option in the Router The cellular host should also honor the MTU option in the Router
Advertisement (see [RFC4861], Section 4.6.4). 3GPP system Advertisement (see [RFC4861], Section 4.6.4). 3GPP system
architecture uses extensive tunneling in its packet core network architecture uses extensive tunneling in its packet core network
below the 3GPP link and this may lead to packet fragmentation issues. below the 3GPP link and this may lead to packet fragmentation issues.
Therefore, the GGSN/PGW may propose a MTU to the cellular host that Therefore, the GGSN/PGW may propose a MTU to the cellular host that
takes the additional tunneling overhead into account. takes the additional tunneling overhead into account.
3. IP Security 3. IP Security
IPsec [RFC4301] is a fundamental but not mandatory part of IPv6. IPsec [RFC4301] is a fundamental but not mandatory part of IPv6.
Refer IPv6 Node Requirements Section 11 of [RFC6434] for the security Refer to the IPv6 Node Requirements Section 11 of [RFC6434] for the
requirements that also apply to cellular hosts. security requirements that also apply to cellular hosts.
3.1. Extension header considerations 3.1. Extension header considerations
The support for the Routing Header Type 0 (RH0) has been deprecated The support for the Routing Header Type 0 (RH0) has been deprecated
[RFC5095]. Therefore, the cellular host should as a default setting [RFC5095]. Therefore, the cellular host should as a default setting
follow the RH0 processing described in Section 3 of RFC 5095. follow the RH0 processing described in Section 3 of RFC 5095.
IPv6 packet fragmentation has known security concerns. The cellular IPv6 packet fragmentation has known security concerns. The cellular
host must follow the handling of overlapping fragments as described host must follow the handling of overlapping fragments as described
in [RFC5722] and the cellular host must not fragment any neighbor in [RFC5722] and the cellular host must not fragment any neighbor
skipping to change at page 12, line 31 skipping to change at page 12, line 34
Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark,
Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing
list for their comments and input. list for their comments and input.
We would also like to thank David DeCamp, Karim El Malki, Markus We would also like to thank David DeCamp, Karim El Malki, Markus
Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and
Shabnam Sultana for their comments and input in preparation of this Shabnam Sultana for their comments and input in preparation of this
document. document.
For the revised version of the RFC 3316 the authors would like thank For the revised version of the RFC 3316 the authors would like thank
Dave Thaler for his comments and input. Dave Thaler, Ales Vizdal, Gang Chen, Ray Hunter and Owen DeLong for
their comments, reviews and inputs.
7. Security Considerations 7. Security Considerations
This document does not specify any new protocols or functionality, This document does not specify any new protocols or functionalities,
and as such, it does not introduce any new security vulnerabilities. and as such, it does not introduce any new security vulnerabilities.
However, specific profiles of IPv6 functionality are proposed for However, specific profiles of IPv6 functionality are proposed for
different situations, and vulnerabilities may open or close depending different situations, and vulnerabilities may open or close depending
on which functionality is included and what is not. There are also on which functionality is included and what is not. There are also
aspects of the cellular environment that make certain types of aspects of the cellular environment that make certain types of
vulnerabilities more severe. The following issues are discussed: vulnerabilities more severe. The following issues are discussed:
o The suggested limitations (Section 3.1) in the processing of o The suggested limitations (Section 3.1) in the processing of
extension headers limits also exposure to Denial-of-Service (DoS) extension headers limits also exposure to Denial-of-Service (DoS)
attacks through cellular hosts. attacks through cellular hosts.
o IPv6 addressing privacy [RFC4941] may be used in cellular hosts. o IPv6 addressing privacy [RFC4941] or similar technology may be
However, it should be noted that in the 3GPP model, the network used in cellular hosts. However, it should be noted that in the
would assign new addresses, in most cases, to hosts in roaming 3GPP model, the network would assign a new prefix, in most cases,
situations and typically, also when the cellular hosts activate a to hosts in roaming situations and typically, also when the
PDP Context or a PDN Connection. This means that 3GPP networks cellular hosts activate a PDP Context or a PDN Connection. This
will already provide a limited form of addressing privacy, and no means that 3GPP networks will already provide a limited form of
global tracking of a single host is possible through its address. addressing privacy, and no global tracking of a single host is
On the other hand, since a GGSN/PGW's coverage area is expected to possible through its address. On the other hand, since a GGSN/
be very large when compared to currently deployed default routers PGW's coverage area is expected to be very large when compared to
(no handovers between GGSN/PGWs are possible), a cellular host can currently deployed default routers (no handovers between GGSN/PGWs
keep an address for a long time. Hence, IPv6 addressing privacy are possible), a cellular host can keep a prefix for a long time.
can be used for additional privacy during the time the host is on Hence, IPv6 addressing privacy can be used for additional privacy
and in the same area. The privacy features can also be used to during the time the host is on and in the same area. The privacy
e.g., make different transport sessions appear to come from features can also be used to e.g., make different transport
different IP addresses. However, it is not clear that these sessions appear to come from different IP addresses. However, it
additional efforts confuse potential observers any further, as is not clear that these additional efforts confuse potential
they could monitor only the network prefix part. observers any further, as they could monitor only the network
prefix part.
o The use of various security services such as IPsec or TLS in the o The use of various security services such as IPsec or TLS in the
connection of typical applications in cellular hosts is discussed connection of typical applications in cellular hosts is discussed
in Section 3 and further pointer for recommendations are given in Section 3 and further pointer for recommendations are given
there. there.
o The airtime used by cellular hosts is expensive. In some cases, o The airtime used by cellular hosts is expensive. In some cases,
users are billed according to the amount of data they transfer to users are billed according to the amount of data they transfer to
and from their host. It is crucial for both the network and the and from their host. It is crucial for both the network and the
users that the airtime is used correctly and no extra charges are users that the airtime is used correctly and no extra charges are
applied to users due to misbehaving third parties. The cellular applied to users due to misbehaving third parties. The cellular
links also have a limited capacity, which means that they may not links also have a limited capacity, which means that they may not
skipping to change at page 17, line 4 skipping to change at page 17, line 14
interface identifier, usually in a random manner. It must ensure the interface identifier, usually in a random manner. It must ensure the
uniqueness of such identifier on the link (i.e., no collisions uniqueness of such identifier on the link (i.e., no collisions
between its own link-local address and the cellular host's). between its own link-local address and the cellular host's).
In addition, the GGSN/PGW will not use any of the prefixes assigned In addition, the GGSN/PGW will not use any of the prefixes assigned
to cellular hosts to generate any of its own addresses. This use of to cellular hosts to generate any of its own addresses. This use of
the interface identifier, combined with the fact that each PDP the interface identifier, combined with the fact that each PDP
Context or PDN Connection is allocated a unique prefix, will Context or PDN Connection is allocated a unique prefix, will
eliminate the need for DAD messages over the air interface, and eliminate the need for DAD messages over the air interface, and
consequently reduces inefficient use of radio resources. consequently reduces inefficient use of radio resources.
Furthermore, the allocation of a prefix to each PDP Context or PDN Furthermore, the allocation of a prefix to each PDP Context or PDN
Connection will allow hosts to implement the privacy extensions in Connection will allow hosts to implement the Privacy Extensions in
[RFC4941] without the need for further DAD messages. [RFC4941] without the need for further DAD messages.
In practice, the GGSN/PGW only needs to route all traffic to the In practice, the GGSN/PGW only needs to route all traffic destined to
cellular host that fall under the prefix assigned to it. This the cellular host that falls under the prefix assigned to it. This
implies the GGSN/PGW may implement a minimal neighbor discovery implies the GGSN/PGW may implement a minimal neighbor discovery
protocol subset; since, due the point-to-point link model and the protocol subset; since, due the point-to-point link model and the
absence of link-layer addressing the address resolution can be absence of link-layer addressing the address resolution can be
entirely statically configured per PDP Context or PDN Connection, and entirely statically configured per PDP Context or PDN Connection, and
there is no need to defend any other address than the link-local there is no need to defend any other address than the link-local
address for very unlikely duplicates. This has also an additional address for very unlikely duplicates. This has also an additional
effect on a router to host NUD. There is really no need for, since effect on a router to host NUD. There is really no need for it,
from the GGSN/PGW point of view it does not need to care for single since from the GGSN/PGW point of view it does not need to care for a
addresses, just route the whole prefix to the cellular host single address, just routes the whole prefix to the cellular host.
direction. However, the cellular host must be prepared for the However, the cellular host must be prepared for the unlikely event of
unlikely event of receiving a NUD against its link-local address. It receiving a NUD against its link-local address. It should be noted
should be noted that the 3GPP specifications at the time of writing that the 3GPP specifications at the time of writing this document are
this document are silent what should happen if the router to host NUD silent what should happen if the router to host NUD fails.
fails.
See Sections 5 of [RFC6459] for further discussion on 3GPP address See Sections 5 of [RFC6459] for further discussion on 3GPP address
allocation and link model. allocation and link model.
Appendix B. Changes to RFC 3316 Appendix B. Changes to RFC 3316
B.1. Version draft-ietf-v6ops-rfc3316bis-02 B.1. Version draft-ietf-v6ops-rfc3316bis-03
o Clarified that RFC4941 or similar technologies instead of plain
RFC4941 may be used for privacy purposes (as stated in RFC6459).
o Clarified that MLD for link-local addresses is not necessary but
doing it causes no hard (instead of saying it may not be needed in
some cases).
o Clarified that a cellular host should not do any changes in its
stack to meet the 3GPP link restriction on the RA PIO options.
o Clarified that a cellular host should not do any changes in its
stack to meet the infinite prefix lifetime requirement the 3GPP
link has.
o Clarified that the prefix lifetime is tied to the PDP Context/PDN
Connection lifetime.
o Implemented numerous WGLC #1 comments.
B.2. Version draft-ietf-v6ops-rfc3316bis-02
o Clarified explicitly that a NUD from the gateway side to the UE's o Clarified explicitly that a NUD from the gateway side to the UE's
link-local address is possible. link-local address is possible.
o Added references to 3GPP specifications. o Added references to 3GPP specifications.
B.2. Version draft-ietf-v6ops-rfc3316bis-01 B.3. Version draft-ietf-v6ops-rfc3316bis-01
o Additional clarification on NUD on 3GPP cellular links. o Additional clarification on NUD on 3GPP cellular links.
o Added an explicit note that the prefix on the link is /64. o Added an explicit note that the prefix on the link is /64.
o Clarified that DHCPv6 (RFC3315) is not used at all for address o Clarified that DHCPv6 (RFC3315) is not used at all for address
autoconfiguration. autoconfiguration.
B.3. Version draft-ietf-v6ops-rfc3316bis-00 B.4. Version draft-ietf-v6ops-rfc3316bis-00
o Removal of all sections that can be directly found from RFC 6434. o Removal of all sections that can be directly found from RFC 6434.
o Clarifications to 3GPP link model and how Neighbor Discovery works o Clarifications to 3GPP link model and how Neighbor Discovery works
on it. on it.
o Addition of RFC 4191 recommendations. o Addition of RFC 4191 recommendations.
o Addition of DHCPv6-based Prefix Delegation recommendations. o Addition of DHCPv6-based Prefix Delegation recommendations.
o Addition of RFC 6106 recommendations. o Addition of RFC 6106 recommendations.
o Addition of RFC 5555 regarding client based mobility. o Addition of RFC 5555 regarding client based mobility.
o Addition of Router Advertisement MTU option handling. o Addition of Router Advertisement MTU option handling.
o Addition of Evolved Packet System text. o Addition of Evolved Packet System text.
o Clarification on the primary 3GPP IPv6 transition mechanism. o Clarification on the primary 3GPP IPv6 transition mechanism.
o Addition of RFC 5095 that deprecates the RH0 o Addition of RFC 5095 that deprecates the RH0
o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers
regarding the IPv6 fragmentation handling. regarding the IPv6 fragmentation handling.
o Addition of RFC 6583 for Neighbor Discovery denial-of-service o Addition of RFC 6583 for Neighbor Discovery denial-of-service
 End of changes. 63 change blocks. 
166 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/