idnits 2.17.1 draft-ietf-16ng-ipv6-over-ipv6cs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 817. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (January 17, 2007) is 6308 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Basavaraj Patil 3 Internet-Draft Nokia 4 Intended status: Standards Track Frank Xia 5 Expires: July 21, 2007 Behcet Sarikaya 6 Huawei USA 7 JH. Choi 8 Samsung AIT 9 Syam Madanapalli 10 LogicaCMG 11 January 17, 2007 13 IPv6 Over the IP Specific part of the Packet Convergence sublayer in 14 802.16 Networks 15 draft-ietf-16ng-ipv6-over-ipv6cs-06 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on July 21, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 IEEE Std 802.16 is an air interface specification. IEEE has 49 specified several service specific convergence sublayers (CS) for 50 802.16 which are used by upper layer protocols. The ATM CS and 51 Packet CS are the two main service specific convergence sublayers and 52 these are a part of the 802.16 MAC which the upper layers interface 53 to. The packet CS is used for transport for all packet-based 54 protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) 55 and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS 56 enables transport of IPv6 packets directly over the MAC. This 57 document specifies the addressing and operation of IPv6 over the IPv6 58 specific part of the packet CS for hosts served by a network that 59 utilizes the IEEE Std 802.16 air interface. It recommends the 60 assignment of a unique prefix (or prefixes) to each host and allows 61 the host to use multiple identifiers within that prefix, including 62 support for randomly generated identifiers. 64 Table of Contents 66 1. Conventions used in this document . . . . . . . . . . . . . . 4 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. IEEE 802.16 convergence sublayer support for IPv6 . . . . . . 5 70 4.1. IPv6 encapsulation over the IP CS of the MAC . . . . . . . 7 71 5. Generic network architecture using the 802.16 air interface . 8 72 6. IPv6 link . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. IPv6 link in 802.16 . . . . . . . . . . . . . . . . . . . 9 74 6.2. IPv6 link establishment in 802.16 . . . . . . . . . . . . 10 75 6.3. Maximum transmission unit in 802.16 . . . . . . . . . . . 11 76 7. IPv6 prefix assignment . . . . . . . . . . . . . . . . . . . . 11 77 8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 11 79 8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 12 80 8.3. Router lifetime and periodic router advertisements . . . . 12 81 9. IPv6 addressing for hosts . . . . . . . . . . . . . . . . . . 12 82 9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 12 83 9.2. Duplicate address detection . . . . . . . . . . . . . . . 13 84 9.3. Stateless address autoconfiguration . . . . . . . . . . . 13 85 9.4. Stateful address autoconfiguration . . . . . . . . . . . . 13 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 92 Appendix A. WiMAX network architecture and IPv6 support . . . . . 15 93 Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 16 94 Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 17 95 Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 17 96 Appendix E. Stateless address autoconfiguration . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 98 Intellectual Property and Copyright Statements . . . . . . . . . . 20 100 1. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. Introduction 108 IPv6 packets can be carried over the IEEE Std 802.16 specified air 109 interface via either: 111 1. the IP specific part of the Packet CS or, 112 2. the 802.3 specific part of the Packet CS or, 113 3. the 802.1Q specific part of the Packet CS. 115 The 802.16 [802.16] specification includes the Phy and MAC details. 116 The convergence sublayers are a part of the MAC. This document 117 specifies IPv6 from the perspective of the transmission of IPv6 over 118 the IP specific part of the packet convergence sublayer. The mobile 119 station/host is attached to an access router via a base station (BS). 120 The host and the BS are connected via the IEEE Std 802.16 air 121 interface at the link and physical layers. The IPv6 link from the MS 122 terminates at an access router which may be a part of the BS or an 123 entity beyond the BS. The base station is a layer 2 entity (from the 124 perspective of the IPv6 link between the MS and AR) and relays the 125 IPv6 packets between the AR and the host via a point-to-point 126 connection over the air interface. The WiMAX (Worldwide 127 Interoperability for Microwave Access) forum [WMF] has defined a 128 network architecture in which the air interface is based on the IEEE 129 802.16 standard. The addressing and operation of IPv6 described in 130 this document is applicable to the WiMAX network as well. The 131 various aspects of IPv6 over 802.16 as applicable to WiMAX are 132 captured in the appendix sections of this document. 134 3. Terminology 136 The terminology in this document is based on the definitions in 137 [PSDOC], in addition to the ones specified in this section. 139 Access Service Network (ASN) - The ASN is defined as a complete set 140 of network functions needed to provide radio access to a WiMAX 141 subscriber. The ASN is the access network to which the MS attaches. 142 The IPv6 access router is an entity within the ASN. The term ASN is 143 specific to the WiMAX network architecture. 145 4. IEEE 802.16 convergence sublayer support for IPv6 147 The IEEE 802.16 MAC specifies two main service specific convergence 148 sublayers: 150 1. ATM Convergence sublayer 151 2. Packet Convergence sublayer 153 The Packet CS is used for the transport of packet based protocols 154 which include: 156 1. IEEE Std 802.3(Ethernet) 157 2. IEEE Std 802.1Q(VLAN) 158 3. Internet Protocol (IPv4 and IPv6) 160 The service specific CS resides on top of the MAC Common Part 161 Sublayer (CPS). The service specific CS is responsible for: 163 o accepting packets (PDUs) from the upper layer, 164 o performing classification of the packet/PDU based on a set of 165 classifiers that are defined which are service specific, 166 o delivering the CS PDU to the appropriate service flow and 167 transport connection and, 168 o receiving PDUs from the peer entity. 170 Payload header suppression (PHS) is also a function of the CS but is 171 optional. 173 The figure below shows the concept of the service specific CS in 174 relation to the MAC: 176 -----------------------------\ 177 | ATM CS | Packet CS | \ 178 ----------------------------- \ 179 | MAC Common Part Sublayer | \ 180 | (Ranging, scheduling, etc)| 802.16 MAC 181 ----------------------------- / 182 | Security | / 183 |(Auth, encryption,key mgmt)| / 184 -----------------------------/ 185 | PHY | 186 ----------------------------- 188 Figure 1: The 802.16 MAC 190 Classifiers for each of the specific upper-layer protocols, i.e 191 Ethernet, VLAN and IP, are defined which enable the packets from the 192 upper layer to be processed by the appropriate service specific part 193 of the packet CS. IPv6 can be transported directly over the IP 194 specific part of the packet CS or over 802.3/Ethernet (which in turn 195 is handled by the Ethernet specific part of the packet CS) or over 196 802.1Q (which is handled by the 802.1Q specific part of the packet 197 CS). 199 The figure below shows the options for IPv6 transport over the packet 200 CS of 802.16: 202 ----------------- ----------------- 203 | IPv6 | | IPv6 | 204 ---------------- |---------------| |----------- | 205 | IPv6 | | Ethernet | | 802.1Q | 206 |--------------| |---------------| |----------- | 207 | IP Specific | | 802.3 specific| |802.1Q specific| 208 |part of Pkt CS| |part of Pkt CS | |part of Pkt CS | 209 |..............| |...............| |...............| 210 | MAC | | MAC | | MAC | 211 |--------------| |---------------| |---------------| 212 | PHY | | PHY | | PHY | 213 ---------------- ----------------- ----------------- 215 (1) IPv6 over (2) IPv6 over (3) IPv6 over 216 IP Specific part 802.3/Ethernet 802.1Q 217 of Packet CS 219 Figure 2: IPv6 over IP, 802.3 and 802.1Q specific parts of the Packet 220 CS 222 The scope of this document is limited to IPv6 operation over the IP 223 specific part of the Packet CS only. It should be noted that 224 immediately after ranging (802.16 air interface procedure), the MS 225 and BS exchange their capability negotiation via REG-REQ and REG-RSP. 226 These management frames negotiate parameters such as the Convergence 227 Sublayer support. By default, Packet, IPv4 and 802.3/Ethernet are 228 supported. IPv6 via the Packet CS is supported by the MS and the BS 229 only when the bit specifying such support is indicated in the 230 parameter "Classification/PHS options and SDU encapsulation support" 231 (Refer to [802.16]). Additionally during the establishment of the 232 transport connection for transporting IPv6 packets, the DSA-REQ and 233 DSA-RSP messages between the BS and MS indicate via the CS- 234 Specification TLV the CS that the connection being setup shall use. 235 When the IPv6 packet is encapsulated by the 802.16 six byte MAC 236 header there is no specific indication in the MAC header itself about 237 the payload type. The processing of the packet is based entirely on 238 the classifiers. 240 Transmission of IPv6 as explained above is possible via multiple 241 methods, i.e, via the IP specific part of the packet CS or via 242 Ethernet or 802.1Q interfaces. The choice of which method to use is 243 implementation specific. In order to ensure interoperability the BS 244 should at least support both the IP specific part of the packet CS 245 and the Ethernet specific part of the packet CS for IPv6 transport. 246 Hosts which may implement one or the other method for transmission 247 would be assured of the ability to establish a transport connection 248 that would enable the transport of IPv6 packets. Inability to 249 negotiate a common convergence sublayer for the transport connection 250 between the MS and BS will result in failure to setup the transport 251 connection and thereby render the host unable to send and receive 252 IPv6 packets. In the case of a host which implements more than one 253 method of transporting IPv6 packets, the choice of which method to 254 use (i.e IPv6 over the IP specific part of the packet CS or IPv6 over 255 802.3 or, IPv6 over 802.1Q) is implementation specific. 257 4.1. IPv6 encapsulation over the IP CS of the MAC 259 The IPv6 payload when carried over the IP specific part of the Packet 260 CS is encapsulated by the 6 byte 802.16 MAC header. Header 261 suppression can also be applied to the IP packet. The format of the 262 IPv6 packet with and without header suppression is shown in the 263 figure below: 265 ---------/ /----------- 266 | MAC SDU | 267 --------/ /------------ 268 || 269 || 270 \/ 271 --------------------------------------------------------- 272 | PHSI=0 | IPv6 Packet (including Header) | 273 --------------------------------------------------------- 274 (i) IPv6 packet without header suppression 276 --------------------------------------------------------- 277 | PHSI=1 | (Header suppressed IPv6 packet) | 278 --------------------------------------------------------- 279 (ii) IPv6 packet with header suppression 280 Figure 3: IPv6 encapsulation 282 For transmission of IPv6 packets via the IP specific part of the 283 Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC 284 directly. The IPv6 layer delivers the IPv6 packet to the Packet CS 285 of the 802.16. The packet CS defines a set of classifiers that are 286 used to determine how to handle the packet. The IP classifiers that 287 are used at the MAC operate on the fields of the IP header and the 288 transport protocol and these include the IP Traffic class, Next 289 header field, Masked IP source and destination addresses and, 290 Protocol source and destination port ranges. Using the classifiers, 291 the MAC maps an upper layer packet to a specific service flow and 292 transport connection to be used. The MAC encapsulates the IPv6 293 packet in the 6 byte MAC header and transmits it. 295 5. Generic network architecture using the 802.16 air interface 297 In a network that utilizes the 802.16 air interface the host/MS is 298 attached to an IPv6 access router (AR) in the network. The BS is a 299 layer 2 entity only. The AR can be an integral part of the BS or the 300 AR could be an entity beyond the BS within the access network. IPv6 301 packets between the MS and BS are carried over a point-to-point 302 transport connection which has a unique connection identifier (CID). 303 The transport connection is a MAC layer link between the MS and the 304 BS. The figures below describe the possible network architectures 305 and are generic in nature. More esoteric architectures are possible 306 but not considered in the scope of this document. Option A: 308 +-----+ CID1 +--------------+ 309 | MS1 |------------/| BS/AR |-----[Internet] 310 +-----+ / +--------------+ 311 . /---/ 312 . CIDn 313 +-----+ / 314 | MSn |---/ 315 +-----+ 317 Figure 4: The IPv6 AR as an integral part of the BS 319 Option B: 321 +-----+ CID1 +-----+ +-----------+ 322 | MS1 |----------/| BS1 |----------| AR |-----[Internet] 323 +-----+ / +-----+ +-----------+ 324 . / ____________ 325 . CIDn / ()__________() 326 +-----+ / L2 Tunnel 327 | MSn |-----/ 328 +-----+ 330 Figure 5: The IPv6 AR is separate from the BS, which acts as a bridge 332 The above network models serve as examples and are shown to 333 illustrate the point to point link between the MS and the AR. 334 Appendix A shows a realization of the generic architecture by the 335 WiMAX forum. 337 6. IPv6 link 339 RFC 2461 defines link as a communication facility or medium over 340 which nodes can communicate at the link layer, i.e., the layer 341 immediately below IP [RFC2461]. A link is bounded by routers that 342 decrement the Hop limit field in the IPv6 header. When an MS moves 343 within a link, it can keep using its IP addresses. This is a layer 3 344 definition and note that the definition is not identical with the 345 definition of the term '(L2) link' in IEEE 802 standards. This 346 section presents a model for the last mile link, i.e. the link to 347 which MSs attach themselves. 349 6.1. IPv6 link in 802.16 351 In 802.16, the Transport Connection between an MS and a BS is used to 352 transport user data, i.e. IPv6 packets in this case. A Transport 353 Connection is represented by a CID (Connection Identifier) and 354 multiple Transport Connections can exist between an MS and BS. IEEE 355 802.16 also defines a secondary management connection that can be 356 used for host configuration. However support for secondary 357 management connections is not mandatory. A transport connection has 358 the advantage of it being used for host configuration as well as for 359 user data. 361 When an AR and a BS are collocated, the collection of Transport 362 Connections to an MS is defined as a single link. When an AR and a 363 BS are separated, it is recommended that a tunnel is established 364 between the AR and a BS whose granuality is no greater than 'per MS' 365 or 'per service flow' ( An MS can have multiple service flows which 366 are identified by a service flow ID). Then the tunnel(s) for an MS, 367 in combination with the MS's Transport connections, forms a single 368 point-to-point link. 370 The collection of service flows (tunnels) to an MS is defined as a 371 single link. Each link has only an MS and an AR. Each MS belongs to 372 a different link. No two MSs belong to the same link. A different 373 prefix should be assigned to each unique link. This link is fully 374 consistent with a standard IP link, without exception and conforms 375 with the definition of a point-to-point link in RFC2461 [RFC2461]. 376 Hence the point-to-point link model for IPv6 operation over the IP 377 specific part of the Packet CS in 802.16 is recommended. A unique 378 IPv6 prefix(es) per link (MS) is also recommended. 380 6.2. IPv6 link establishment in 802.16 382 In order to enable the sending and receiving of IPv6 packets between 383 the MS and the AR, the link between the MS and the AR via the BS 384 needs to be established. This section illustrates the link 385 establishment procedure. 387 The MS goes through the network entry procedure as specified by 388 802.16. A high level description of the network entry procedure is 389 as follows: 391 1. MS performs initial ranging with the BS. Ranging is a process by 392 which an MS becomes time aligned with the BS. The MS is 393 synchronized with the BS at the succesful completion of ranging 394 and is ready to setup a connection. 395 2. MS and BS perform capability exchange as per 802.16 procedures. 396 The CS capability parameter indicates which classification/PHS 397 options and SDU encapsulation the MS supports. By default, 398 Packet, IPv4 and 802.3/Ethernet shall be supported, thus absence 399 of this parameter in REG-REQ (802.16 message) means that named 400 options are supported by the MS/SS. Support for IPv6 over the IP 401 specific part of the packet CS is indicated by Bit#2 of the CS 402 capability parameter (Refer to [802.16]). 403 3. The MS progresses to an authentication phase. Authentication is 404 based on PKMv2 as defined in the IEEE Std 802.16 specification. 405 4. On succesful completion of authentication, the MS performs 802.16 406 registration with the network. 407 5. The MS can request the establishment of a service flow for IPv6 408 packets over the IP specific part of the Packet CS. The service 409 flow can also be triggered by the network as a result of pre- 410 provisioning. The service flow establishes a link between the MS 411 and the AR over which IPv6 packets can be sent and received. 412 6. The AR sends a router advertisement to the MS. Alternatively or 413 in addition, the MS can also send a router solicitation. 415 The above flow does not show the actual 802.16 messages that are used 416 for ranging, capability exchange or service flow establishment. 417 Details of these are in [802.16]. 419 6.3. Maximum transmission unit in 802.16 421 The 802.16 MAC PDU (Protocol Data Unit) is composed by a 6 byte 422 header followed by an optional payload and an optional CRC covering 423 the header and the payload. The length of the PDU is indicated by 424 the Len parameter in the Generic MAC HDR. The Len parameter has a 425 size of 11 bits. Hence the total PDU size is 2048 bytes. The IPv6 426 payload can be a max value of 2038 bytes ( Total PDU size minus (MAC 427 Header + CRC)). The Max value of the IPv6 MTU for 802.16 is 2038 428 bytes and the minimum value of 1280 bytes. The default MTU for IPv6 429 over 802.16 SHOULD be the same as specified in RFC2460 which is 1500 430 octets. RFC2461 defines an MTU option that an AR can advertise to an 431 MN. If an AR advertises an MTU via the RA MTU option, the MN should 432 use the MTU from the RA. 434 7. IPv6 prefix assignment 436 The MS and the AR are connected via a point-to-point connection at 437 the IPv6 layer. Hence each MS can be considered to be on a separate 438 subnet. A CPE (Customer Premise Equipment) type of device which 439 serves multiple IPv6 hosts, may be the end point of the connection. 440 Hence one or more /64 prefixes should be assigned to a link. The 441 prefixes are advertised with the on-link (L-bit) flag set as 442 specified in RFC2461 [RFC2461]. The size and number of the prefixes 443 is a configuration issue. Also, prefix delegation may be used to 444 provide additional prefixes for a router connected over 802.16. The 445 other properties of the prefixes are also dealt via configuration. 447 8. Router Discovery 449 8.1. Router Solicitation 451 On completion of the establishment of the IPv6 link, the MS may send 452 a router solicitation message to solicit a Router Advertisement 453 message from the AR to acquire necessary information as per RFC2461. 454 An MS that is network attached may also send router solicitations at 455 any time as per RFC2461. Movement detection at the IP layer of an MS 456 in many cases is based on receiving periodic router advertisements. 457 An MS may also detect changes in its attachment via link triggers or 458 other means. The MS can act on such triggers by sending router 459 solicitations. The router solicitation is sent over the IPv6 link 460 that has been previously established. The MS sends router 461 solicitations to the all-routers multicast address. It is carried 462 over the point-to-point link to the AR via the BS. The MS does not 463 need to be aware of the link-local address of the AR in order to send 464 a router solicitation at any time. 466 8.2. Router Advertisement 468 The AR should send a number (configurable value) of router 469 advertisements as soon as the IPv6 link is established, to the MS. 470 The AR sends unsolicited router advertisements periodically as per 471 RFC2461. The interval between periodic router advertisements is 472 however greater than the specification in RFC2461 and is discussed in 473 the following section. 475 8.3. Router lifetime and periodic router advertisements 477 The router lifetime should be set to a large value, preferably in 478 hours. This document over-rides the specification for the value of 479 the router lifetime in RFC2461 [RFC2461]. The AdvDefaultLifetime in 480 the router advertisement MUST be either zero or between 481 MaxRtrAdvInterval and 43200 seconds. The default value is 2 * 482 MaxRtrAdvInterval. 484 802.16 hosts have the capability to transition to an idle mode in 485 which case the radio link between the BS and MS is torn down. Paging 486 is required in case the network needs to deliver packets to the MS. 487 In order to avoid waking a mobile which is in idle mode and consuming 488 resources on the air interface, the interval between periodic router 489 advertisements should be set quite high. The MaxRtrAdvInterval value 490 specified in this document over-rides the recommendation in RFC2461 491 [RFC2461]. The MaxRtrAdvInterval MUST be no less than 4 seconds and 492 no greater than 21600 seconds. The default value for 493 MaxRtrAdvInterval is 10800 seconds. 495 9. IPv6 addressing for hosts 497 The addressing scheme for IPv6 hosts in 802.16 network follows the 498 IETFs recommendation for hosts specified in RFC 4294. The IPv6 node 499 requirements RFC RFC4294 [RFC4294] specifies a set of RFCs that are 500 applicable for addressing and the same is applicable for hosts that 501 use 802.16 as the link layer for transporting IPv6 packets. 503 9.1. Interface Identifier 505 The MS has a 48-bit MAC address as specified in 802.16 [802.16]. 506 This MAC address can be used if EUI-64 based interface identifier is 507 needed for autoconfiguration RFC4291 [RFC4291]. As in other links 508 that support IPv6, EUI-64 based interface identifiers are not 509 mandatory and other mechanisms, such as random interface identifiers 510 RFC3041 [RFC3041] may also be used. 512 9.2. Duplicate address detection 514 DAD is performed as per RFC2461 [RFC2461] and, RFC2462 [RFC2462]. 516 9.3. Stateless address autoconfiguration 518 If the A-bit in the prefix information option (PIO) is set, the MS 519 performs stateless address autoconfiguration as per RFC 2461, 2462. 520 The AR is the default router that advertises a unique prefix (or 521 prefixes) that is used by the MS to configure an address. 523 9.4. Stateful address autoconfiguration 525 The Stateful Address Autoconfiguration is invoked if the M-flag is 526 set in the Router Advertisement. Obtaining the IPv6 address through 527 stateful address autoconfiguration method is specified in RFC3315 528 [RFC3315]. 530 10. IANA Considerations 532 This draft does not require any actions from IANA. 534 11. Security Considerations 536 This document does not introduce any new vulnerabilities to IPv6 537 specifications or operation. The security of the 802.16 air 538 interface is the subject of [802.16]. In addition, the security 539 issues of the network architecture spanning beyond the 802.16 base 540 stations is the subject of the documents defining such architectures, 541 such as WiMAX Network Architecture [WiMAXArch]. 543 12. Acknowledgments 545 The authors would like to acknowledge the contributions of the 16NG 546 working group chairs Soohong Daniel Park and Gabriel Montenegro as 547 well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ 548 Johnston, Dave Thaler, Bruno Sousa and Alexandru Petrescu for their 549 review and comments. 551 13. References 552 13.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", RFC 2119, March 1997, 556 . 558 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 559 Discovery for IP Version 6 (IPv6)", RFC 2461, 560 December 1998, . 562 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 563 Autoconfiguration", RFC 2462, December 1998, 564 . 566 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 567 Architecture", RFC 4291, February 2006, 568 . 570 13.2. Informative References 572 [802.16] "IEEE Std 802.16e: IEEE Standard for Local and 573 metropolitan area networks, Amendment for Physical and 574 Medium Access Control Layers for Combined Fixed and Mobile 575 Operation in Licensed Bands", October 2005. 577 [PSDOC] Jee, J., Madanapalli, S., Montenegro, G., Riegel, M., 578 Mandin, J., and S. Park, "IP over 802.16 Problem Statement 579 and Goals", October 2006, . 582 [RFC3041] Narten, T., Draves, R., and S. Krishnan, "Privacy 583 Extensions for Stateless Address Autoconfiguration in 584 IPv6", August 2006, . 587 [RFC3315] Droms, Ed., R., Bound, J., Volz, B., Lemon, T., Perkins, 588 C., and M. Carney, "Dynamic Host Configuration Protocol 589 for IPv6 (DHCPv6)", RFC 3315, July 2003, 590 . 592 [RFC4294] Loughney, Ed., J., "IPv6 Node requirements", RFC 4294, 593 April 2006, . 595 [WMF] "http://www.wimaxforum.org". 597 [WiMAXArch] 598 "WiMAX End-to-End Network Systems Architecture 599 http://www.wimaxforum.org/technology/documents", 600 August 2006. 602 Appendix A. WiMAX network architecture and IPv6 support 604 The WiMAX network architecture consists of the Access Service Network 605 (ASN) and the Connectivity Service Network (CSN). The ASN is the 606 access network which includes the BS and the AR in addition to other 607 functions such as AAA, Mobile IP Foreign agent, Paging controller, 608 Location Register etc. The CSN is the entity that provides 609 connectivity to the Internet and includes functions such as Mobile IP 610 Home agent and AAA. The figure below shows the WiMAX reference 611 model: 613 ------------------- 614 | ---- ASN | |----| 615 ---- | |BS|\ R6 -------| |---------| | CSN| 616 |MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | | 617 ---- | |R8 /--|------|----| |-----|Home| 618 | ---- / | | visited| | NSP| 619 | |BS|/ | | NSP | | | 620 | ---- | |---------| | | 621 | NAP | \ |----| 622 ------------------- \---| / 623 | | / 624 | (--|------/----) 625 |R4 ( ) 626 | ( ASP network ) 627 --------- ( or Internet ) 628 | ASN | ( ) 629 --------- (----------) 631 Figure 6: WiMAX Network reference model 633 Three different types of ASN realizations called profiles are defined 634 by the architecture. ASNs of profile types A and C include BS' and 635 ASN-gateway(s) (ASN-GW) which are connected to each other via an R6 636 interface. An ASN of profile type B is one in which the 637 functionality of the BS and other ASN functions are merged together. 638 No ASN-GW is specifically defined in a profile B ASN. The absence of 639 the R6 interface is also a profile B specific characteristic. The MS 640 at the IPv6 layer is associated with the AR in the ASN. The AR may 641 be a function of the ASN-GW in the case of profiles A and C and is a 642 function in the ASN in the case of profile B. When the BS and the AR 643 are separate entities and linked via the R6 interface, IPv6 packets 644 between the BS and the AR are carried over a GRE tunnel. The 645 granularity of the GRE tunnel should be on a per MS basis or on a per 646 service flow basis (an MS can have multiple service flows, each of 647 which are identified uniquely by a service flow ID). The protocol 648 stack in WiMAX for IPv6 is shown below: 650 |-------| 651 | App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 652 | | 653 |-------| /------ ------- 654 | | / IPv6 | | | 655 | IPv6 |- - - - - - - - - - - - - - - - / | | |--> 656 | | --------------- -------/ | | IPv6| 657 |-------| | \Relay/ | | | |- - - | | 658 | | | \ / | | GRE | | | | 659 | | | \ /GRE | - | | | | | 660 | |- - - | |-----| |------| | | | 661 | IPv6CS| |IPv6CS | IP | - | IP | | | | 662 | ..... | |...... |-----| |------|--------| |-----| 663 | MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 | 664 |-------| |------ |-----| |----- |--------| |-----| 665 | PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 | 666 -------- --------------- ----------------- ------- 668 MS BS AR/ASN-GW CSN Rtr 670 Figure 7: WiMAX protocol stack 672 As can be seen from the protocol stack description, the IPv6 end- 673 points are constituted in the MS and the AR. The BS provides lower 674 layer connectivity for the IPv6 link. 676 Appendix B. IPv6 link in WiMAX 678 WiMAX is an example of a network based on the IEEE Std 802.16 air 679 interface. This section describes the IPv6 link in the context of a 680 WiMAX network. The MS and the AR are connected via a combination of 681 : 683 1. The transport connection which is identified by a Connection 684 Identifier (CID) over the air interface, i.e the MS and BS and, 686 2. A GRE tunnel between the BS and AR which transports the IPv6 687 packets 689 From an IPv6 perspective the MS and the AR are connected by a point- 690 to-point link. The combination of transport connection over the air 691 interface and the GRE tunnel between the BS and AR creates a (point- 692 to-point) tunnel at the layer below IPv6. 694 The collection of service flows (tunnels) to an MS is defined as a 695 single link. Each link has only an MS and an AR. Each MS belongs to 696 a different link. No two MSs belong to the same link. A different 697 prefix should be assigned to each unique link. This link is fully 698 consistent with a standard IP link, without exception and conforms 699 with the definition of a point-to-point link in RFC2461 [RFC2461]. 701 Appendix C. IPv6 link establishment in WiMAX 703 The mobile station performs initial network entry as specified in 704 802.16. On succesful completion of the network entry procedure the 705 ASN gateway/AR triggers the establishment of the initial service flow 706 (ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the 707 ASN-GW/AR and the BS. The BS in turn requests the MS to establish a 708 transport connection over the air interface. The end result is a 709 transport connection over the air interface for carrying IPv6 packets 710 and a GRE tunnel between the BS and AR for relaying the IPv6 packets. 711 On succesful completion of the establishment of the ISF, IPv6 packets 712 can be sent and received between the MS and AR. The ISF enables the 713 MS to communicate with the AR for host configuration procedures. 714 After the establishment of the ISF, the AR can send a router 715 advertisement to the MS. An MS can establish multiple service flows 716 with different QoS characteristics. The ISF can be considered as the 717 primary service flow. The ASN-GW/ AR treats each ISF, along with the 718 other service flows to the same MS, as a unique link which is managed 719 as a (virtual) interface. 721 Appendix D. Maximum transmission unit in WiMAX 723 The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. 724 Hence the IPv6 path MTU can be 1500 octets. However because of the 725 overhead of the GRE tunnel used to transport IPv6 packets between the 726 BS and AR and the 6 byte MAC header over the air interface, using a 727 value of 1500 would result in fragmentation of packets. It is 728 recommended that the default MTU for IPv6 be set to 1400 octets for 729 the MS in WiMAX networks. Note that the 1522 octet specification is 730 a WiMAX forum specification and not the size of the SDU that can be 731 transmitted over 802.16, which has a higher limit. 733 Appendix E. Stateless address autoconfiguration 735 The MS can perform stateless address autoconfiguration as per 736 RFC2461, 2462 if the A-bit in the prefix information option (PIO) is 737 set. The AR is the default router that advertises a unique /64 738 prefix (or prefixes) that is used by the MS to configure an address. 740 Authors' Addresses 742 Basavaraj Patil 743 Nokia 744 6000 Connection Drive 745 Irving, TX 75039 746 USA 748 Email: basavaraj.patil@nokia.com 750 Frank Xia 751 Huawei USA 752 1700 Alma Dr. Suite 100 753 Plano, TX 75075 755 Email: xiayangsong@huawei.com 757 Behcet Sarikaya 758 Huawei USA 759 1700 Alma Dr. Suite 100 760 Plano, TX 75075 762 Email: sarikaya@ieee.org 764 JinHyeock Choi 765 Samsung AIT 766 Networking Technology Lab 767 P.O.Box 111 768 Suwon, Korea 440-600 770 Email: jinchoe@samsung.com 771 Syam Madanapalli 772 LogicaCMG 773 125 Yemlur P.O. 774 Off Airport Road 775 Bangalore, India 560037 777 Email: smadanapalli@gmail.com 779 Full Copyright Statement 781 Copyright (C) The IETF Trust (2007). 783 This document is subject to the rights, licenses and restrictions 784 contained in BCP 78, and except as set forth therein, the authors 785 retain all their rights. 787 This document and the information contained herein are provided on an 788 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 789 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 790 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 791 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 792 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 793 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 795 Intellectual Property 797 The IETF takes no position regarding the validity or scope of any 798 Intellectual Property Rights or other rights that might be claimed to 799 pertain to the implementation or use of the technology described in 800 this document or the extent to which any license under such rights 801 might or might not be available; nor does it represent that it has 802 made any independent effort to identify any such rights. Information 803 on the procedures with respect to rights in RFC documents can be 804 found in BCP 78 and BCP 79. 806 Copies of IPR disclosures made to the IETF Secretariat and any 807 assurances of licenses to be made available, or the result of an 808 attempt made to obtain a general license or permission for the use of 809 such proprietary rights by implementers or users of this 810 specification can be obtained from the IETF on-line IPR repository at 811 http://www.ietf.org/ipr. 813 The IETF invites any interested party to bring to its attention any 814 copyrights, patents or patent applications, or other proprietary 815 rights that may cover technology that may be required to implement 816 this standard. Please address the information to the IETF at 817 ietf-ipr@ietf.org. 819 Acknowledgment 821 Funding for the RFC Editor function is provided by the IETF 822 Administrative Support Activity (IASA).