GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3316

Network Working Group J. Arkko Request for Comments: 3316 G. Kuijpers Category: Informational H. Soliman

                                                              Ericsson
                                                           J. Loughney
                                                           J. Wiljakka
                                                                 Nokia
                                                            April 2003
                 Internet Protocol Version 6 (IPv6)
        for Some Second and Third Generation Cellular Hosts

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

 As the deployment of second and third generation cellular networks
 progresses, a large number of cellular hosts are being connected to
 the Internet.  Standardization organizations are making Internet
 Protocol version 6 (IPv6) mandatory in their specifications.
 However, the concept of IPv6 covers many aspects and numerous
 specifications.  In addition, the characteristics of cellular links
 in terms of bandwidth, cost and delay put special requirements on how
 IPv6 is used.  This document considers IPv6 for cellular hosts that
 attach to the General Packet Radio Service (GPRS), or Universal
 Mobile Telecommunications System (UMTS) networks.  This document also
 lists basic components of IPv6 functionality and discusses some
 issues relating to the use of these components when operating in
 these networks.

Arkko, et al. Informational [Page 1] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

Table of Contents

 1. Introduction.....................................................3
    1.1  Scope of this Document......................................3
    1.2  Abbreviations...............................................4
    1.3  Cellular Host IPv6 Features.................................5
 2. Basic IP.........................................................5
    2.1  RFC1981 - Path MTU Discovery for IP Version 6...............5
    2.2  RFC3513 - IP Version 6 Addressing Architecture..............6
    2.3  RFC2460 - Internet Protocol Version 6.......................6
    2.4  RFC2461 - Neighbor Discovery for IPv6.......................7
    2.5  RFC2462 - IPv6 Stateless Address Autoconfiguration..........8
    2.6  RFC2463 - Internet Control Message Protocol for the IPv6....8
    2.7  RFC2472 - IP version 6 over PPP.............................9
    2.8  RFC2473 - Generic Packet Tunneling in IPv6 Specification....9
    2.9  RFC2710 - Multicast Listener Discovery (MLD) for IPv6.......9
    2.10 RFC2711 - IPv6 Router Alert Option.........................10
    2.11 RFC3041 - Privacy Extensions for Address Configuration
                   in IPv6 .........................................10
    2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)......10
    2.13 RFC3484 - Default Address Selection for IPv6...............11
    2.14 DNS........................................................11
 3. IP Security.....................................................11
    3.1  RFC2104 - HMAC: Keyed-Hashing for Message Authentication...12
    3.2  RFC2401 - Security Architecture for the Internet Protocol..12
    3.3  RFC2402 - IP Authentication Header.........................12
    3.4  RFC2403 - The Use of HMAC-MD5-96 within ESP and AH.........12
    3.5  RFC2404 - The Use of HMAC-SHA-96 within ESP and AH.........12
    3.6  RFC2405 - The ESP DES-CBC Cipher Algorithm With
                   Explicit IV......................................12
    3.7  RFC2406 - IP Encapsulating Security Payload (ESP)..........12
    3.8  RFC2407 - The Internet IP Security DoI for ISAKMP..........12
    3.9  RFC2408 - The Internet Security Association and Key
                   Management Protocol..............................13
    3.10 RFC2409 - The Internet Key Exchange (IKE)..................13
    3.11 RFC2410 - The NULL Encryption Algorithm & its Use
                   With IPsec.......................................14
    3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms...............14
 4. Mobility........................................................14
 5. Security Considerations.........................................14
 6. References......................................................16
    6.1  Normative..................................................16
    6.2  Informative................................................18
 7. Contributors....................................................19
 8. Acknowledgements................................................19
 Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model.......20
 Authors' Addresses.................................................21
 Full Copyright Statement...........................................22

Arkko, et al. Informational [Page 2] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

1 Introduction

 Technologies such as GPRS (General Packet Radio Service), UMTS
 (Universal Mobile Telecommunications System) and CDMA2000 (Code
 Division Multiple Access 2000) are making it possible for cellular
 hosts to have an always-on connection to the Internet.  IPv6 becomes
 necessary, as it is expected that the number of such cellular hosts
 will increase rapidly.  Standardization organizations working with
 cellular technologies have recognized this and are making IPv6
 mandatory in their specifications.
 Support for IPv6 and the introduction of UMTS starts with 3GPP
 Release 99 networks and hosts.  IPv6 is specified as the only IP
 version supported for IP Multimedia Subsystem (IMS) starting from
 Release 5.

