draft-ietf-v6ops-rfc3316bis-03.txt   draft-ietf-v6ops-rfc3316bis-04.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 28, 2013 T. Savolainen Expires: March 4, 2014 T. Savolainen
Nokia Nokia
S. Krishnan S. Krishnan
Ericsson Ericsson
May 27, 2013 August 31, 2013
IPv6 for 3GPP Cellular Hosts IPv6 for 3GPP Cellular Hosts
draft-ietf-v6ops-rfc3316bis-03.txt draft-ietf-v6ops-rfc3316bis-04.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 have made 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
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 November 28, 2013. This Internet-Draft will expire on March 4, 2014.
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 32 skipping to change at page 3, line 32
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 . . . . . . . . . . . . . . . . . 18
B.1. Version draft-ietf-v6ops-rfc3316bis-03 . . . . . . . . . . 17
B.2. Version draft-ietf-v6ops-rfc3316bis-02 . . . . . . . . . . 18
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 [RFC2460] has become essential to such networks as the number of
skipping to change at page 4, line 31 skipping to change at page 4, line 31
1.1. Scope of this Document 1.1. Scope of this Document
For the purpose 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 the with discussion on the use places where clarifications are needed with discussion on the use of
of these selected IPv6 specifications when operating over a cellular these selected IPv6 specifications when operating over a cellular
interface. Such a specification is necessary in order to enable the interface. Such a specification is necessary in order to enable the
optimal use of IPv6 in a cellular network environment. The optimal use of IPv6 in a cellular network environment. The
description is made from a cellular host point of view. description is made from a cellular host point of view.
Complementary access technologies may be supported by the cellular Complementary access technologies may be supported by the cellular
host, but those are not discussed in detail. Important host, but those are not discussed in detail. Important
considerations are given in order to eliminate unnecessary user considerations are given in order to eliminate unnecessary user
confusion over configuration options, ensure interoperability and to confusion over configuration options, ensure interoperability and to
provide an easy reference for those who are implementing IPv6 in a provide an easy reference for those who are implementing IPv6 in a
cellular host. It is necessary to ensure that cellular hosts are cellular host. It is necessary to ensure that cellular hosts are
good citizens of the Internet. good citizens of the Internet.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
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
functionalies 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 build-in o The host can be a "closed" device with optimized built-in
applications, with no possibility to add or download applications applications, with no possibility to add or download applications
that can have IP communications. An example of such a host is a that can have IP communications. An example of such a host is a
very simple 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. One 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.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
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
transport RTP, the RTCP protocol feedback should be used as a basis transport RTP [RFC3550], the RTCP protocol [RFC3550] feedback should
for the reachability confirmation. If an RTCP packet is received be used as a basis for the reachability confirmation. If an RTCP
with a reception report block indicating some packets have gone packet is received with a reception report block indicating some
through, then packets are reaching the peer. If they have reached packets have gone through, then packets are reaching the peer. If
the peer, they have also reached the neighbor. they have reached 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 [RFC3261], responses to SIP
should be used as the confirmation that packets sent to the peer are requests should be used as the confirmation that packets sent to the
reaching it. When the cellular host is acting as the server side SIP peer are reaching it. When the cellular host is acting as the server
node, no such confirmation is generally available. However, a host side SIP node, no such confirmation is generally available. However,
may interpret the receipt of a SIP ACK request as confirmation that a host may interpret the receipt of a SIP ACK request as confirmation
the previously sent response to a SIP INVITE request has reached the that the previously sent response to a SIP INVITE request has reached
peer. the peer.
2.3. 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.
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
skipping to change at page 9, line 30 skipping to change at page 9, line 30
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 on the perform Duplicate Address Detection for the link-local address 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.4. IP version 6 over PPP 2.4. IP version 6 over PPP
A cellular host in a 3GPP network that supports PPP on the interface A cellular host in a 3GPP network that supports PPP [RFC1661] on the
between the MT and the TE, must support the IPv6CP interface interface between the MT and the TE, must support the IPv6CP
identifier option. This option is needed to be able to connect other [RFC5072] interface identifier option. This option is needed to be
devices to the Internet using a PPP link between the cellular device able to connect other devices to the Internet using a PPP link
(MT, e.g., a USB dongle) and other devices (TE, e.g., a laptop). The between the cellular device (MT, e.g., a USB dongle) and other
MT performs the PDP Context activation based on a request from the devices (TE, e.g., a laptop). The MT performs the PDP Context
TE. This results in an interface identifier being suggested by the activation based on a request from the TE. This results in an
MT to the TE, using the IPv6CP option. To avoid any duplication in interface identifier being suggested by the MT to the TE, using the
link-local addresses between the TE and the GGSN/PGW, the MT must IPv6CP option. To avoid any duplication in link-local addresses
always reject other suggested interface identifiers by the TE. This between the TE and the GGSN/PGW, the MT must always reject other
results in the TE always using the interface identifier suggested by suggested interface identifiers by the TE. This results in the TE
the GGSN/PGW for its link-local address. 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] or similar specifications. The use of privacy addresses [RFC4941] or similar
technologies for unique local IPv6 unicast addresses (ULA) [RFC4193] technologies for unique local IPv6 unicast addresses (ULA) [RFC4193]
and global addresses is not affected by the above procedure. and global addresses is not affected by the above procedure.
2.5. Multicast Listener Discovery (MLD) for IPv6 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/
skipping to change at page 11, line 38 skipping to change at page 11, line 38
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 to the IPv6 Node Requirements Section 11 of [RFC6434] for the Refer to the IPv6 Node Requirements Section 11 of [RFC6434] for the
security 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 [RFC5095].
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
discovery messages as described in discovery messages as described in [RFC6980].
[I-D.ietf-6man-nd-extension-headers].
4. Mobility 4. Mobility
For the purposes of this document, IP mobility is not relevant. The For the purposes of this document, IP mobility is not relevant. The
movement of cellular hosts within 3GPP networks is handled by link movement of cellular hosts within 3GPP networks is handled by link
layer mechanisms in majority of cases. 3GPP Release-8 introduced the layer mechanisms in majority of cases. 3GPP Release-8 introduced the
dual-stack Mobile IPv6 (DSMIPv6) for a client based mobility dual-stack Mobile IPv6 (DSMIPv6) for a client based mobility
[RFC5555]. Client based IP mobility is optional in 3GPP [RFC5555]. Client based IP mobility is optional in 3GPP
architecture. architecture.
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank the original authors for their The authors would like to thank the original authors for their
skipping to change at page 12, line 18 skipping to change at page 12, line 18
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank the original authors for their The authors would like to thank the original authors for their
grounding work on this documents: Gerben Kuijpers, John Loughney, grounding work on this documents: Gerben Kuijpers, John Loughney,
Hesham Soliman and Juha Wiljakka. Hesham Soliman and Juha Wiljakka.
The original RFC 3316 document was based on the results of a team The original [RFC3316] document was based on the results of a team
that included Peter Hedman and Pertti Suomela in addition to the that included Peter Hedman and Pertti Suomela in addition to the
authors. Peter and Pertti have contributed both text and their IPv6 authors. Peter and Pertti have contributed both text and their IPv6
experience to this document. experience to this document.
The authors would like to thank Jim Bound, Brian Carpenter, Steve The authors would like to thank Jim Bound, Brian Carpenter, Steve
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 [RFC3316] the authors would like thank
Dave Thaler, Ales Vizdal, Gang Chen, Ray Hunter and Owen DeLong for Dave Thaler, Ales Vizdal, Gang Chen, Ray Hunter, Charlie Kaufman,
their comments, reviews and inputs. Owen DeLong and Alexey Melnikov for their comments, reviews and
inputs.
7. Security Considerations 7. Security Considerations
This document does not specify any new protocols or functionalities, 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:
skipping to change at page 14, line 18 skipping to change at page 14, line 18
cellular hosts. cellular hosts.
o Cellular devices that have local network interfaces (such as WLAN o Cellular devices that have local network interfaces (such as WLAN
or Bluetooth) may be used to launch attacks through them, unless or Bluetooth) may be used to launch attacks through them, unless
the local interfaces are secured in an appropriate manner. the local interfaces are secured in an appropriate manner.
Therefore, local network interfaces should have access control to Therefore, local network interfaces should have access control to
prevent others from using the cellular host as an intermediary. prevent others from using the cellular host as an intermediary.
o The 3GPP link model mitigates most of the known IPv6 on-link and o The 3GPP link model mitigates most of the known IPv6 on-link and
neighbor cache targeted attacks (see Section 2.2 and Appendix A). neighbor cache targeted attacks (see Section 2.2 and Appendix A).
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 [RFC6459] 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]
Gont, F., "Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery",
draft-ietf-6man-nd-extension-headers-04 (work in
progress), March 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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
skipping to change at page 15, line 15 skipping to change at page 15, line 8
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009. RFC 5722, December 2009.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery", RFC 6980, August 2013.
8.2. Informative references 8.2. Informative references
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
Second and Third Generation Cellular Hosts", RFC 3316,
April 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. RFC 6106, November 2010.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
skipping to change at page 17, line 39 skipping to change at page 18, line 7
However, the cellular host must be prepared for the unlikely event of However, the cellular host must be prepared for the unlikely event of
receiving a NUD against its link-local address. It should be noted receiving a NUD against its link-local address. It should be noted
that the 3GPP specifications at the time of writing this document are that the 3GPP specifications at the time of writing this document are
silent what should happen if the router to host NUD fails. silent what should happen if the router to host NUD 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-03 o Clarified that [RFC4941] or similar technologies instead of plain
[RFC4941] may be used for privacy purposes (as stated in
o Clarified that RFC4941 or similar technologies instead of plain [RFC6459]).
RFC4941 may be used for privacy purposes (as stated in RFC6459).
o Clarified that MLD for link-local addresses is not necessary but 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 doing it causes no harm (instead of saying it may not be needed in
some cases). some cases).
o Clarified that a cellular host should not do any changes in its 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. 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 o Clarified that a cellular host should not do any changes in its
stack to meet the infinite prefix lifetime requirement the 3GPP stack to meet the infinite prefix lifetime requirement the 3GPP
link has. link has.
o Clarified that the prefix lifetime is tied to the PDP Context/PDN o Clarified that the prefix lifetime is tied to the PDP Context/PDN
Connection lifetime. 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.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.
o Removal of all sections that can be directly found from [RFC6434].
B.4. Version draft-ietf-v6ops-rfc3316bis-00
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 [RFC4191] 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 [RFC6106] recommendations.
o Addition of RFC 5555 regarding client based mobility. o Addition of [RFC5555] 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 [RFC5095] that deprecates the RH0.
o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers o Addition of [RFC5722] and [RFC6980] regarding the IPv6
regarding the IPv6 fragmentation handling. fragmentation handling.
o Addition of RFC 6583 for Neighbor Discovery denial-of-service o Addition of [RFC6583] for Neighbor Discovery denial-of-service
attack considerations. attack considerations.
o Made the PPP IPV6CP support text conditional. o Made the PPP IPv6CP [RFC5072] support text conditional.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Renesas Mobile Renesas Mobile
Porkkalankatu 24 Porkkalankatu 24
FIN-00180 Helsinki FIN-00180 Helsinki
Finland Finland
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 32 change blocks. 
76 lines changed or deleted 79 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/