idnits 2.17.1 draft-manyfolks-ipv6-cellular-host-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 110 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 455 has weird spacing: '...plified when...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3041' is mentioned on line 804, but not defined ** Obsolete undefined reference: RFC 3041 (Obsoleted by RFC 4941) == Unused Reference: '3GPP-IMS' is defined on line 881, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3GPPADDR' -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-IMS' ** Obsolete normative reference: RFC 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2462 (ref. 'ADDRCONF') (Obsoleted by RFC 4862) == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-ciph-aes-cbc-01 -- No information found for draft-ietf-ipngwg-default-addr-select - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DEFADDR' == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-19 -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HMIPv6' == Outdated reference: A later version (-02) exists of draft-arkko-icmpv6-ike-effects-00 -- Possible downref: Normative reference to a draft: ref. 'ICMPIKEv6' ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2472 (ref. 'IPv6PPP') (Obsoleted by RFC 5072, RFC 5172) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MIPv6-FH' ** Obsolete normative reference: RFC 1981 (ref. 'PMTU') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Downref: Normative reference to an Historic RFC: RFC 2874 ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) -- No information found for draft-ietf-pilc-2 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TCPWIRELESS' -- Duplicate reference: RFC2893, mentioned in 'TRANSMECH', was also mentioned in 'RFC-2893'. ** Obsolete normative reference: RFC 2893 (ref. 'TRANSMECH') (Obsoleted by RFC 4213) Summary: 27 errors (**), 0 flaws (~~), 11 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jari Arkko 2 Internet Engineering Task Force Peter Hedman 3 Issued: September 21, 2001 Gerben Kuijpers 4 Expires: March 21, 2002 Ericsson 5 John Loughney 6 Pertti Suomela 7 Juha Wiljakka 8 Nokia 10 Minimum IPv6 Functionality for a Cellular Host 11 13 Status of This Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as 'work in progress.' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 As an increasing number of cellular hosts are being connected to the 37 Internet, IPv6 becomes necessary. Examples of such hosts are GPRS, 38 UMTS, and CDMA2000 terminals. Standardization organizations are also 39 making IPv6 mandatory in their newest specifications, such as the IP 40 multimedia terminals specified for UMTS. However, the concept of 41 IPv6 covers many aspects, numerous RFCs, a number of different 42 situations, and is also partly still evolving. A rapid adoption of 43 IPv6 is desired for cellular hosts. Yet these terminals vary greatly 44 in terms of their processing capabilities and task orientation. 45 Cellular host software often cannot be upgraded, yet it must meet 46 tough demands for interoperability with other hosts, the cellular 47 network, and the Internet. For these reasons it is necessary to 48 understand how the IPv6 deployment starts and which parts of IPv6 49 are necessary under which situations. This document suggests basic 50 IPv6 functionality for cellular hosts, and discusses when parts of 51 the functionality is needed, and under which conditions. 53 Abstract ............................................................1 54 1 Introduction ......................................................4 55 1.1 Abbreviations ..................................................6 56 1.2 Requirement Language ...........................................6 57 1.3 Cellular Host IPv6 Features ....................................6 58 2 Core IP ...........................................................6 59 2.1 RFC1981 - Path MTU Discovery for IP Version 6 ..................7 60 2.2 RFC2373 - IP Version 6 Addressing Architecture .................7 61 2.3 RFC2374 - IPv6 Aggregatable Global Unicast Address Format ......7 62 2.4 RFC2460 - Internet Protocol Version 6 ..........................7 63 2.5 RFC2461 - Neighbor Discovery for IPv6 ..........................8 64 2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration .............8 65 2.7 RFC2463 - Internet Control Message Protocol for the IPv6 .......9 66 2.8 RFC2472 - IP version 6 over PPP ................................9 67 2.9 RFC2473 - Generic Packet Tunneling in IPv6 Specification .......9 68 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 .........9 69 2.11 RFC2711 - IPv6 Router Alert Option ............................9 70 2.12 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers ....9 71 2.13 RFC3041 - Privacy Extensions for Stateless AA in IPv6 ........10 72 2.14 RFC3056 - Connection of IPv6 Domains Via IPv4 Clouds .........10 73 2.15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ........10 74 2.16 Default Address Selection for IPv6 ...........................10 75 2.17 DNS ..........................................................11 76 2.18 Security Issues ..............................................11 77 3 IP Security ......................................................11 78 3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication ......13 79 3.2 RFC2401 - Security Architecture for the Internet Protocol .....13 80 3.3 RFC2402 - IP Authentication Header ............................13 81 3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH ............13 82 3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH ............13 83 3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV ...14 84 3.7 RFC2406 - IP Encapsulating Security Payload (ESP) .............14 85 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP .............14 86 3.9 RFC2408 - ISA and Key Management Protocol .....................14 87 3.10 RFC2409 - The Internet Key Exchange (IKE) ....................14 88 3.11 RFC2410 - The NULL Encryption Algorithm and its Use With IPsec14 89 3.12 RFC2411 - IP Security Document Roadmap .......................14 90 3.13 RFC2451 - The ESP CBC-Mode Cipher Algorithms .................15 91 3.14 IP Security Remote Access ....................................15 92 3.15 The AES Cipher Algorithm and Its Use With IPsec ..............15 93 3.16 ICMPv6 and Its Effect to IKE and IPsec Policies ..............15 94 4 IP Mobility ......................................................15 95 4.1 Mobility Support in IPv6 ......................................15 96 4.2 Fast Handovers for Mobile IPv6 ................................16 97 4.3 Hierarchical MIPv6 Mobility Management ........................17 98 4.4 Mobile IP Security ............................................17 99 5 Security Considerations ..........................................17 100 6 References .......................................................19 101 7 Acknowledgements .................................................22 102 8 Authors' Addresses ...............................................22 103 Appendix A Cellular Host IPv6 Addressing in the 3GPP Model .........23 104 Appendix B Transition Issues .......................................25 106 1 Introduction 108 Technologies such as GPRS (General Packet Radio Service), UMTS 109 (Universal Mobile Telecommunications System), and CDMA2000 are 110 making it possible for cellular hosts to have an always-on 111 connection to the Internet. IPv6 becomes necessary, as it is 112 expected that the number of such cellular hosts will increase 113 rapidly. Standardization organizations working with cellular 114 technologies have recognized this, and are making IPv6 mandatory in 115 their newest specifications. One example of this is that 3GPP 116 specifies IPv6 support as mandatory for future UMTS IP multimedia 117 terminals. 119 The purpose of this draft is to propose a compact set of IPv6 120 specifications and functionality that cellular hosts must support. 121 Such a specification is necessary in order to determine the optimal 122 way to use IPv6 in a cellular environment. Important considerations 123 are how to minimize footprint and implementation effort for a large 124 number of consumer terminals, eliminate unnecessary user confusion 125 with regards to configuration options, ensure interoperability and 126 to provide an easy reference for those implementing IPv6 in a 127 cellular host. The overarching desire is to ensure that cellular 128 hosts are good citizens on the Internet. 130 The main audiences of this document are the implementors who need 131 guidance on what to implement, the IETF that wants to ensure a well- 132 working global IPv6 network, and other standardization organizations 133 that need a reference to how IPv6 can be mandated on their 134 standards. 136 For the purposes of this document, a cellular host is considered to 137 be a terminal which uses a cellular air interface (i.e. GPRS, UMTS, 138 CDMA2000) to connect to a cellular access network in order to 139 provide IPv6 connectivity to an IP network. The functionality to 140 provide this connectivity is outlined in this draft. The description 141 is made from a general cellular host point of view, and this 142 document is intended to be applicable for many types of cellular 143 network standards (or even multi-standard devices). In some cases 144 known exceptions and special cases are however documented for 145 specific cellular networks such as the UMTS, as examples and 146 additional information for the reader. 148 Parts of this document may also be applicable in other, non-cellular 149 contexts, such as small IPv6 appliances with similar size and cost 150 restrictions. The scope of thisdocument, however, is the cellular 151 hosts and it may not cover all issues relevant in those other 152 contexts. 154 The use of IPv6 within cellular networks implies an implementation 155 of the IPv6 stack within a wide range of terminals. Such terminals 156 may vary significantly in terms of capacity, task orientation and 157 processing power. For instance, the smallest handheld terminals can 158 have a very limited amount of memory, computational power, and 159 battery capacity. Cellular hosts operate over low bandwidth wireless 160 links with limited throughput. As such, there are certain 161 optimizations that would be required for these hosts in order to fit 162 the largest possible amount of terminals within an area of spectrum. 164 Tough demands are set for interoperability of cellular hosts towards 165 other hosts, the cellular network, and the Internet. It is often 166 hard or impossible to upgrade a large number of cellular hosts to a 167 new software version. The long lifetime of the terminals sets a 168 requirement for old equipment to still work in newer versions of the 169 network and other hosts. 171 The concept of IPv6 covers many aspects, numerous RFCs, a number of 172 different situations, and is also partly still in evolution. For 173 these reasons it is necessary to understand how the IPv6 deployment 174 starts and which parts of IPv6 are necessary under which situations. 175 This document reviews the IPv6 functionality, grouped under three 176 categories: core IP, security, and mobility. For each category and 177 each RFC in them, we discuss the following: 179 - Is this part of functionality needed by cellular hosts and under 180 which conditions? 181 - In some cases individual parts of the RFCs are discussed in more 182 detail and recommendations are given regarding their support. 183 - In some other cases conflicts between some parts of 184 functionality and the current cellular network protocols are 185 identified. 187 The aim of this work is to introduce a minimal set of IPv6 188 functionality _ subject to the particular type of terminal and 189 application _ that would be required for cellular IPv6 hosts. As a 190 general guideline, a cellular host should not appear any different 191 from other IPv6 hosts. The set of requirements proposed should be 192 suited to terminals with minimal capabilities, low cost and 193 processing power. Interoperability can be achieved by listing needed 194 IPv6 related IETF specifications according to chapter 1.2. 196 The scope of the discussion in this document is the IPv6 197 functionality. The reader should be advised that other work exists 198 for various other layers, which is not IPv6 specific such as the 199 header compression work done in the IETF ROHC group, or the TCP work 200 in [TCPWIRELESS]. 202 The authors of this document seek feedback to ensure that the 203 proposed functionality set is consistent, interoperable with the 204 rest of the IPv6 Internet, complete, and does not open new security 205 risks. 207 1.1 Abbreviations 209 3GPP Third Generation Partnership Project 210 AH Authentication Header 211 CDMA2000 Code Division Multiple Access 2000, the name identifying 212 the third generation technology of IS-95 CDMA standard 213 and ANSI-41 network. 214 ESP Encapsulating Security Payload 215 GGSN Gateway GPRS Support Node 216 GPRS General Packet Radio Service 217 IKE Internet Key Exchange 218 ISAKMP Internet Security Association and Key Management 219 Protocol 220 MTU Maximum Transmission Unit 221 SGSN Serving GPRS Support Node 222 UMTS Universal Mobile Telecommunications System 223 WLAN Wireless LAN 225 1.2 Requirement Language 227 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 228 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 229 document, are to be interpreted as described in [KEYWORDS]. 231 1.3 Cellular Host IPv6 Features 233 This specification defines IPv6 features for cellular hosts in three 234 groups. 236 Core IP 238 In this group we describe the core parts of IPv6. Only RFCs 239 needed in all situations and under all conditions are in this 240 group. 242 IP Security 244 In this group we discuss the IP layer security functionality 245 suitable for cellular hosts. Chapter 3 defines the contents 246 of this group, and discusses its usage in different contexts. 248 IP Mobility 250 In this group we discuss IP layer mobility functionality for 251 cellular hosts. Basic functionality needed just to correspond 252 with mobile nodes is a part of the Core IP group. Chapter 4 253 defines the contents of the IP Mobility group, and discusses 254 its usage in different contexts. 256 2 Core IP 257 This section describes the minimum needed IPv6 functionality of a 258 cellular host in order to be able to communicate with other IPv6 259 hosts. 261 2.1 RFC1981 - Path MTU Discovery for IP Version 6 263 Path MTU Discovery [PMTU] MAY be supported. 265 The IPv6 specification [IPv6] states in chapter 5 that "a minimal 266 IPv6 implementation (e.g., in a boot ROM) may simply restrict itself 267 to sending packets no larger than 1280 octets, and omit 268 implementation of Path MTU Discovery." 270 If Path MTU Discovery is not implemented then the uplink packet size 271 MUST be limited to 1280 octets (standard limit in [IPv6]). However, 272 the cellular host MUST be able to receive packets with size up to 273 the link MTU before reassembly. 275 2.2 RFC2373 - IP Version 6 Addressing Architecture 277 The IPv6 Addressing Architecture [ADDRARCH] MUST be supported. IPX & 278 NSAP addresses SHOULD NOT be used. 280 2.3 RFC2374 - IPv6 Aggregatable Global Unicast Address Format 282 The IPv6 Aggregatable Global Unicast Address Format is described in 283 [RFC-2374]. This RFC MUST be supported. 285 2.4 RFC2460 - Internet Protocol Version 6 287 The Internet Protocol Version 6 is specified in [IPv6]. This RFC 288 MUST be supported. 290 The cellular host is assumed to act as a host, not a router. 291 Implementation requirements for a cellular router are not defined in 292 this document. 294 The cellular host MUST implement all non-router packet receive 295 processing as described in RFC 2460. This includes the generation 296 of ICMPv6 error reports, and at least minimal processing of each 297 extension header: 299 - Hop-by-Hop Options header: at least the Pad1 and PadN options 300 - Destination Options header: at least the Pad1, PadN and Home 301 Address options 302 - Routing (Type 0) header: final destination (host) processing 303 only 304 - Fragment header 305 - AH and ESP headers: In the case of the Core IP functionality 306 only, AH and ESP headers are treated as if the Security 307 Association had not existed, i.e. - packets with these headers 308 are dropped. When the IP Security functionality is in use, they 309 are processed as specified in RFCs 2401, 2402, and 2406. 310 - The No Next Header value 312 Unrecognized options in Hop-by-Hop Options or Destination Options 313 extensions must be processed as described in RFC 2460. 315 The cellular host must follow the packet transmission rules in RFC 316 2460. A cellular host implementing the Core IP functionality will 317 typically send packets containing either no extension headers or the 318 Fragment header. However, a cellular host MAY generate any of the 319 extension headers. 321 Cellular Hosts will act as the destination when processing the 322 Routing Header. This will also ensure that the cellular hosts will 323 not be inappropriately used as relays or components in Denial-of- 324 Service attacks. Acting as the destination involves the following. 325 The cellular hosts MUST check the Segments Left field in the header, 326 and proceed if it is zero or one and the next address is one of the 327 terminal's addresses. If not, however, the terminal MUST implement 328 error checks as specified in section 4.4 of RFC 2460. Under the 329 simplifying assumptions, there is no need for the terminal to send 330 Routing Headers. 332 2.5 RFC2461 - Neighbor Discovery for IPv6 334 Neighbor Discovery is described in [RFC-2461] and, in general, MUST 335 be supported. 337 In cellular networks, some Neighbor Discovery messages can cause 338 unnecessary traffic and consume valuable (limited) bandwidth. If a 339 cellular link resembles a point-to-point link, a mobile terminal may 340 only have its default routers as neighbors. Therefore, in this 341 situation, Neighbor Solicitation and Advertisement messages MAY be 342 implemented. If a cellular host does not have a MAC address on its 343 cellular interface, the link layer suboption SHOULD NOT be 344 implemented for this interface. It is for further study to study in 345 which direction this is applicable. 347 2.5.1 Neighbor Discovery in 3GPP 349 3GPP terminals only need to support Router Solicitations and Router 350 Advertisements for 3GPP IPv6 Stateless Address Autoconfiguration. 351 See appendix A for more details. Neighbor Sollicitations and 352 Advertisements may be supported for Neighbor Unreachability 353 Detection. They are not needed for 3GPP IPv6 Stateless Address 354 Autoconfiguration, since Duplicate Address Detection is not needed 355 in this address assignment mechanism. 357 2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration 358 IPv6 Stateless Address Autoconfiguration [ADDRCONF] MAY be 359 supported. It is recommended not to perform the Duplicate Address 360 Detection if the IPv6 address (suffix) uniqueness is taken care of 361 by a network element (on the same link). It will avoid unnecessary 362 (valuable) bandwidth consumption in the cellular environment. 364 2.6.1 Stateless Address Autoconfiguration in 3GPP 366 A 3GPP Cellular host MUST be able to process a Router Advertisement 367 as stated in chapter 5.5.3 of [ADDRCONF]. However, a cellular host 368 in a 3GPP Architecture does not generate its own IPv6 address 369 (suffix), therefore Duplicate Address Detection is not needed. 370 See appendix A for more details on 3GPP IPv6 Stateless Address 371 Autoconfiguration. 373 2.7 RFC2463 - Internet Control Message Protocol for the IPv6 375 The Internet Control Message Protocol for the IPv6 [ICMPv6] MUST be 376 supported. 378 As per RFC 2463 section 2, ICMPv6 requirements MUST be fully 379 implemented by every IPv6 node. However, references to the use of IP 380 Security (sections 5.1 and 5.2) are not relevant for Core IP 381 features. 383 2.8 RFC2472 - IP version 6 over PPP 385 IPv6 over PPP [IPv6PPP] MUST be supported for cellular hosts that 386 implement PPP. 388 2.9 RFC2473 - Generic Packet Tunneling in IPv6 Specification 390 Generic Packet Tunneling [RFC-2473] MAY be supported if needed for 391 transition mechanisms and MUST be supported if the Mobile Node 392 functionality of Mobile IP is implemented, as specified in chapter 393 4. 395 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 397 Multicast Listener Discovery [MLD] SHOULD be supported if the 398 cellular host supports multicast functionality. 400 2.11 RFC2711 - IPv6 Router Alert Option 402 The Router Alert Option [RFC-2711] MAY be supported. Since the 403 cellular host will not function as a router, the receiver side of 404 the Router Alert Option can be omitted even in case the Router Alert 405 Option is supported. 407 2.12 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers 408 Transition mechanisms [TRANSMECH] MAY be supported. See Appendix B 409 for more details. 411 2.13 RFC3041 - Privacy Extensions for Stateless AA in IPv6 413 Privacy Extensions for Stateless Address Autoconfiguration [RFC- 414 3041] MAY be supported. 416 2.13.1 Privacy Extensions for Stateless AA in 3GPP 418 The Privacy Extensions for Stateless Autoconfiguration RFC [RFC- 419 3041] is incompatible with the 3GPP model and MUST NOT be supported 420 if the 3GPP IPv6 Stateless Address Autoconfiguration is used. 3GPP 421 IPv6 Stateless Address Autoconfiguration uses Neigbor Discovery 422 messages, but the host is not allowed to propose its own interface 423 identifier. The network provides the complete IPv6 address to the 424 3GPP host. A host implementing Privacy Extensions for Stateless 425 Autoconfiguration will periodically change its interface identifier. 426 Depending on the specific implementation of the 3GPP network, the 427 packets originated from and destined for the new address will most 428 likely be dropped. See Appendix A for more details on 3GPP IPv6 429 address assignment and Chapter 5 for the security implications of 430 this. 432 2.14 RFC3056 - Connection of IPv6 Domains Via IPv4 Clouds 434 Connection of IPv6 domains via IPv4 clouds [RFC-3056] MAY be 435 supported. 437 For a cellular host, this specification would mean capability to 438 create 6to4 tunnels starting from the cellular host itself. In a 439 cellular environment, tunneling over the air interface should be 440 minimized. Hence, 6to4 tunneling SHOULD be carried out by 441 intermediate 6to4 routers rather than the cellular host. 443 2.15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 445 Dynamic Host Configuration Protocol for IPv6 [DHCPv6] MAY be 446 supported. 448 It is possible for the DHCP client to be implemented on the cellular 449 host. 451 2.16 Default Address Selection for IPv6 453 Default Address Selection for IPv6 [DEFADDR] SHOULD be supported 454 since cellular hosts can have more than one IPv6 address.However, 455 note that the rules in [DEFADDR] can be greatly simplified when 456 cellular hosts do not implement the optional policy table, and/or 457 have just one global IPv6 address. 459 2.17 DNS 461 Some networks may provide DNS-proxy service for simple cellular 462 hosts. Therefore, generally, DNS MAY be supported. 464 2.17.1 RFC1034 - Domain Names _ Concepts and Facilities 466 The concepts and facilities of domain names are specified in [RFC- 467 1034]. This RFC MUST be supported for cellular hosts which support 468 DNS. 470 2.17.2 RFC1035 - Domain Names _ Implementation and Specification 472 The implementation and specification are described in [RFC-1035]. 473 This RFC MUST be supported for cellular hosts which support DNS. 475 2.17.3 RFC1886 - DNS Extension to support IP version 6 477 DNS Extension for IPv6 [RFC-1886] MUST be supported for cellular 478 hosts which support DNS. 480 2.17.4 RFC2874 - DNS Extensions to Support IPv6 Address Aggregation and 481 Renumbering 483 DNS Extensions to Support IPv6 Address Aggregation and Renumbering 484 [RFC-2874] MAY be supported. A6 can cause problems for cellular 485 hosts operating over wireless links since several round trips may be 486 needed to collect a complete DNS record, when a DNS resolver is 487 implemented on a cellular host. 489 2.18 Security Issues 491 Chapter 3 describes where IP Security [RFC-2401] should or should 492 not be used. Nevertheless, even if a particular terminal does not 493 support IP Security, it MUST be able to refuse IKE [RFC-2409] 494 connection attempts. The purpose of this is to provide a clean 495 indication to the other host that this particular host is not 496 willing to provide security associations. 498 It is for further study whether IKE response messages are needed for 499 the clean indication or if ICMP port unreachable reports are 500 sufficient. 502 3 IP Security 504 The use of IP Security [RFC-2401] or other security services in 505 cellular hosts depends on their intended use. The following services 506 are discussed here: 508 - VPN service to a corporate intranet 509 - Web browsing service 510 - IP Multimedia Service as defined by 3GPP 511 - Mobility service as defined by Mobile IP 512 - Protection of IPv6 infrastructure communications in the local 513 network 515 Recommendations are given on what security solution to employ in 516 these situations, though in some cases work by other bodies or 517 working groups hasn't progressed far enough to state the solution 518 yet. It is however strongly suggested that some of the existing set 519 of security mechanisms be used rather than new ones developed, 520 adding to the amount of memory and implementation effort needed for 521 a host supporting multiple services. 523 Cellular hosts that provide a VPN service to a corporate intranet, 524 for example, or to a transition tunneling gateway MUST support IPsec 525 and IKE. This security set is defined in this chapter. For this 526 purpose an IPsec Remote Access solution SHOULD also be supported. 528 Cellular hosts that provide only a simple web browsing service 529 SHOULD provide SSL or TLS [RFC-2246]. The use of security in a web 530 browser is seen in most cases as necessary, as otherwise the user 531 would be blocked from some of the sites - such as e-commerce sites - 532 that do require security. The fact that just SSL/TLS should be the 533 protocol to provide web security relates to current deployment and 534 the suitability of the single-side certificate trust model for this 535 application. 537 It is likely that no end-to-end security will be mandated for the 538 multimedia streams themselves in the first releases of the 3GPP IMS 539 service specifications. However, it is necessary to provide security 540 for the signaling parts. The 3GPP SA3 group is currently evaluating 541 the use of IPsec, S/MIME/CMS-based approaches, and other techniques. 542 When this work completes, more can be said about the mandated 543 security services for the IMS. 545 Hosts supporting mobility services [MIPv6], will need a security 546 solution which is also currently under development in the IETF. 548 The use of IPsec, IKE, or other security services directly in the 549 underlying IPv6 infrastructure communications (e.g. ICMPv6 or 550 Neighbor Discovery) can also be discussed. The use of IPsec towards 551 a specific home server in the context of a VPN service is easy. 552 However, the use of any security service within the context of local 553 next hop routers (GGSNs) or other 3GPP nodes seems hard due to the 554 difficulties in establishing a suitable trust infrastructure for 555 creating the necessary Security Associations (SAs). In order for a 556 terminal to create an SA with the next hop router for the purposes 557 of securing the router and neighbor discovery tasks would mean the 558 following. First, both the routers and all cellular hosts would have 559 to be registered to a PKI system. Second, a common root CA would 560 have to be found that encompasses both the visiting cellular host of 561 an operator as well as the infrastructure of another operator. It is 562 not clear if this is possible with today's technology. 564 Furthermore, as [ICMPIKEv6] points out, dynamic SA negotiation can't 565 be used for the protection of the first few connectivity 566 establishment messages in ICMPv6. It may be possible to overcome 567 these problems, however, the added security benefits of the 568 protection in these cases would be minimal: encrypted radio 569 communications exist at a lower layer, and the next hop router can 570 always engage in any denial-of-service attacks (such as dropping all 571 packets) regardless of the existence of any SAs. For these reasons, 572 the 3GPP terminals will not be mandated to support any security for 573 the pure IPv6 router and infrastructure protection purposes. 575 3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication 577 This RFC [RFC-2104] MUST be supported, as it is referenced from RFC 578 2403 which is mandatory in this set. 580 3.2 RFC2401 - Security Architecture for the Internet Protocol 582 This RFC [RFC-2401] MUST be supported. 584 3.3 RFC2402 - IP Authentication Header 586 This RFC [RFC-2402] SHOULD be supported. The AH protocol is one of 587 the alternative protocols in the IPsec protocol family, the other 588 alternative being ESP. 590 In the interest of minimizing implementation complexity and in 591 particular configuration options, both protocols may not be needed 592 in a cellular host. It is suggested that the ESP protocol be 593 preferred for its confidentiality protection function. We also note 594 that the IPsec WG has discussed the removal of AH, it is no longer 595 certain that AH be used for securing Mobile IP Binding Updates, and 596 tunnel mode ESP with integrity protection can perhaps be used to 597 provide some of the functions of AH. 599 For these reasons AH is made a SHOULD and ESP a MUST. However, 600 feedback is sought on the matter since this is against the 601 traditional standard rules, and the protection offered by AH is 602 different from ESP. 604 3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH 606 This RFC [RFC-2403] MUST be supported. 608 3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH 610 This RFC [RFC-2404] MUST be supported. 612 3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV 614 This RFC [RFC-2405] MAY be supported. It is, however, recommended 615 that stronger algorithms than DES be supported. 617 3.7 RFC2406 - IP Encapsulating Security Payload (ESP) 619 This RFC [RFC-2406] MUST be supported. 621 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP 623 This RFC [RFC-2407] SHOULD be supported. Automatic key management, 624 [RFC-2408] and [RFC-2409], are not a mandatory part of the IP 625 Security Architecture. Note, however, that in the cellular 626 environment the IP addresses of a host may change dynamically. For 627 this reason the use of manually configured Security Associations is 628 not practical, as the newest host address would have to be updated 629 to the SA data base of the peer as well. Regardless of this, 630 automatic key management is not made a mandatory requirement here. 631 This is because there may be other special-purpose keying schemes 632 for particular applications. 634 In the cellular environment, the detailed MUSTs within the IP 635 Security DoI, ISAKMP, and IKE is for further study. It is likely 636 that several simplifying assumptions can be made. For instance, the 637 use of pre-shared secrets as an authentication method in IKE is not 638 feasible in practice in the context of a large number of hosts. 640 3.9 RFC2408 - ISA and Key Management Protocol 642 This RFC [RFC-2408] MUST be supported where IKE is necessary for the 643 particular service provided, as described in the start of chapter 3, 644 and MAY be supported otherwise. 646 3.10 RFC2409 - The Internet Key Exchange (IKE) 648 This RFC [RFC-2409] SHOULD be supported where IKE is necessary for 649 the particular service provided, as described in the start of 650 chapter 3, and MAY be supported otherwise. 652 3.11 RFC2410 - The NULL Encryption Algorithm and its Use With IPsec 654 This RFC [RFC-2410] MUST be supported where IKE is necessary for the 655 particular service provided, as described in the start of chapter 3, 656 and MAY be supported otherwise. 658 3.12 RFC2411 - IP Security Document Roadmap 660 This RFC [RFC-2411] is of informational nature only. 662 3.13 RFC2451 - The ESP CBC-Mode Cipher Algorithms 664 This RFC [RFC-2451] MUST be supported if encryption algorithms other 665 than DES are implemented, e.g.: CAST-128, RC5, IDEA, Blowfish, 3DES. 667 3.14 IP Security Remote Access 669 The IETF IPSRA WG is working on solutions to provide remote access 670 mechanisms on top of IPsec in situations where legacy RADIUS or 671 other authentication is desired instead of PKI-based authentication. 672 These solutions are currently under development, but SHOULD be 673 supported by cellular hosts offering VPN services to corporate 674 intranets. 676 3.15 The AES Cipher Algorithm and Its Use With IPsec 678 This specification [AESIPSEC] MUST be supported. We suggest here 679 that in a new environment such as the cellular IPv6 older and 680 insecure algorithms such as DES should not be used, and that the 681 most secure and lightweight new ones should be used instead. Due to 682 better efficiency we suggest the use of AES instead of 3DES. 684 3.16 ICMPv6 and Its Effect to IKE and IPsec Policies 686 This specification [ICMPIKEv6] MUST be supported by hosts, if they 687 also support IKE. Without this specification, there may be certain 688 undesirable interactions between ICMPv6 and IKE. 690 4 IP Mobility 692 Mobile IPv6 manages IP mobility resulting from the change in CoA 693 when a host moves within the Internet topology. This section will 694 detail the level of support of MIPv6 required by cellular hosts and 695 highlight the scenarios in which such support is needed. 697 4.1 Mobility Support in IPv6 699 Mobile IPv6 is specified in [MIPv6]. 701 Mobile IP is required for hosts moving within the Internet topology. 702 At the highest level, the Mobile IPv6 functionality within Mobile 703 Nodes can be divided to the following parts: 705 - Mobile Node (MN) functionality, defined by Mobile IPv6 706 specification [MIPv6]. This includes the ability to configure 707 Home and Care-of-Addresses (CoA) send Binding Updates (BUs)and 708 receive Binding Acknowledgements and Requests. In addition, this 709 function also includes the ability to maintain a Binding Update 710 List. 711 - Correspondent Node (CN) functionality [MIPv6], i.e. the basic 712 functionality needed to correspond with mobile nodes. 714 - Route optimization. The functionality needed to correspond with 715 mobile nodes in an optimal manner. 717 We will discuss the use of each part in turn. The mobile node 718 functionality is needed when the host itself will move within the 719 Internet topology i.e. changes it's care-of address. This function 720 is needed in cellular systems where MIPv6 is used for intra-domain 721 mobility. In other cellular systems where intra-domain mobility is 722 handled by other means (e.g. GTP in a 3GPP system), only hosts with 723 additional, non-cellular interfaces MUST have this functionality if 724 they need to retain session or IP layer reachability while moving 725 between different access technologies, i.e. - to use MIPv6 for 726 inter-system IP handovers. 728 For instance, when a hosts has both a Wireless LAN (WLAN) and an 729 UMTS interface, MIPv6 MN functionality is needed to retain sessions 730 when moving from UMTS area to a WLAN area. The UMTS network provides 731 a basic mobility service (layer 2 mobility) to all hosts without 732 requiring the implementation of IP layer mobility. Hosts that have 733 interfaces only to networks providing such other mobility services, 734 or hosts that do not require session mobility through interface 735 handovers MAY have this functionality. 737 The basic functionality of a Correspondent Node, i.e. process the 738 Home Address Option, MUST be supported by all hosts. 740 The Route Optimized functionality for a CN, i.e. processing of 741 Binding Updates, SHOULD be supported by all hosts when the 742 communication benefits from this optimization. 744 4.2 Fast Handovers for Mobile IPv6 746 Fast handovers for Mobile IPv6 is specified in [MIPv6-FH]. 748 This draft SHOULD be supported if Mobile IPv6 [MIPv6] is supported 749 and when communication benefits from this optimization. 751 4.2.1 3GPP and Fast Handoffs 753 Within the current 3GPP architecture, a cellular host will always 754 keep the connection to the same GGSN (default router) for a context. 755 Movement between default routers is not permitted. The only scenario 756 where a MN would change default routers is in the case of a handover 757 between two different access technologies. In this case the MN will 758 be simultaneously connected to both routers which would eliminate 759 the need for anticipation through the current router. Hence the Fast 760 Handoffs draft will not be required within the current 3GPP 761 architecture. 763 4.3 Hierarchical MIPv6 Mobility Management 765 Hierarchical MIPv6 is specified in [HMIPv6]. 767 Hierarchy SHOULD be supported to run MIPv6 efficiently over the air. 768 This aims to reduce the number of MIPv6 BUs sent over the air while 769 moving within the topology. 771 4.3.1 HMIPv6 in 3GPP 773 As mentioned above, Inter-GGSN handovers are not allowed within the 774 current 3GPP architecture. Hence, the benefit of implementing HMIPv6 775 in 3GPP will only appear during the inter-access technology handover 776 which may not be as common as intra-access technology ones. However 777 the architecture can benefit from the per-flow movement explained in 778 the draft which allows a MN to receive different traffic flows on 779 different interfaces. 781 4.4 Mobile IP Security 783 The security design for Mobile IP is currently being performed in 784 the IETF. Before this work completes it will not be possible to 785 state in detail the security requirements for cellular hosts using 786 Mobile IP. However, we expect that security solutions will be 787 provided both for the protection of binding updates to correspondent 788 nodes, as well as secure tunneling support between the mobile node 789 and its home. 791 5 Security Considerations 793 This document does not specify any new protocols or functionality, 794 and as such it does not introduce any new security vulnerabilities. 795 However, specific profiles of IPv6 functionality are proposed for 796 different situations, and vulnerabilities may open or close 797 depending on which functionality is included and what is not. In the 798 following, we discuss such situations: 800 - The suggested limitations (Section 2.4) in the processing of 801 routing headers limits also exposure to Denial-of-Service 802 attacks through cellular hosts. 804 - The incompatibility of the addressing privacy [RFC3041] and 3GPP 805 address autoconfiguration model prevents the use of exactly the 806 same kind of privacy functionality as provided in IPv6. However, 807 it should be noted that in the 3GPP model the network will 808 assign new addresses to hosts in roaming situations and 809 typically also when the cellular terminals are turned on. This 810 means that a limited form of addressing privacy will already be 811 provided by 3GPP networks, and no global tracking of a single 812 terminal is possible through its address. 814 - The use of various security services such as IPsec or SSL in the 815 connection of typical applications in cellular hosts is 816 discussed in Chapter 3 and recommendations are given there. 818 - Chapter 3 also discusses under what conditions it is possible to 819 provide IPsec protection of e.g. ICMPv6 communications. 820 Recommendations are given to support VPN-type tunneling to home 821 networks, but to avoid the use of any security services in 822 towards visited network nodes due to problems setting up 823 sufficient PKI infrastructure for such usage. 825 - Chapter 3 further discusses a specific profile of IPsec suitable 826 for cellular implementations. Deviations from the standard RFCs 827 are suggested mainly due to a desire to adopt the latest 828 advances, such as the AES algorithm. On the other hand it is 829 suggested to employ only the ESP protocol for reasons of 830 reducing complexity. ESP provides a different protection than 831 AH, which may have security implications. 833 - As Chapter 4 mandates only the support of the Mobile IP Home 834 Address option and not the full, optimized correspondent node 835 behavior, the security problems related to Binding Updates are 836 not relevant for nodes supporting only the Core IP features. 838 - The air-time used by cellular hosts is expensive. In some cases 839 users are billed according to the amount of data they transfer 840 to and from their host. It is crucial for both the network and 841 the users that the air-time is used correctly and no extra 842 charges are applied to users due to misbehaving third parties. 843 The wireless links also have a limited capacity, which means 844 that they may not necessarily be able to accommodate more 845 traffic than what the user selected, such as a multimedia call. 846 Additional traffic might interfere with the service level 847 experienced by the user. While QoS mechanisms mitigate these 848 problems to an extent, it is still apparent that Denial-of- 849 Service aspects may be highlighted in the cellular environment. 850 It is possible for existing DoS attacks that use for instance 851 packet amplification to be substantially more damaging in this 852 environment. How these attacks can be protected against is still 853 an area of further study. It is also often easy to fill the 854 wireless link and queues on both sides with additional or large 855 packets. 857 - In certain areas of the world it is possible to buy a prepaid 858 cellular subscription without presenting personal 859 identification. This could be leveraged by attackers that wish 860 to remain unidentified. We note that while the user hasn't been 861 identified, the equipment still is; the operators can follow the 862 identity of the device and block it from further use. The 863 operators MUST have procedures in place to take notice of third 864 party complaints regarding the use of their customers' devices. 866 It MAY also be necessary for the operators to have attack 867 detection tools that enable them to efficiently detect attacks 868 launched from the cellular hosts. 870 - Cellular devices that have local network interfaces (such as 871 IrDA or Bluetooth) may be used to launch attacks through them, 872 unless the local interfaces are secured in an appropriate 873 manner. Therefore, we recommend that any local network interface 874 SHOULD have access controls to prevent bypassers from using the 875 cellular host as an intermediary. 877 6 References 879 [3GPPADDR] 3GPP 23.060, version 4.00, chapter 9.2.1.1 881 [3GPP-IMS] 3rd Generation Partnership Project; Technical 882 Specification Group Services and System Aspects; IP 883 Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228 884 version 5.0.0) 886 [ADDRARCH] Hinden, R. and Deering, S., "IP Version 6 Addressing 887 Architecture", RFC 2373, July 1998. 889 [ADDRCONF] Thomson, S. and Narten, T., "IPv6 Stateless Address 890 Autoconfiguration". RFC 2462. 892 [AESIPSEC] Frankel, S., Kelly, S. and Glenn, R., "The Candidate 893 AES Cipher Algorithms and Their Use With IPsec", 894 draft-ietf-ipsec-ciph-aes-cbc-01.txt, November 2000, 895 Work in progress 897 [DEFADDR] Draves, R., "Default Address Selection for IPv6", 898 draft-ietf-ipngwg-default-addr-select-05.txt, June 899 2001, Work in progress. 901 [DHCPv6] Bound, J. et al., "Dynamic Host Configuration 902 Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6- 903 19.txt, June 2001 Work in progress. 905 [HMIPv6] Soliman, H., Castelluccia, C., El-Malki, K. and 906 Bellier, L., "Hierarchical MIPv6 mobility 907 management", draft-ietf-mobileip-hmipv6-04.txt, July 908 2001, Work in progress 910 [ICMPIKEv6] Arkko, J., "Effects of ICMPv6 on IKE and IPsec 911 Policies", draft-arkko-icmpv6-ike-effects-00.txt, 912 February 2001, Work in progress 914 [ICMPv6] Conta, A. and Deering, S., "ICMP for the Internet 915 Protocol Version 6 (IPv6)", RFC 2463, December 1998. 917 [IPv6] Deering, S. and Hinden, R., "Internet Protocol, 918 Version 6 (IPv6) Specification", RFC 2460, December 919 1998. 921 [IPv6PPP] Haskin, D. and Allen, E., "IP Version 6 over PPP", 922 RFC 2472, December 1998 924 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 925 Requirement Levels", BCP 14, RFC 2119, March 1997. 927 [MIPv6] Johnson D. and Perkins, C., "Mobility Support in 928 IPv6", draft-ietf-mobileip-ipv6-14.txt, July 2001, 929 Work in progress. 931 [MIPv6-FH] Tsirtsis, G. et al., "Fast Handovers for Mobile 932 IPv6", draft-ietf-mobileip-fast-mipv6-02.txt, July 933 2001, Work in progress. 935 [MLD] Deering, S., Fenner, W. and Haberman, B., "Multicast 936 Listener Discovery (MLD) for IPv6", RFC 2710, October 937 1999 939 [PMTU] McCann, J., Mogul, J. and Deering, S., "Path MTU 940 Discovery for IP version 6", RFC 1981, August 1996. 942 [RFC-1034] Mockapetris, P., "Domain names _ concepts and 943 facilities", RFC 1034, November 1987 945 [RFC-1035] Mockapetris, P., "Domain names - implementation and 946 specification", STD 13, RFC 1035, November 1987. 948 [RFC-1886] Thomson, S. and Huitema, C., "DNS Extensions to 949 support IP version 6, RFC 1886, December 1995. 951 [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: 952 Keyed-Hashing for Message Authentication", RFC 2104, 953 February 1997. 955 [RFC-2246] Dierks, T. and Allen, C., "The TLS Protocol Version 956 1.0", RFC 2246, January 1999 958 [RFC-2374] Hinden, R., O'Dell, M. and Deering, S., "An IPv6 959 Aggregatable Global Unicast Address Format", RFC 960 2374, July 1998. 962 [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for 963 the Internet Protocol", RFC 2401, November 1998. 965 [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication 966 Header", RFC 2402, November 1998. 968 [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 969 within ESP and AH", RFC 2403, November 1998. 971 [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 972 within ESP and AH", RFC 2404, November 1998. 974 [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher 975 Algorithm With Explicit IV", RFC 2405, November 1998. 977 [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security 978 Protocol (ESP)", RFC 2406, November 1998. 980 [RFC-2407] Piper, D., "The Internet IP Security Domain of 981 Interpretation for ISAKMP", RFC 2407, November 1998. 983 [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and 984 Turner, J., "Internet Security Association and Key 985 Management Protocol (ISAKMP)", RFC 2408, November 986 1998. 988 [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key 989 Exchange (IKE)", RFC 2409, November 1998. 991 [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption 992 Algorithm and Its Use With IPsec", RFC 2410, November 993 1998 995 [RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 996 Document Roadmap", RFC 2411, November 1998. 998 [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher 999 Algorithms", RFC 2451, November 1998 1001 [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor 1002 Discovery for IP Version 6 (IPv6)", RFC 2461, 1003 December 1998. 1005 [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling 1006 in IPv6 Specification", RFC 2473, December 1998. 1008 [RFC-2529] Carpenter, B. and Jung, C., "Transmission of IPv6 1009 over IPv4 Domains without Explicit Tunnels_, RFC 1010 2529, March 1999. 1012 [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert 1013 Option", RFC 2711, October 1999. 1015 [RFC-2874] Crawford, M. and Huitema, C., "DNS Extensions to 1016 Support IPv6 Address Aggregation and Renumbering", 1017 RFC 2874, July 2000. 1019 [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms 1020 for IPv6 Hosts and Routers", RFC 2893, August 2000. 1022 [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for 1023 Stateless Address Autoconfiguration in IPv6", RFC 1024 3041, January 2001. 1026 [RFC-3056] Carpenter, B. and Moore, K., "Connection of Ipv6 1027 domains via IPv4 clouds", RFC 3056, February 2001. 1029 [TCPWIRELESS] Inamura, H. et al. _TCP over 2.5G and 3G Networks_. 1030 IETF, draft-ietf-pilc-2.5g3g-02.txt, Work in 1031 progress. 1033 [TRANSMECH] Gilligan, R. and Nordmark, E., "Transition Mechanisms 1034 for IPv6 Hosts and Routers", RFC 2893, August 2000. 1036 7 Acknowledgements 1038 The authors would like to thank David DeCamp, Markus Isomaki, Petter 1039 Johnsen, Janne Rinne, Jonne Soininen, Hesham Soliman and Shabnam 1040 Sultana for there comments and input. 1042 8 Authors' Addresses 1044 Jari Arkko 1045 Ericsson 1046 02420 Jorvas 1047 Finland 1049 Phone: +358 40 5079256 1050 Fax: +358 40 2993401 1051 E-Mail: Jari.Arkko@ericsson.com 1053 Peter Hedman 1054 Ericsson 1055 SE-221 83 LUND 1056 SWEDEN 1058 Phone: +46 46 231760 1059 Fax: +46 46 231650 1060 E-mail: peter.n.hedman@ecs.ericsson.se 1062 Gerben Kuijpers 1063 Ericsson 1064 Skanderborgvej 232 1065 DK-8260 Viby J 1066 DENMARK 1068 Phone: +45 89385100 1069 Fax: +45 89385101 1070 E-mail: gerben.a.kuijpers@ted.ericsson.dk 1072 John Loughney 1073 Nokia Research Center 1074 Itamerenkatu 11 _ 13 1075 FIN-00180 HELSINKI 1076 FINLAND 1078 Phone: +358 7180 36242 1079 Fax: +358 7180 36851 1080 E-mail: john.loughney@nokia.com 1082 Pertti Suomela 1083 Nokia Mobile Phones 1084 Sinitaival 5 1085 FIN-33720 TAMPERE 1086 Finland 1088 Phone: +358 7180 40546 1089 Fax: +358 7180 48215 1090 E-mail: pertti.suomela@nokia.com 1092 Juha Wiljakka 1093 Nokia Mobile Phones 1094 Sinitaival 5 1095 FIN-33720 TAMPERE 1096 Finland 1098 Phone: +358 7180 47562 1099 Fax: +358 7180 48215 1100 E-mail: juha.wiljakka@nokia.com 1102 Appendix A Cellular Host IPv6 Addressing in the 3GPP Model 1104 The appendix aims to describe 3GPP (Third Generation Partnership 1105 Project) IPv6 addressing model for 2G (GPRS) and 3G (UMTS) cellular 1106 networks [3GPPADDR]. 1108 There are two possibilities to allocate an address for an IPv6 node 1109 _ stateless and stateful autoconfiguration. The stateful address 1110 allocation mechanism needs a DHCP server to allocate the address for 1111 the IPv6 node. In the stateless autoconfiguration, the IPv6 node is 1112 more involved in the allocation and the stateless autoconfiguration 1113 procedure does not need any external entity involved in the address 1114 autoconfiguration. 1116 The two important network elements in the 3GPP packet based 1117 architecture are SGSN (Serving GPRS Support node) and GGSN (Gateway 1118 GPRS Support Node). GGSN is the nearest router for the mobile 1119 terminal / cellular host and it is responsible for giving an IP 1120 address to the mobile terminal. The logical link established 1121 between the GGSN Access Point and the mobile terminal is called PDP 1122 (Packet Data Protocol) context. 1124 To support dynamic IPv6 address allocation by the PLMN (Public Land 1125 Mobile Network) operator, the GGSN provides a unique interface 1126 identifier (see RFC 2462) to the mobile terminal. This enables the 1127 cellular host to perform the IPv6 stateless autoconfiguration 1128 procedures to generate its full IPv6 address. 1130 In the first phase the mobile terminal sends an Activate PDP Context 1131 Request message to the SGSN. The mobile terminal shall leave PDP 1132 Address empty and set PDP Type to IPv6. The GGSN shall create the 1133 unique link-local address for the mobile terminal and send it in the 1134 PDP Address information element in the Create PDP Context Response 1135 message. The link local address consists of a fixed 10-bit prefix 1136 (IPv6 link-local prefix), zero or more 0 bits, and the interface 1137 identifier. 1139 After that the mobile terminal may send a Router Solicitation 1140 message to the GGSN to activate the sending of the Router 1141 Advertisement message. 1143 The GGSN should automatically send the Router Advertisement message 1144 after the PDP context is activated. In 3GPP Release 99 the GGSN 1145 shall be configured to advertise only one network prefix per APN 1146 (Access Point Name). 1148 After the mobile terminal has received the Router Advertisement 1149 message, it constructs its full IPv6 address by concatenating the 1150 interface identifier contained in the link-local address provided in 1151 the Create PDP Context Response Message and the network prefix of 1152 the selected APN received in the Router Advertisement. Subsequently, 1153 the mobile terminal is ready to start communicating to the Internet. 1155 Because the GGSN provides a unique interface identifier during the 1156 PDP context activation procedure, there is no need for the mobile 1157 terminal to perform Duplicate Address Detection for this IPv6 1158 address. Therefore, the GGSN shall intercept and discard Neighbor 1159 Solicitation messages that the mobile terminal may send to perform 1160 Duplicate Address Detection. It is possible for the mobile terminal 1161 to perform Neighbor Unreachability Detection, as defined in RFC 1162 2461; therefore if the GGSN receives a Neighbor Solicitation as part 1163 of this procedure, the GGSN shall provide a Neighbor Advertisement 1164 as described in RFC 2461. 1166 Finally, the GGSN updates the PDP context in the SGSN and mobile 1167 terminal with the full IPv6 address (so-called GGSN-Initiated PDP 1168 Context Modification Procedure). 1170 Appendix B Transition Issues 1172 IETF has specified a number of IPv4 / IPv6 transition mechanisms 1173 [RFC-2893] to ensure smooth transition from IPv4 to IPv6 and 1174 interoperability between IPv4 and IPv6 during the transition period. 1175 The three main transition methods from a cellular network point of 1176 view are dual IPv4 / IPv6 stacks, tunneling and protocol 1177 translators, such as NAT-PT or SIIT. 1179 It is recommended that cellular hosts have dual IPv4 / IPv6 stacks 1180 to be able to interoperate with both IPv4 and IPv6 domains and use 1181 both IPv6 and IPv4 applications / services. It is recommended that 1182 the majority of the transition mechanisms are provided by the 1183 network in order to save the limited resources of the cellular host. 1184 Tunneling (for example RFC 3056 - Connection of IPv6 Domains via 1185 IPv4 Clouds) should be carried out in the network. Also any 1186 protocol translation function, such as NAT-PT, should be implemented 1187 in the network, not in the cellular host. The tunneling mechanism 1188 specified by [RFC-2529] is not relevant for a cellular host. [RFC- 1189 2529] allows isolated IPv6-only hosts to connect to an IPv6 router 1190 via an IPv4 domain. The scenario of an IPv6-only host in an IPv4- 1191 only cellular network is considered unlikely.