1.1 Scope of this Document

 For the purposes of this document, a cellular interface is considered
 to be the interface to a cellular access network based on the
 following standards: 3GPP GPRS and UMTS Release 99, Release 4,
 Release 5, as well as future UMTS releases.  A cellular host is
 considered to be a host with such a cellular interface.
 This document lists IPv6 specifications with discussion on the use of
 these specifications when operating over cellular interfaces.  Such a
 specification is necessary in order for the optimal use of IPv6 in a
 cellular environment.  The description is made from a cellular host
 point of view.  Important considerations are given in order to
 eliminate unnecessary user confusion over configuration options,
 ensure interoperability and to provide an easy reference for those
 implementing IPv6 in a 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
 replace, update, or contradict any IPv6 standards documents [RFC-
 2026].
 The main audience of this document are:  the implementers of cellular
 hosts that will be used with GPRS, 3GPP UMTS Release 99, Release 4,
 Release 5, or future releases of UMTS.  The document provides
 guidance on which parts of IPv6 to implement in such cellular hosts.
 Parts of this document may also apply to other cellular link types,
 but no such detailed analysis has been done yet and is a topic of
 future work.  This document should not be used as a definitive list

Arkko, et al. Informational [Page 3] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 of IPv6 functionality for cellular links other than those listed
 above.  Future changes in 3GPP networks that require changes in host
 implementations may result in updates to this document.
 There are different ways to implement cellular hosts:
  1. The host can be a "closed 2G or 3G host" with a very compact size

and optimized applications, with no possibility to add or download

   applications that can have IP communications.  An example of such a
   host is a very simple form of a mobile phone.
  1. The host can be an "open 2G or 3G host" with a compact size, but

where it is possible to download applications; such as a PDA-type

   of phone.
 If a cellular host has additional interfaces on which IP is used,
 (such as Ethernet, WLAN, Bluetooth, etc.) then there may be
 additional requirements for the device, beyond what is discussed in
 this document.  Additionally, this document does not make any
 recommendations on the functionality required on laptop computers
 having a cellular interface such as a PC card, other than
 recommending link specific behavior on the cellular link.
 This document discusses IPv6 functionality as specified when this
 document has been written.  Ongoing work on IPv6 may affect what is
 needed from future hosts.  The reader should also be advised other
 relevant work exists for various other layers.  Examples of this
 include the header compression work done in the IETF ROHC group, the
 analysis of the effects of error-prone links to performance in [RFC-
 3155], or the TCP work in [RFC-3481].
 Transition mechanisms used by cellular hosts are not described in
 this document and are left for further study.

1.2 Abbreviations

 2G     Second Generation Mobile Telecommunications, such as GSM and
        GPRS technologies.
 3G     Third Generation Mobile Telecommunications, such as UMTS
        technology.
 3GPP   3rd Generation Partnership Project.  Throughout the document,
        the term 3GPP (3rd Generation Partnership Project) networks
        refers to architectures standardized by 3GPP, in Second and
        Third Generation releases: 99, 4, and 5, as well as future
        releases.
 AH     Authentication Header
 APN    Access Point Name.  The APN is a logical name referring to a
        GGSN and an external network.

Arkko, et al. Informational [Page 4] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 ESP    Encapsulating Security Payload
 ETSI   European Telecommunications Standards Institute
 IMS    IP Multimedia Subsystem
 GGSN   Gateway GPRS Support Node (a default router for 3GPP IPv6
        cellular hosts)
 GPRS   General Packet Radio Service
 GSM    Global System for Mobile Communications
 IKE    Internet Key Exchange
 ISAKMP Internet Security Association and Key Management Protocol
 MT     Mobile Terminal, for example, a mobile phone handset.
 MTU    Maximum Transmission Unit
 PDP    Packet Data Protocol
 SGSN   Serving GPRS Support Node
 TE     Terminal Equipment, for example, a laptop attached through a
        3GPP handset.
 UMTS   Universal Mobile Telecommunications System
 WLAN   Wireless Local Area Network

1.3 Cellular Host IPv6 Features

 This specification defines IPv6 features for cellular hosts in three
 groups.
   Basic IP
        In this group, basic parts of IPv6 are described.
   IP Security
        In this group, the IP Security parts are described.
   Mobility
        In this group, IP layer mobility issues are described.

2 Basic IP

2.1 RFC1981 - Path MTU Discovery for IP Version 6

 Path MTU Discovery [RFC-1981] may be used.  Cellular hosts with a
 link MTU larger than the minimum IPv6 link MTU (1280 octets) can use
 Path MTU Discovery in order to discover the real path MTU.  The
 relative overhead of IPv6 headers is minimized through the use of
 longer packets, thus making better use of the available bandwidth.

