draft-ietf-v6ops-rfc3316bis-00.txt   draft-ietf-v6ops-rfc3316bis-01.txt 
IPv6 Operations (V6OPS) J. Korhonen, Ed. IPv6 Operations (V6OPS) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks 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: May 16, 2013 T. Savolainen Expires: August 29, 2013 T. Savolainen
Nokia Nokia
S. Krishnan S. Krishnan
Ericsson Ericsson
November 12, 2012 February 25, 2013
IPv6 for 3GPP Cellular Hosts IPv6 for 3GPP Cellular Hosts
draft-ietf-v6ops-rfc3316bis-00.txt draft-ietf-v6ops-rfc3316bis-01.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 are making 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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 May 16, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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. IPv6 Stateless Address Autoconfiguration . . . . . . . . . 8
2.4. Stateless Address Autoconfiguration in 3GPP Networks . . . 8 2.4. Stateless Address Autoconfiguration in 3GPP Networks . . . 8
2.5. IP version 6 over PPP in 3GPP Networks . . . . . . . . . . 9 2.5. IP version 6 over PPP in 3GPP Networks . . . . . . . . . . 9
2.6. MLD in 3GPP Networks . . . . . . . . . . . . . . . . . . . 9 2.6. MLD in 3GPP Networks . . . . . . . . . . . . . . . . . . . 9
2.7. Privacy Extensions for Address Configuration in IPv6 . . . 9 2.7. Privacy Extensions for Address Configuration in IPv6 . . . 10
2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . . 10 2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . . 10
2.9. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10 2.9. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10
2.10. Router preferences and more specific routes . . . . . . . 10 2.10. Router preferences and more specific routes . . . . . . . 10
2.11. Neighbor Discovery and additional host configuration . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 14 8.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 15 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 15
Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 16 Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 17
B.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 16 B.1. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 17
B.2. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 such
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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. Some further notes on how these are applied
in the particular type of an interface can be useful, however: in the particular type of an interface can be useful, however:
In GPRS, UMTS and EPS networks, some Neighbor Discovery messages can In GPRS, UMTS and EPS networks, some Neighbor Discovery messages can
be unnecessary in certain cases. GPRS, UMTS and EPS links resemble a be unnecessary in certain cases. GPRS, UMTS and EPS links resemble a
point- to-point link; hence, the cellular host's only neighbor on the point-to-point link; hence, the cellular host's only neighbor on the
cellular link is the default router that is already known through cellular link is the default router that is already known through
Router Discovery. The cellular host always solicits for routers when Router Discovery. The cellular host always solicits for routers when
the cellular interface is enabled (as described in [RFC4861], Section the cellular interface is enabled (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. Therefore, address resolution and
next-hop determination are not needed. If the cellular host still next-hop determination are not needed. If the cellular host still
attempts the address resolution e.g., for the default router, it must attempts the address resolution e.g., for the default router, it must
be understood that the GGSN/PGW may not even answer the address 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.
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 Neighbor Unreachability considerations above also apply to the NUD. The NUD triggered
Detection. The NUD triggered Neighbor Advertisement is also unlikely Neighbor Advertisement is also unlikely to contain the Target link-
to contain the Target link-layer address option as there are no link- layer address option as there are no link-layer addresses. The
layer addresses. 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
ever take place on a GPRS, UMTS and EPS links. See Appendix A for
more discussion on the router to host NUD.
In GPRS, UMTS and EPS networks, it is very desirable to reduce any In GPRS, UMTS and EPS networks, it is very desirable to reduce any
additional periodic signaling. Therefore, the cellular host should additional periodic signaling. Therefore, the cellular host should
include a mechanism in upper layer protocols to provide reachability include a mechanism in upper layer protocols to provide reachability
confirmations when two-way IP layer reachability can be confirmed confirmations when two-way IP layer reachability can be confirmed
(see [RFC4861], Section 7.3.1). These confirmations would allow the (see [RFC4861], Section 7.3.1). These confirmations would allow the
suppression of NUD-related messages in most cases. suppression of 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.
skipping to change at page 10, line 19 skipping to change at page 10, line 25
assignments depends upon many factors such as radio coverage, device assignments depends upon many factors such as radio coverage, device
status and user preferences. Additionally, the use of temporary status and user preferences. Additionally, the use of temporary
address with IPsec may lead to more frequent renegotiation for the address with IPsec may lead to more frequent renegotiation for the
Security Associations. 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.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] As of 3GPP Release-11 The Dynamic Host Configuration Protocol for
may be used. As of 3GPP Release-11 DHCPv6 is neither required nor IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address
supported for address autoconfiguration. The IPv6 stateless autoconfiguration. The IPv6 stateless autoconfiguration still
autoconfiguration still remains the only mandatory address remains the only mandatory address configuration method. However,
configuration method. However, DHCPv6 may be useful for other DHCPv6 may be useful for other configuration needs on a cellular
configuration needs on a cellular host. e.g. Stateless DHCPv6 host. e.g. Stateless DHCPv6 [RFC3736] may be used to configure DNS
[RFC3736] may be used to configure DNS and SIP server addresses, and and SIP server addresses, and DHCPv6 prefix delegation [RFC3633] may
DHCPv6 prefix delegation [RFC3633] may be used to delegate a prefix be used to delegate a prefix to the cellular host for use on its
to the cellular host for use on its non-cellular links. downstream non-cellular links.
2.9. DHCPv6 Prefix Delegation 2.9. 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 for 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
skipping to change at page 12, line 43 skipping to change at page 12, line 47
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] may be used in cellular hosts.
However, it should be noted that in the 3GPP model, the network However, it should be noted that in the 3GPP model, the network
would assign new addresses, in most cases, to hosts in roaming would assign new addresses, in most cases, to hosts in roaming
situations and typically, also when the cellular hosts activate a situations and typically, also when the cellular hosts activate a
PDP context. This means that 3GPP networks will already provide a PDP Context or a PDN Connection. This means that 3GPP networks
limited form of addressing privacy, and no global tracking of a will already provide a limited form of addressing privacy, and no
single host is possible through its address. On the other hand, global tracking of a single host is possible through its address.
since a GGSN's coverage area is expected to be very large when On the other hand, since a GGSN's coverage area is expected to be
compared to currently deployed default routers (no handovers very large when compared to currently deployed default routers (no
between GGSNs are possible), a cellular host can keep an address handovers between GGSNs are possible), a cellular host can keep an
for a long time. Hence, IPv6 addressing privacy can be used for address for a long time. Hence, IPv6 addressing privacy can be
additional privacy during the time the host is on and in the same used for additional privacy during the time the host is on and in
area. The privacy features can also be used to e.g., make the same area. The privacy features can also be used to e.g.,
different transport sessions appear to come from different IP make different transport sessions appear to come from different IP
addresses. However, it is not clear that these additional efforts addresses. However, it is not clear that these additional efforts
confuse potential observers any further, as they could monitor confuse potential observers any further, as they could monitor
only the network prefix part. 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
skipping to change at page 14, line 10 skipping to change at page 14, line 17
o Advice for implementations in the face of Neighbor Discovery DoS o Advice for implementations in the face of Neighbor Discovery DoS
attacks may be useful in some environments [RFC6583]. attacks may be useful in some environments [RFC6583].
o Section 9 of RFC 6459 discusses further some recent concerns o Section 9 of RFC 6459 discusses further some recent concerns
related to cellular hosts security. related to cellular hosts security.
8. References 8. References
8.1. Normative references 8.1. Normative references
[I-D.ietf-6man-nd-extension-headers] [I-D.ietf-6man-nd-extension-headers]
Gont, F., "Security Implications of the Use of IPv6 Gont, F., "Security Implications of IPv6 Fragmentation
Extension Headers with IPv6 Neighbor Discovery", with IPv6 Neighbor Discovery",
draft-ietf-6man-nd-extension-headers-00 (work in draft-ietf-6man-nd-extension-headers-03 (work in
progress), June 2012. progress), January 2013.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
skipping to change at page 15, line 50 skipping to change at page 16, line 12
documentation for 4G can be found from 3GPP Technical Specifications documentation for 4G can be found from 3GPP Technical Specifications
23.401, 23.402 and 29.061. 23.401, 23.402 and 29.061.
There are two possibilities to allocate the address for an IPv6 node: There are two possibilities to allocate the address for an IPv6 node:
stateless and stateful autoconfiguration. The stateful address stateless and stateful autoconfiguration. The stateful address
allocation mechanism needs a DHCP server to allocate the address for allocation mechanism needs a DHCP server to allocate the address for
the IPv6 node. On the other hand, the stateless autoconfiguration the IPv6 node. On the other hand, the stateless autoconfiguration
procedure does not need any external entity involved in the address procedure does not need any external entity involved in the address
autoconfiguration (apart from the GGSN/PGW). At the time of writing autoconfiguration (apart from the GGSN/PGW). At the time of writing
this document, the IPv6 stateless address autoconfiguration mechanism this document, the IPv6 stateless address autoconfiguration mechanism
is still the only madatory and supported address configuration method is still the only mandatory and supported address configuration
for the cellular 3GPP link. method for the cellular 3GPP link.
In order to support the standard IPv6 stateless address In order to support the standard IPv6 stateless address
autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW
shall assign a prefix that is unique within its scope to each primary shall assign a single /64 IPv6 prefix that is unique within its scope
PDP context that uses IPv6 stateless address autoconfiguration. This to each primary PDP Context or PDN Connection that uses IPv6
avoids the necessity to perform Duplicate Address Detection (DAD) at stateless address autoconfiguration. This avoids the necessity to
the network level for every address built by the mobile host. The perform Duplicate Address Detection (DAD) at the network level for
GGSN/PGW always provides an Interface Identifier to the mobile host. every address built by the mobile host. The GGSN/PGW always provides
The Mobile host uses the interface identifier provided by the GGSN to an interface identifier to the mobile host. The Mobile host uses the
generate its link-local address. The GGSN/PGW provides the cellular interface identifier provided by the GGSN to generate its link-local
host with the interface identifier, usually in a random manner. It address. The GGSN/PGW provides the cellular host with the interface
must ensure the uniqueness of such identifier on the link (i.e., no identifier, usually in a random manner. It must ensure the
collisions between its own link-local address and the cellular uniqueness of such identifier on the link (i.e., no collisions
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 will Furthermore, the allocation of a prefix to each PDP context will
allow hosts to implement the privacy extensions in RFC 4941 without allow hosts to implement the privacy extensions in RFC 4941 without
the need for further DAD messages. 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 to the
cellular host that fall under the prefix assigned to it. This cellular host that fall 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. address for very unlikely duplicates. This has also an additional
effect on a router to host NUD. There is really no need for one,
since from the GGSN/PGW point of view it does not need to care for
single addresses, just route the whole prefix to the cellular host
direction. Furthermore, 3GPP specifications at the time of writing
this document are silent what should happen if the router to host NUD
fails.
See Sections 5 of RFC 6459 for further discussion on 3GPP address See Sections 5 of RFC 6459 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 -00 B.1. Version -01
o Additional clarification on NUD on 3GPP cellular links.
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
autoconfiguration.
B.2. Version -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.
skipping to change at page 17, line 22 skipping to change at page 17, line 39
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
attack considerations. attack considerations.
o Made the PPP IPV6CP support text conditional. o Made the PPP IPV6CP support text conditional.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Nokia Siemens Networks Renesas Mobile
Linnoitustie 6 Porkkalankatu 24
FIN-02600 Espoo FIN-00180 Helsinki
Finland Finland
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
Jari Arkko (editor) Jari Arkko (editor)
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Teemu Savolainen Teemu Savolainen
Nokia Nokia
Hermiankatu 12 D Hermiankatu 12 D
 End of changes. 23 change blocks. 
60 lines changed or deleted 75 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/