Arkko, et al. Informational [Page 5] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 The IPv6 specification [RFC-2460] states in Section 5 that "a minimal
 IPv6 implementation (e.g., in a boot ROM) may simply restrict itself
 to sending packets no larger than 1280 octets, and omit
 implementation of Path MTU Discovery."
 If Path MTU Discovery is not implemented then the sending packet size
 is limited to 1280 octets (standard limit in [RFC-2460]).  However,
 if this is done, the cellular host must be able to receive packets
 with size up to the link MTU before reassembly.  This is because the
 node at the other side of the link has no way of knowing less than
 the MTU is accepted.

2.2 RFC3513 - IP Version 6 Addressing Architecture

 The IPv6 Addressing Architecture [RFC-3513] is a mandatory part of
 IPv6.

2.3 RFC2460 - Internet Protocol Version 6

 The Internet Protocol Version 6 is specified in [RFC-2460].  This
 specification is a mandatory part of IPv6.
 By definition, a cellular host acts as a host, not as a router.
 Implementation requirements for a cellular router are not defined in
 this document.
 Consequently, the cellular host must implement all non-router packet
 receive processing as described in RFC 2460.  This includes the
 generation of ICMPv6 error reports, and the processing of at least
 the following extension headers:
  1. Hop-by-Hop Options header: at least the Pad1 and PadN options
  1. Destination Options header: at least the Pad1 and PadN options
  1. Routing (Type 0) header: final destination (host) processing only
  1. Fragment header
  1. AH and ESP headers (see also a discussion on the use of IPsec for

various purposes in Section 3)

  1. The No Next Header value
 Unrecognized options in Hop-by-Hop Options or Destination Options
 extensions must be processed as described in RFC 2460.

Arkko, et al. Informational [Page 6] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 The cellular host must follow the packet transmission rules in RFC
 2460.
 The cellular host must always be able to receive and reassemble
 fragment headers.  It will also need to be able to send a fragment
 header in cases where it communicates with an IPv4 host through a
 translator (see Section 5 of RFC2460).
 Cellular hosts should only process routing headers when they are the
 final destination and return errors if the processing of the routing
 header requires them to forward the packet to another node.  This
 will also ensure that the cellular hosts will not be inappropriately
 used as relays or components in Denial-of-Service (DoS) attacks.
 Acting as the destination involves the following:  the cellular hosts
 must check the Segments Left field in the header, and proceed if it
 is zero or one and the next address is one of the host's addresses.
 If not, however, the host must implement error checks as specified in
 Section 4.4 of RFC 2460.  There is no need for the host to send
 Routing Headers.

2.4 RFC2461 - Neighbor Discovery for IPv6

 Neighbor Discovery is described in [RFC-2461].  This specification is
 a mandatory part of IPv6.

2.4.1 Neighbor Discovery in 3GPP Networks

 A cellular host must support Neighbor Solicitation and Advertisement
 messages.
 In GPRS and UMTS networks, some Neighbor Discovery messages can be
 unnecessary in certain cases.  GPRS and UMTS links resemble a point-
 to-point link; hence, the cellular host's only neighbor on the
 cellular link is the default router that is already known through
 Router Discovery.  There are no link layer addresses.  Therefore,
 address resolution and next-hop determination are not needed.
 The cellular host must support neighbor unreachability detection as
 specified in [RFC-2461].
 In GPRS and UMTS networks, it is very desirable to conserve
 bandwidth.  Therefore, the cellular host should include a mechanism
 in upper layer protocols to provide reachability confirmation when
 two-way IP layer reachability can be confirmed (see RFC-2461, Section
 7.3.1).  These confirmations will allow the suppression of most NUD-
 related messages in most cases.

Arkko, et al. Informational [Page 7] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 Host TCP implementation should provide reachability confirmation in
 the manner explained in RFC 2461, Section 7.3.1.
 The common use of UDP in 3GPP networks poses a problem for providing
 reachability confirmation.  UDP itself is unable to provide such
 confirmation.  Applications running over UDP should provide the
 confirmation where possible.  In particular, when UDP is used for
 transporting RTP, the RTCP protocol feedback should be used as a
 basis for the reachability confirmation.  If an RTCP packet is
 received with a reception report block indicating some packets have
 gone through, then packets are reaching the peer.  If they have
 reached the peer, they have also reached the neighbor.
 When UDP is used for transporting SIP, responses to SIP requests
 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
 node, no such confirmation is generally available.  However, a host
 may interpret the receipt of a SIP ACK request as confirmation that
 the previously sent response to a SIP INVITE request has reached the
 peer.

2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration

 IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
 This specification is a mandatory part of IPv6.

2.5.1 Stateless Address Autoconfiguration in 3GPP Networks

 A cellular host in a 3GPP network must process a Router Advertisement
 as stated in Section 2.4.
 Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero,
 as each delegated prefix is unique within its scope when allocated
 using the 3GPP IPv6 Stateless Address Autoconfiguration.  In
 addition, the default router (GGSN) will not configure or assign to
 its interfaces, any addresses based on prefixes delegated to IPv6
 hosts.  Thus, the host is not required to perform Duplicate Address
 Detection on the cellular interface.
 See Appendix A for more details on 3GPP IPv6 Stateless Address
 Autoconfiguration.

2.6 RFC2463 - Internet Control Message Protocol for the IPv6

 The Internet Control Message Protocol for the IPv6 is defined [RFC-
 2463].  This specification is a mandatory part of IPv6.  Currently,
 this work is being updated.

Arkko, et al. Informational [Page 8] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 As per RFC 2463 Section 2, ICMPv6 requirements must be fully
 implemented by every IPv6 node.  See also Section 3 for an
 explanation of the use of IPsec for protecting ICMPv6 communications.

2.7 RFC2472 - IP version 6 over PPP

 IPv6 over PPP [RFC-2472] must be supported for cellular hosts that
 implement PPP.

2.7.1 IP version 6 over PPP in 3GPP Networks

 A cellular host in a 3GPP network must support the IPv6CP interface
 identifier option.  This option is needed to be able to connect other
 devices to the Internet using a PPP link between the cellular device
 (MT) and other devices (TE, e.g., a laptop).  The MT performs the PDP
 Context activation based on a request from the TE.  This results in
 an interface identifier being suggested by the MT to the TE, using
 the IPv6CP option.  To avoid any duplication in link-local addresses
 between the TE and the GGSN, the MT must always reject other
 suggested interface identifiers by the TE.  This results in the TE
 always using the interface identifier suggested by the GGSN for its
 link-local address.
 The rejection of interface identifiers suggested by the TE is only
 done for creation of link-local addresses, according to 3GPP
 specifications.  The use of privacy addresses [RFC-3041] for site-
 local and global addresses is not affected by the above procedure.
 The above procedure is only 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., site-local and global).

2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification

 Generic Packet Tunneling [RFC-2473] may be supported if needed for
 transition mechanisms.

2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6

 Multicast Listener Discovery [RFC-2710] must be supported by cellular
 hosts.
 MLD requires that MLD messages be sent for link-local multicast
 addresses (excluding the all-nodes address).  The requirement that
 MLD be run even for link-local addresses aids layer-two devices
 (e.g., Ethernet bridges) that attempt to suppress the forwarding of
 link-layer multicast packets to portions of the layer-two network
 where there are no listeners.  If MLD is used to announce the

Arkko, et al. Informational [Page 9] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 presence of listeners for all IP multicast addresses (including
 link-local multicast addresses), layer 2 devices can snoop MLD
 messages to reliably determine which portions of a network IP
 multicast messages need to be forwarded to.

2.9.1 MLD in 3GPP Networks

 Within 3GPP networks, hosts connect to their default routers (GGSN)
 via point-to-point links.  Moreover, there are exactly two IP devices
 connected to the point-to-point link, and no attempt is made (at the
 link-layer) to suppress the forwarding of multicast traffic.
 Consequently, sending MLD reports for link-local addresses in a 3GPP
 environment may not always be necessary.
 MLD is needed for multicast group knowledge that is not link-local.

2.10 RFC2711 - IPv6 Router Alert Option

 The Router Alert Option [RFC-2711] must be supported, and its use is
 required when MLD is used (see Section 2.9) or when RSVP [RFC-2205]
 is used.

2.11 RFC3041 - Privacy Extensions for Address Configuration in IPv6

 Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
 should be supported.  RFC 3041, and privacy in general, is important
 for the Internet.  Cellular hosts may use the temporary addresses as
 described in RFC 3041.  However, the use of the Privacy Extension in
 an environment where IPv6 addresses are short-lived may not be
 necessary.  At the time this document has been written, there is no
 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 5 for a discussion of the benefits of privacy
 extensions in a 3GPP network.

2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

 The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be
 used.  DHCPv6 is not required for address autoconfiguration when IPv6
 stateless autoconfiguration is used.  However, DHCPv6 may be useful
 for other configuration needs on a cellular host.

Arkko, et al. Informational [Page 10] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

2.13 RFC3484 - Default Address Selection for IPv6

 Default Address Selection [RFC-3484] is needed for cellular hosts.

2.14 DNS

 Cellular hosts should support DNS, as described in [RFC-1034], [RFC-
 1035], [RFC-1886], and [RFC-3152].
 If DNS is used, a cellular host can perform DNS requests in the
 recursive mode, to limit signaling over the air interface.  Both the
 iterative and the recursive approach should be supported, however, as
 the specifications require implementation of the iterative approach,
 and allow the recursive approach as an option.  Furthermore, all DNS
 servers may not support recursive queries, and the security benefits
 of DNS Security cannot always be achieved with them.

3 IP Security

 IPsec [RFC-2401] is a fundamental part of IPv6, and support for AH
 and ESP is described as mandatory in the specifications.
 The first part of this section discusses the applicability of IP
 Security and other security mechanisms for common tasks in cellular
 hosts.  The second part, Sections 3.1 to 3.13, lists the
 specifications related to IPsec and discusses the use of these parts
 of IPsec in a cellular context.
 In general, the need to use a security mechanism depends on the
 intended application for it.  Different security mechanisms are
 useful in different contexts, and have different limitations.  Some
 applications require the use of TLS [RFC-2246], in some situations
 IPsec is used.
 It is not realistic to list all possible services here, and it is
 expected that application protocol specifications have requirements
 on what security services they require.  Note that cellular hosts
 able to download applications must be prepared to offer sufficient
 security services for these applications regardless of the needs of
 the initial set of applications in those hosts.
 The following sections list specifications related to the IPsec
 functionality, and discuss their applicability in a cellular context.
 This discussion focuses on the use of IPsec.  In some applications, a
 different set of protocols may need to be employed.  In particular,
 the below discussion is not relevant for applications that use other
 security services than IPsec.

Arkko, et al. Informational [Page 11] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication

 This specification [RFC-2104] must be supported.  It is referenced by
 RFC 2403 that describes how IPsec protects the integrity of packets.

3.2 RFC2401 - Security Architecture for the Internet Protocol

 This specification [RFC-2401] must be supported.

3.3 RFC2402 - IP Authentication Header

 This specification [RFC-2402] must be supported.

3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH

 This specification [RFC-2403] must be supported.

3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH

 This specification [RFC-2404] must be supported.

3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV

 This specification [RFC-2405] may be supported.  It is, however,
 recommended that stronger algorithms than DES be used.  Algorithms,
 such as AES, are undergoing work in the IPsec working group.  These
 new algorithms are useful, and should be supported as soon as their
 standardization is ready.

3.7 RFC2406 - IP Encapsulating Security Payload (ESP)

 This specification [RFC-2406] must be supported.

3.8 RFC2407 - The Internet IP Security DoI for ISAKMP

 Automatic key management, [RFC-2408] and [RFC-2409], is not a
 mandatory part of the IP Security Architecture.  Note, however, that
 in the cellular environment the IP addresses of a host may change
 dynamically.  For this reason the use of manually configured Security
 Associations is not practical, as the newest host address would have
 to be updated to the SA database of the peer as well.
 Even so, it is not clear that all applications would use IKE for key
 management.  For instance, hosts may use IPsec ESP [RFC-2406] for
 protecting SIP signaling in the IMS [3GPP-ACC] but provide
 authentication and key management through another mechanism such as
 UMTS AKA (Authentication and Key Agreement) [UMTS-AKA].

Arkko, et al. Informational [Page 12] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 It is likely that several simplifying assumptions can be made in the
 cellular environment, with respect to the mandated parts of the IP
 Security DoI, ISAKMP, and IKE.  Work on such simplifications would be
 useful, but is outside the scope of this document.

3.9 RFC2408 - The Internet Security Association and Key Management

            Protocol
 This specification [RFC-2408] is optional according to the IPv6
 specifications, but may be necessary in some applications, as
 described in Section 3.8.

3.10 RFC2409 - The Internet Key Exchange (IKE)

 This specification [RFC-2409] is optional according to the IPv6
 specifications, but may be necessary in some applications, as
 described in Section 3.8.
 Interactions with the ICMPv6 packets and IPsec policies may cause
 unexpected behavior for IKE-based SA negotiation unless some special
 handling is performed in the implementations.
 The ICMPv6 protocol provides many functions, which in IPv4 were
 either non-existent or provided by lower layers.  For instance, IPv6
 implements address resolution using an IP packet, ICMPv6 Neighbor
 Solicitation message.  In contrast, IPv4 uses an ARP message at a
 lower layer.
 The IPsec architecture has a Security Policy Database that specifies
 which traffic is protected, and how.  It turns out that the
 specification of policies in the presence of ICMPv6 traffic is not
 easy.  For instance, a simple policy of protecting all traffic
 between two hosts on the same network would trap even address
 resolution messages, leading to a situation where IKE can't establish
 a Security Association since in order to send the IKE UDP packets one
 would have had to send the Neighbor Solicitation Message, which would
 have required an SA.
 In order to avoid this problem, Neighbor Solicitation, Neighbor
 Advertisement, Router Solicitation, and Router Advertisement messages
 must not lead to the use of IKE-based SA negotiation.  The Redirect
 message should not lead to the use of IKE-based SA negotiation.
 Other ICMPv6 messages may use IKE-based SA negotiation as is desired
 in the Security Policy Data Base.
 Note that the above limits the usefulness of IPsec in protecting all
 ICMPv6 communications.  For instance, it may not be possible to
 protect the ICMPv6 traffic between a cellular host and its next hop

Arkko, et al. Informational [Page 13] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 router.  (Which may be hard in any case due to the need to establish
 a suitable public key infrastructure.  Since roaming is allowed, this
 infrastructure would have to authenticate all hosts to all routers.)

3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec

 This specification [RFC-2410] must be supported.

3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms

 This specification [RFC-2451] must be supported if encryption
 algorithms other than DES are implemented, e.g., CAST-128, RC5, IDEA,
 Blowfish, 3DES.

4. Mobility

 For the purposes of this document, IP mobility is not relevant.  When
 Mobile IPv6 specification is approved, a future update to this
 document may address these issues, as there may be some effects on
 all IPv6 hosts due to Mobile IP.  The movement of cellular hosts
 within 3GPP networks is handled by link layer mechanisms.

5. Security Considerations

 This document does not specify any new protocols or functionality,
 and as such, it does not introduce any new security vulnerabilities.
 However, specific profiles of IPv6 functionality are proposed for
 different situations, and vulnerabilities may open or close depending
 on which functionality is included and what is not.  There are also
 aspects of the cellular environment that make certain types of
 vulnerabilities more severe.  The following issues are discussed:
  1. The suggested limitations (Section 2.3) in the processing of

routing headers limits also exposure to DoS attacks through

   cellular hosts.
  1. IPv6 addressing privacy [RFC3041] may be used in cellular hosts.

However, it should be noted that in the 3GPP model, the network

   would assign new addresses, in most cases, to hosts in roaming
   situations and typically, also when the cellular hosts activate a
   PDP context.  This means that 3GPP networks will already provide a
   limited form of addressing privacy, and no global tracking of a
   single host is possible through its address.  On the other hand,
   since a GGSN's coverage area is expected to be very large when
   compared to currently deployed default routers (no handovers
   between GGSNs are possible), a cellular host can keep an address
   for a long time.  Hence, IPv6 addressing privacy can be used for
   additional privacy during the time the host is on and in the same

Arkko, et al. Informational [Page 14] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

   area.  The privacy features can also be used to e.g., make
   different transport sessions appear to come from different IP
   addresses.  However, it is not clear that these additional efforts
   confuse potential observers any further, as they could monitor only
   the network prefix part.
  1. The use of various security services such as IPsec or TLS in the

connection of typical applications in cellular hosts is discussed

   in Section 3 and recommendations are given there.
  1. Section 3 also discusses under what conditions it is possible to

provide IPsec protection of e.g., ICMPv6 communications.

  1. The airtime used by cellular hosts is expensive. In some cases,

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
   users that the airtime is used correctly and no extra charges are
   applied to users due to misbehaving third parties.  The cellular
   links also have a limited capacity, which means that they may not
   necessarily be able to accommodate more traffic than what the user
   selected, such as a multimedia call.  Additional traffic might
   interfere with the service level experienced by the user.  While
   Quality of Service mechanisms mitigate these problems to an extent,
   it is still apparent that DoS aspects may be highlighted in the
   cellular environment.  It is possible for existing DoS attacks that
   use for instance packet amplification to be substantially more
   damaging in this environment.  How these attacks can be protected
   against is still an area of further study.  It is also often easy
   to fill the cellular link and queues on both sides with additional
   or large packets.
  1. Within some service provider networks, it is possible to buy a

prepaid cellular subscription without presenting personal

   identification.  Attackers that wish to remain unidentified could
   leverage this.  Note that while the user hasn't been identified,
   the equipment still is; the operators can follow the identity of
   the device and block it from further use.  The operators must have
   procedures in place to take notice of third party complaints
   regarding the use of their customers' devices.  It may also be
   necessary for the operators to have attack detection tools that
   enable them to efficiently detect attacks launched from the
   cellular hosts.
  1. Cellular devices that have local network interfaces (such as IrDA

or Bluetooth) may be used to launch attacks through them, unless

   the local interfaces are secured in an appropriate manner.
   Therefore, local network interfaces should have access control to
   prevent others from using the cellular host as an intermediary.

Arkko, et al. Informational [Page 15] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

6. References

6.1. Normative

 [RFC-1035]  Mockapetris, P., "Domain names - implementation and
             specification", STD 13, RFC 1035, November 1987.
 [RFC-1886]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
             version 6, RFC 1886, December 1995.
 [RFC-1981]  McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery
             for IP version 6", RFC 1981, August 1996.
 [RFC-2026]  Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.
 [RFC-2104]  Krawczyk, K., Bellare, M. and R. Canetti, "HMAC:  Keyed-
             Hashing for Message Authentication", RFC 2104, February
             1997.
 [RFC-2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
             RFC 2246, January 1999.
 [RFC-2401]  Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.
 [RFC-2402]  Kent, S. and R. Atkinson,  "IP Authentication Header",
             RFC 2402, November 1998.
 [RFC-2403]  Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP
             and AH", RFC 2403, November 1998.
 [RFC-2404]  Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within
             ESP and AH", RFC 2404, November 1998.
 [RFC-2405]  Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
             Algorithm With Explicit IV", RFC 2405, November 1998.
 [RFC-2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
             Protocol (ESP)", RFC 2406, November 1998.
 [RFC-2407]  Piper, D., "The Internet IP Security Domain of
             Interpretation for ISAKMP", RFC 2407, November 1998.
 [RFC-2408]  Maughan, D., Schertler, M., Schneider, M., and J. Turner,
             "Internet Security Association and Key Management
             Protocol (ISAKMP)", RFC 2408, November 1998.

Arkko, et al. Informational [Page 16] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 [RFC-2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.
 [RFC-2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
             Its Use With IPsec", RFC 2410, November 1998.
 [RFC-2451]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
             Algorithms", RFC 2451, November 1998.
 [RFC-2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.
 [RFC-2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
             Discovery for IP Version 6 (IPv6)", RFC 2461, December
             1998.
 [RFC-2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
             Autoconfiguration", RFC 2462, December 1998.
 [RFC-2463]  Conta, A. and S. Deering, "ICMP for the Internet Protocol
             Version 6 (IPv6)", RFC 2463, December 1998.
 [RFC-2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
             IPv6 Specification", RFC 2473, December 1998.
 [RFC-2710]  Deering, S., Fenner, W. and B. Haberman, "Multicast
             Listener Discovery (MLD) for IPv6", RFC 2710, October
             1999.
 [RFC-2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
             RFC 2711, October 1999.
 [RFC-2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
             IPv6 Address Aggregation and Renumbering", RFC 2874, July
             2000.
 [RFC-3041]  Narten, T. and R. Draves, "Privacy Extensions for
             Stateless Address Autoconfiguration in IPv6", RFC 3041,
             January 2001.
 [RFC-3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
             August 2001.
 [RFC-3155]  Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N.
             Vaidya, "End-to-end Performance Implications of Links
             with Errors", BCP 50, RFC 3155, August 2001.

Arkko, et al. Informational [Page 17] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

 [RFC-3484]  Draves, R., "Default Address Selection for Internet
             Protocol version 6 (IPv6)", RFC 3484, February 2003.
 [RFC-3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
             (IPv6) Addressing Architecture", RFC 3513, April 2003.

6.2. Informative

 [3GPP-ACC]  3GPP Technical Specification 3GPP TS 33.203, "Technical
             Specification Group Services and System Aspects; 3G
             Security; Access security for IP-based services (Release
             5)", 3rd Generation Partnership Project, March 2002.
 [3GPP-IMS]  3rd Generation Partnership Project; Technical
             Specification Group Services and System Aspects; IP
             Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228)
 [3GPP-IPv6] 3rd Generation Partnership Project; Technical
             Specification Group Services and System Aspects
             "Architectural requirements" (TS 23.221)
 [DHCPv6]    Bound, J., et al., "Dynamic Host Configuration Protocol
             for IPv6 (DHCPv6)", Work in progress.
 [RFC-1034]  Mockapetris, P., "Domain names - concepts and
             facilities", STD 13, RFC 1034, November 1987.
 [RFC-2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over
             IPv4 Domains without Explicit Tunnels", RFC 2529, March
             1999.
 [RFC-2205]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
             Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
             Functional Specification", RFC 2205, September 1997.
 [RFC-3314]  Wasserman, M., Editor, "Recommendations for IPv6 in Third
             Generation Partnership Project (3GPP) Standards, RFC
             3314, September 2002.
 [RFC-3481]  Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and
             F. Khafizov, "TCP over Second (2.5G) and Third (3G)
             Generation Wireless Networks", BCP 71, RFC 3481, February
             2003.
 [UMTS-AKA]  3GPP Technical Specification 3GPP TS 33.102, "Technical
             Specification Group Services and System Aspects; 3G
             Security; Security Architecture (Release 4)", 3rd
             Generation Partnership Project, December 2001.

Arkko, et al. Informational [Page 18] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

7. Contributors

 This document is based on the results of a team that included Peter
 Hedman and Pertti Suomela in addition to the authors.  Peter and
 Pertti have contributed both text and their IPv6 experience to this
 document.

8. Acknowledgements

 The authors would like to thank Jim Bound, Brian Carpenter, Steve
 Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark,
 Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing
 list for their comments and input.
 We would also like to thank David DeCamp, Karim El Malki, Markus
 Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and
 Shabnam Sultana for their comments and input in preparation of this
 document.

Arkko, et al. Informational [Page 19] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model

 The appendix aims to very briefly describe the 3GPP IPv6 addressing
 model for 2G (GPRS) and 3G (UMTS) cellular networks from Release 99
 onwards.  More information can be found from 3GPP Technical
 Specification 23.060.
 There are two possibilities to allocate the address for an IPv6 node:
 stateless and stateful autoconfiguration.  The stateful address
 allocation mechanism needs a DHCP server to allocate the address for
 the IPv6 node.  On the other hand, the stateless autoconfiguration
 procedure does not need any external entity involved in the address
 autoconfiguration (apart from the GGSN).
 In order to support the standard IPv6 stateless address
 autoconfiguration mechanism, as recommended by the IETF, the GGSN
 shall assign a prefix that is unique within its scope to each primary
 PDP context that uses IPv6 stateless address autoconfiguration.  This
 avoids the necessity to perform Duplicate Address Detection at the
 network level for every address built by the mobile host.  The GGSN
 always provides an Interface Identifier to the mobile host.  The
 Mobile host uses the interface identifier provided by the GGSN to
 generate its link-local address.  The GGSN provides the cellular host
 with the interface identifier, usually in a random manner.  It must
 ensure the uniqueness of such identifier on the link (i.e., no
 collisions between its own link-local address and the cellular
 host's).
 In addition, the GGSN will not use any of the prefixes assigned to
 cellular hosts to generate any of its own addresses.  This use of the
 interface identifier, combined with the fact that each PDP context is
 allocated a unique prefix, will eliminate the need for DAD messages
 over the air interface, and consequently allows an efficient use of
 bandwidth.  Furthermore, the allocation of a prefix to each PDP
 context will allow hosts to implement the privacy extensions in RFC
 3041 without the need for further DAD messages.

Arkko, et al. Informational [Page 20] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

Authors' Addresses

 Jari Arkko
 Ericsson
 02420 Jorvas
 Finland
 EMail: jari.arkko@ericsson.com
 Gerben Kuijpers
 Ericsson
 Skanderborgvej 232
 DK-8260 Viby J
 Denmark
 EMail: gerben.a.kuijpers@ted.ericsson.se
 John Loughney
 Nokia Research Center
 Itamerenkatu 11 - 13
 FIN-00180 HELSINKI
 Finland
 EMail: john.loughney@nokia.com
 Hesham Soliman
 Ericsson Radio Systems AB
 Torshamnsgatan 23, Kista, Stockholm
 Sweden
 EMail: hesham.soliman@era.ericsson.se
 Juha Wiljakka
 Nokia Mobile Phones
 Sinitaival 5
 FIN-33720 TAMPERE
 Finland
 EMail: juha.wiljakka@nokia.com

Arkko, et al. Informational [Page 21] RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003

Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Arkko, et al. Informational [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3316.txt · Last modified: 2003/04/30 16:15 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki