idnits 2.17.1 draft-ietf-16ng-ipv6-over-ipv6cs-08.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 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 890. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Multicast Listener Discovery Version 2(MLDv2) for IPv6 RFC3810 [RFC3810] SHOULD be supported as specified by the hosts and routers attached to each other via an 802.16 link. The access router which has hosts attached to it via a Point-to-point link over an 802.16 SHOULD not send periodic queries if the host is in idle/dormant mode. The AR can obtain information about the state of a host from the paging controller in the network. -- 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 (March 5, 2007) is 6261 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) == Outdated reference: A later version (-01) exists of draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00 -- 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 (~~), 3 warnings (==), 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: September 6, 2007 Behcet Sarikaya 6 Huawei USA 7 JH. Choi 8 Samsung AIT 9 Syam Madanapalli 10 LogicaCMG 11 March 5, 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-08 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 September 6, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 IEEE Std 802.16 is an Air Interface for Fixed and Mobile Broadband 49 Wireless Access Systems. The 802.16 specification includes several 50 service specific convergence sublayers (CS) as part of the MAC 51 (Medium Access Control) layer which are used by upper layer 52 protocols. The ATM CS and Packet CS are the two main service 53 specific convergence sublayers and these are a part of the 802.16 MAC 54 to which the upper layers interface. The packet CS is used for 55 transport for all packet-based protocols such as Internet Protocol 56 (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP 57 specific part of the Packet CS enables transport of IPv4 and IPv6 58 packets directly over the MAC. This document specifies the 59 addressing and operation of IPv6 over the IP specific part of the 60 packet CS for hosts served by a network that utilizes the IEEE Std 61 802.16 air interface. It recommends the assignment of a unique 62 prefix (or prefixes) to each host and allows the host to use multiple 63 identifiers within that prefix, including support for randomly 64 generated interface identifiers. 66 Table of Contents 68 1. Conventions used in this document . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. IEEE 802.16 convergence sublayer support for IPv6 . . . . . . 5 72 4.1. IPv6 encapsulation over the IP CS of the MAC . . . . . . . 7 73 5. Generic network architecture using the 802.16 air interface . 9 74 6. IPv6 link . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. IPv6 link in 802.16 . . . . . . . . . . . . . . . . . . . 10 76 6.2. IPv6 link establishment in 802.16 . . . . . . . . . . . . 11 77 6.3. Maximum transmission unit in 802.16 . . . . . . . . . . . 12 78 7. IPv6 prefix assignment . . . . . . . . . . . . . . . . . . . . 12 79 8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 12 81 8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 13 82 8.3. Router lifetime and periodic router advertisements . . . . 13 83 9. IPv6 addressing for hosts . . . . . . . . . . . . . . . . . . 13 84 9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 13 85 9.2. Duplicate address detection . . . . . . . . . . . . . . . 14 86 9.3. Stateless address autoconfiguration . . . . . . . . . . . 14 87 9.4. Stateful address autoconfiguration . . . . . . . . . . . . 14 88 10. Multicast Listener Discovery . . . . . . . . . . . . . . . . . 14 89 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 94 14.2. Informative References . . . . . . . . . . . . . . . . . . 16 95 Appendix A. WiMAX network architecture and IPv6 support . . . . . 16 96 Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 18 97 Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 19 98 Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 100 Intellectual Property and Copyright Statements . . . . . . . . . . 21 102 1. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Introduction 110 IEEE 802.16e is an air interface for fixed and mobile broadband 111 wireless access systems. Orthogonal Frequency Division Multiplexing 112 (OFDM) is the basis of the air interface. The standard specifies the 113 air interface, including the medium access control (MAC) layer and 114 multiple physical layer (PHY) specifications. It can be deployed in 115 licensed as well as unlicensed spectrum. While the PHY and MAC are 116 specified in IEEE 802.16, the details of IPv4 and IPv6 operation over 117 the air interface are not included. This document specifies the 118 operation of IPv6 over the IEEE 802.16 air interface. 120 IPv6 packets can be carried over the IEEE Std 802.16 specified air 121 interface via : 123 1. the IP specific part of the Packet CS or, 124 2. the 802.3 specific part of the Packet CS or, 125 3. the 802.1Q specific part of the Packet CS. 127 The 802.16 [802.16] specification includes the Phy and MAC details. 128 The convergence sublayers are a part of the MAC. This document 129 specifies IPv6 from the perspective of the transmission of IPv6 over 130 the IP specific part of the packet convergence sublayer. 132 The mobile station/host is attached to an access router via a base 133 station (BS). The host and the BS are connected via the IEEE Std 134 802.16 air interface at the link and physical layers. The IPv6 link 135 from the MS terminates at an access router which may be a part of the 136 BS or an entity beyond the BS. The base station is a layer 2 entity 137 (from the perspective of the IPv6 link between the MS and AR) and 138 relays the IPv6 packets between the AR and the host via a point-to- 139 point connection over the air interface. 141 3. Terminology 143 The terminology in this document is based on the definitions in 144 [PSDOC]. 146 4. IEEE 802.16 convergence sublayer support for IPv6 148 The IEEE 802.16 MAC specifies two main service specific convergence 149 sublayers: 151 1. ATM Convergence sublayer 152 2. Packet Convergence sublayer 154 The Packet CS is used for the transport of packet based protocols 155 which include: 157 1. IEEE Std 802.3(Ethernet) 158 2. IEEE Std 802.1Q(VLAN) 159 3. Internet Protocol (IPv4 and IPv6) 161 The service specific CS resides on top of the MAC Common Part 162 Sublayer (CPS). The service specific CS is responsible for: 164 o accepting packets (PDUs) from the upper layer, 165 o performing classification of the packet/PDU based on a set of 166 classifiers that are defined which are service specific, 167 o delivering the CS PDU to the appropriate service flow and 168 transport connection and, 169 o receiving PDUs from the peer entity. 171 Payload header suppression (PHS) is also a function of the CS but is 172 optional. 174 The figure below shows the concept of the service specific CS in 175 relation to the MAC: 177 -----------------------------\ 178 | ATM CS | Packet CS | \ 179 ----------------------------- \ 180 | MAC Common Part Sublayer | \ 181 | (Ranging, scheduling, etc)| 802.16 MAC 182 ----------------------------- / 183 | Security | / 184 |(Auth, encryption,key mgmt)| / 185 -----------------------------/ 186 | PHY | 187 ----------------------------- 189 Figure 1: The 802.16 MAC 191 Classifiers for each of the specific upper-layer protocols, i.e 192 Ethernet, VLAN and IP, are defined in the IEEE 802.16 specification, 193 which enable the packets from the upper layer to be processed by the 194 appropriate service specific part of the packet CS. IPv6 can be 195 transported directly over the IP specific part of the packet CS or 196 over 802.3/Ethernet (which in turn is handled by the Ethernet 197 specific part of the packet CS) or over 802.1Q (which is handled by 198 the 802.1Q specific part of the packet CS). IPv6 over the IP 199 specific part of the packet CS SHOULD be the default method for IPv6 200 packet transmission. IPv4 packets also are transported over the IP 201 specific part of the packet CS. The classifiers enable the 202 differntiation of IPv4 and IPv6 packets and mapping to specific 203 transport connections over the air-interface. 205 The figure below shows the options for IPv6 transport over the packet 206 CS of 802.16: 208 ----------------- ----------------- 209 | IPv6 | | IPv6 | 210 ---------------- |---------------| |----------- | 211 | IPv6 | | Ethernet | | 802.1Q | 212 |--------------| |---------------| |----------- | 213 | IP Specific | | 802.3 specific| |802.1Q specific| 214 |part of Pkt CS| |part of Pkt CS | |part of Pkt CS | 215 |..............| |...............| |...............| 216 | MAC | | MAC | | MAC | 217 |--------------| |---------------| |---------------| 218 | PHY | | PHY | | PHY | 219 ---------------- ----------------- ----------------- 221 (1) IPv6 over (2) IPv6 over (3) IPv6 over 222 IP Specific part 802.3/Ethernet 802.1Q 223 of Packet CS 225 Figure 2: IPv6 over IP, 802.3 and 802.1Q specific parts of the Packet 226 CS 228 The scope of this document is limited to IPv6 operation over the IP 229 specific part of the Packet CS only. IPv4 over the IP specific part 230 of the packet CS is specified in [IPv4CS]. It should be noted that 231 immediately after ranging (802.16 air interface procedure), the MS 232 and BS exchange their capability negotiation via REG-REQ 233 (Registration Request) and REG-RSP (Registration Response) 802.16 MAC 234 messages. These management frames negotiate parameters such as the 235 Convergence Sublayer support. By default, Packet, IPv4 and 802.3/ 236 Ethernet are supported. IPv6 via the Packet CS is supported by the 237 MS and the BS only when the IPv6 support bit in the capability 238 negotiation messages (REG-REQ and REG-RSP) implying such support is 239 indicated in the parameter "Classification/PHS options and SDU 240 (Service Data Unit) encapsulation support" (Refer to [802.16]). 241 Additionally during the establishment of the transport connection for 242 transporting IPv6 packets, the DSA-REQ (Dynamic Service Addition) and 243 DSA-RSP messages between the BS and MS indicate via the CS- 244 Specification TLV the CS that the connection being setup shall use. 245 When the IPv6 packet is preceded by the 802.16 six byte MAC header 246 there is no specific indication in the MAC header itself about the 247 payload type. The processing of the packet is based entirely on the 248 classifiers. Based on the classification rules, the MAC layer 249 selects an appropriate transport connection for the transmission of 250 the packet. An IPv6 packet is transported over a transport 251 connection that is specifically established for carrying such 252 packets. 254 Transmission of IPv6 as explained above is possible via multiple 255 methods, i.e, via the IP specific part of the packet CS or via 256 Ethernet or 802.1Q interfaces. The choice of which method to use is 257 implementation specific. When IPv6 is carried via the IP convergence 258 sublayer, this specification SHOULD be followd. In order to ensure 259 interoperability the BS SHOULD support the IP specific part of the 260 packet CS and the Ethernet specific part of the packet CS for IPv6 261 transport. Hosts which may implement one or the other method for 262 transmission would be assured of the ability to establish a transport 263 connection that would enable the transport of IPv6 packets. 264 Inability to negotiate a common convergence sublayer for the 265 transport connection between the MS and BS will result in failure to 266 setup the transport connection and thereby render the host unable to 267 send and receive IPv6 packets. In the case of a host which 268 implements more than one method of transporting IPv6 packets, the 269 choice of which method to use (i.e IPv6 over the IP specific part of 270 the packet CS or IPv6 over 802.3 or, IPv6 over 802.1Q) is 271 implementation specific. The host and the BS SHOULD support the 272 transmission of IPv6 over the IP specific part of the packet 273 convergence sublayer. The default method for IPv6 packet 274 transmission over 802.16 should be via the packet CS. 276 4.1. IPv6 encapsulation over the IP CS of the MAC 278 The IPv6 payload when carried over the IP specific part of the Packet 279 CS is encapsulated by the 6 byte 802.16 generic MAC header. The 280 format of the IPv6 packet encapsulated by the generic MAC header is 281 shown in the figure below. The format of the 6 byte MAC header is 282 described in the [802.16] specification. The CRC (cyclic redundancy 283 check) is optional. It should be noted that the actual MAC address 284 is not included in the MAC header. 286 ---------/ /----------- 287 | MAC SDU | 288 --------/ /------------ 289 || 290 || 291 MSB \/ LSB 292 --------------------------------------------------------- 293 | Generic MAC header| IPv6 Payload | CRC | 294 --------------------------------------------------------- 296 Figure 3: IPv6 encapsulation 298 For transmission of IPv6 packets via the IP specific part of the 299 Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC 300 directly. The IPv6 layer delivers the IPv6 packet to the Packet CS 301 of the 802.16. The packet CS defines a set of classifiers that are 302 used to determine how to handle the packet. The IP classifiers that 303 are used at the MAC operate on the fields of the IP header and the 304 transport protocol and these include the IP Traffic class, Next 305 header field, Masked IP source and destination addresses and, 306 Protocol source and destination port ranges. Next header in this 307 case refers to the last header of the IP header chain. Using the 308 classifiers, the MAC maps an upper layer packet to a specific service 309 flow and transport connection to be used. The MAC encapsulates the 310 IPv6 packet in the 6 byte MAC header (MAC SDU) and transmits it. The 311 figure below shows the operation on the downlink, i.e the 312 transmission from the BS to the host. The reverse is applicable for 313 the uplink transmission. 315 ----------- ---------- 316 | IPv6 Pkt| |IPv6 Pkt| 317 ----------- ---------- 318 | | /|\ 319 | | | 320 --[SAP]--------------------- ---------[SAP]-------- 321 ||-| |----------| | | /|\ | 322 || \ / 0---->[CID1] | | --- |-------- | 323 || Downlink 0\/-->[CID2] | | |Reconstruct| | 324 || classifiers0/\-->[....] | | | (undo PHS)| | 325 || 0---->[CIDn] | | --- ------- | 326 ||--------------| | | /|\ | 327 | | | | | 328 | {SDU, CID,..} | | {SDU, CID,..} | 329 | | | | /|\ | 330 | v | | | | 331 ------[SAP]----------------- |-------[SAP]--------- 332 | 802.16 MAC CPS |------>| 802.16 MAC CPS | 333 ---------------------------- ---------------------- 335 Figure 4: IPv6 packet transmission: Downlink 337 5. Generic network architecture using the 802.16 air interface 339 In a network that utilizes the 802.16 air interface the host/MS is 340 attached to an IPv6 access router (AR) in the network. The BS is a 341 layer 2 entity only. The AR can be an integral part of the BS or the 342 AR could be an entity beyond the BS within the access network. IPv6 343 packets between the MS and BS are carried over a point-to-point 344 transport connection which has a unique connection identifier (CID). 345 The transport connection is a MAC layer link between the MS and the 346 BS. The figures below describe the possible network architectures 347 and are generic in nature. More esoteric architectures are possible 348 but not considered in the scope of this document. Option A: 350 +-----+ CID1 +--------------+ 351 | MS1 |------------/| BS/AR |-----[Internet] 352 +-----+ / +--------------+ 353 . /---/ 354 . CIDn 355 +-----+ / 356 | MSn |---/ 357 +-----+ 358 Figure 5: The IPv6 AR as an integral part of the BS 360 Option B: 362 +-----+ CID1 +-----+ +-----------+ 363 | MS1 |----------/| BS1 |----------| AR |-----[Internet] 364 +-----+ / +-----+ +-----------+ 365 . / ____________ 366 . CIDn / ()__________() 367 +-----+ / L2 Tunnel 368 | MSn |-----/ 369 +-----+ 371 Figure 6: The IPv6 AR is separate from the BS 373 The above network models serve as examples and are shown to 374 illustrate the point to point link between the MS and the AR. 376 6. IPv6 link 378 RFC 2461 defines link as a communication facility or medium over 379 which nodes can communicate at the link layer, i.e., the layer 380 immediately below IP [RFC2461]. A link is bounded by routers that 381 decrement the Hop limit field in the IPv6 header. When an MS moves 382 within a link, it can keep using its IP addresses. This is a layer 3 383 definition and note that the definition is not identical with the 384 definition of the term '(L2) link' in IEEE 802 standards. 386 6.1. IPv6 link in 802.16 388 In 802.16, the Transport Connection between an MS and a BS is used to 389 transport user data, i.e. IPv6 packets in this case. A Transport 390 Connection is represented by a CID (Connection Identifier) and 391 multiple Transport Connections can exist between an MS and BS. 393 When an AR and a BS are collocated, the collection of Transport 394 Connections to an MS is defined as a single link. When an AR and a 395 BS are separated, it is recommended that a tunnel is established 396 between the AR and a BS whose granuality is no greater than 'per MS' 397 or 'per service flow' ( An MS can have multiple service flows which 398 are identified by a service flow ID). Then the tunnel(s) for an MS, 399 in combination with the MS's Transport connections, forms a single 400 point-to-point link. 402 The collection of service flows (tunnels) to an MS is defined as a 403 single link. Each link has only an MS and an AR. Each MS belongs to 404 a different link. A different prefix should be assigned to each 405 unique link. This link is fully consistent with a standard IP link, 406 without exception and conforms with the definition of a point-to- 407 point link in RFC2461 [RFC2461]. Hence the point-to-point link model 408 for IPv6 operation over the IP specific part of the Packet CS in 409 802.16 SHOULD be used. A unique IPv6 prefix(es) per link (MS/host) 410 MUST be assigned. 412 6.2. IPv6 link establishment in 802.16 414 In order to enable the sending and receiving of IPv6 packets between 415 the MS and the AR, the link between the MS and the AR via the BS 416 needs to be established. This section illustrates the link 417 establishment procedure. 419 The MS goes through the network entry procedure as specified by 420 802.16. A high level description of the network entry procedure is 421 as follows: 423 1. MS performs initial ranging with the BS. Ranging is a process by 424 which an MS becomes time aligned with the BS. The MS is 425 synchronized with the BS at the succesful completion of ranging 426 and is ready to setup a connection. 427 2. MS and BS perform capability exchange as per 802.16 procedures. 428 The CS capability parameter indicates which classification/PHS 429 options and SDU encapsulation the MS supports. By default, 430 Packet, IPv4 and 802.3/Ethernet shall be supported, thus absence 431 of this parameter in REG-REQ (802.16 message) means that named 432 options are supported by the MS/SS. Support for IPv6 over the IP 433 specific part of the packet CS is indicated by Bit#2 of the CS 434 capability parameter (Refer to [802.16]). 435 3. The MS progresses to an authentication phase. Authentication is 436 based on PKMv2 as defined in the IEEE Std 802.16 specification. 437 4. On succesful completion of authentication, the MS performs 802.16 438 registration with the network. 439 5. The MS MUST request the establishment of a service flow for IPv6 440 packets over the IP specific part of the Packet CS. The service 441 flow MAY also be triggered by the network as a result of pre- 442 provisioning. The service flow establishes a link between the MS 443 and the AR over which IPv6 packets can be sent and received. 444 6. The AR and MS should send router advertisements and solicitations 445 as specified in Neighbor discovery, RFC2461 [RFC2461]. 447 The above flow does not show the actual 802.16 messages that are used 448 for ranging, capability exchange or service flow establishment. 449 Details of these are in [802.16]. 451 6.3. Maximum transmission unit in 802.16 453 The 802.16 MAC PDU (Protocol Data Unit) is composed by a 6 byte 454 header followed by an optional payload and an optional CRC covering 455 the header and the payload. The length of the PDU is indicated by 456 the Len parameter in the Generic MAC Header. The Len parameter has a 457 size of 11 bits. Hence the total PDU size is 2048 bytes. The IPv6 458 payload can be a max value of 2038 bytes ( Total PDU size minus (MAC 459 Header + CRC)). The Max value of the IPv6 MTU for 802.16 is 2038 460 bytes and the minimum value of 1280 bytes. The default MTU for IPv6 461 over 802.16 SHOULD be the same as specified in RFC2460 which is 1500 462 octets. RFC2461 defines an MTU option that an AR can advertise to an 463 MN. If an AR advertises an MTU via the RA MTU option, the MN SHOULD 464 use the MTU from the RA. 466 7. IPv6 prefix assignment 468 The MS and the AR are connected via a point-to-point connection at 469 the IPv6 layer. Hence each MS can be considered to be on a separate 470 subnet. A CPE (Customer Premise Equipment) type of device which 471 serves multiple IPv6 hosts, may be the end point of the connection. 472 Hence one or more /64 prefixes SHOULD be assigned to a link. The 473 prefixes are advertised with the on-link (L-bit) flag set as 474 specified in RFC2461 [RFC2461]. The size and number of the prefixes 475 is a configuration issue. Also, prefix delegation MAY be used to 476 provide additional prefixes for a router connected over 802.16. The 477 other properties of the prefixes are also dealt via configuration. 479 8. Router Discovery 481 8.1. Router Solicitation 483 On completion of the establishment of the IPv6 link, the MS may send 484 a router solicitation message to solicit a Router Advertisement 485 message from the AR to acquire necessary information as per RFC2461. 486 An MS that is network attached may also send router solicitations at 487 any time as per RFC2461. Movement detection at the IP layer of an MS 488 in many cases is based on receiving periodic router advertisements. 489 An MS may also detect changes in its attachment via link triggers or 490 other means. The MS can act on such triggers by sending router 491 solicitations. The router solicitation is sent over the IPv6 link 492 that has been previously established. The MS sends router 493 solicitations to the all-routers multicast address. It is carried 494 over the point-to-point link to the AR via the BS. The MS does not 495 need to be aware of the link-local address of the AR in order to send 496 a router solicitation at any time. 498 8.2. Router Advertisement 500 The AR should send a number (configurable value) of router 501 advertisements as soon as the IPv6 link is established, to the MS. 502 The AR sends unsolicited router advertisements periodically as per 503 RFC2461. The interval between periodic router advertisements is 504 however greater than the specification in RFC2461 and is discussed in 505 the following section. 507 8.3. Router lifetime and periodic router advertisements 509 The router lifetime SHOULD be set to a large value, preferably in 510 hours. This document over-rides the specification for the value of 511 the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) 512 RFC2461 [RFC2461]. The AdvDefaultLifetime in the router 513 advertisement MUST be either zero or between MaxRtrAdvInterval and 514 43200 seconds. The default value is 2 * MaxRtrAdvInterval. 516 802.16 hosts have the capability to transition to an idle mode in 517 which case the radio link between the BS and MS is torn down. Paging 518 is required in case the network needs to deliver packets to the MS. 519 In order to avoid waking a mobile which is in idle mode and consuming 520 resources on the air interface, the interval between periodic router 521 advertisements SHOULD be set quite high. The MaxRtrAdvInterval value 522 specified in this document over-rides the recommendation in Neighbor 523 Discovery for IP Version 6 (IPv6) RFC2461 [RFC2461]. The 524 MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 525 21600 seconds. The default value for MaxRtrAdvInterval is 10800 526 seconds. 528 9. IPv6 addressing for hosts 530 The addressing scheme for IPv6 hosts in 802.16 network follows the 531 IETFs recommendation for hosts specified in IPv6 Node Requirement, 532 RFC 4294. The IPv6 node requirements RFC4294 [RFC4294] specifies a 533 set of RFCs that are applicable for addressing and the same is 534 applicable for hosts that use 802.16 as the link layer for 535 transporting IPv6 packets. 537 9.1. Interface Identifier 539 The MS has a 48-bit MAC address as specified in 802.16 [802.16]. 540 This MAC address MUST be used if EUI-64 based interface identifier is 541 needed for autoconfiguration, IP Version 6 Addressing Architecture 542 RFC4291 [RFC4291]. As in other links that support IPv6, EUI-64 based 543 interface identifiers are not mandatory and other mechanisms, such as 544 random interface identifiers, Privacy Extensions for Stateless 545 Address Autoconfiguration in IPv6 RFC3041 [RFC3041] MAY also be used. 547 9.2. Duplicate address detection 549 DAD SHOULD be performed as per Neighbor Discovery for IP Version 550 6,RFC2461 [RFC2461] and, IPv6 Stateless Address Autoconfiguration, 551 RFC2462 [RFC2462]. It MAY be redundant to perform DAD on a global 552 unicast address that is configured using the EUI-64 or generated as 553 per RFC3041 [RFC3041] for the interface as part of the IPv6 stateless 554 address autoconfiguration protocol RFC2462 [RFC2462] as long as the 555 following two conditions are met: 557 1. The prefixes advertised through the router advertisement messages 558 by the access router terminating the 802.16 IPv6 link is unique 559 to that link. 560 2. The access router terminating the 802.16 IPv6 link does not 561 autoconfigure any IPv6 global unicast addresses from the prefix 562 that it advertises. 564 9.3. Stateless address autoconfiguration 566 If the A-bit in the prefix information option (PIO) is set, the MS 567 SHOULD perform stateless address autoconfiguration as per RFC 2461, 568 2462. The AR is the default router that advertises a unique prefix 569 (or prefixes) that is used by the MS to configure an address. 571 9.4. Stateful address autoconfiguration 573 The Stateful Address Autoconfiguration is invoked if the M-flag is 574 set in the Router Advertisement. Obtaining the IPv6 address through 575 stateful address autoconfiguration method is specified in RFC3315 576 [RFC3315]. The MS MUST obtain an address via the stateful address 577 autoconfiguration mechanism when the M-flag is set in the router 578 advertisement. 580 10. Multicast Listener Discovery 582 Multicast Listener Discovery Version 2(MLDv2) for IPv6 RFC3810 583 [RFC3810] SHOULD be supported as specified by the hosts and routers 584 attached to each other via an 802.16 link. The access router which 585 has hosts attached to it via a Point-to-point link over an 802.16 586 SHOULD not send periodic queries if the host is in idle/dormant mode. 587 The AR can obtain information about the state of a host from the 588 paging controller in the network. 590 11. IANA Considerations 592 This draft does not require any actions from IANA. 594 12. Security Considerations 596 This document does not introduce any new vulnerabilities to IPv6 597 specifications or operation. The security of the 802.16 air 598 interface is the subject of [802.16]. In addition, the security 599 issues of the network architecture spanning beyond the 802.16 base 600 stations is the subject of the documents defining such architectures, 601 such as WiMAX Network Architecture [WiMAXArch]. 603 13. Acknowledgments 605 The authors would like to acknowledge the contributions of the 16NG 606 working group chairs Soohong Daniel Park and Gabriel Montenegro as 607 well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ 608 Johnston, Dave Thaler, Bruno Sousa, Alexandru Petrescu, Margaret 609 Wasserman and Pekka Savola for their review and comments. 611 14. References 613 14.1. Normative References 615 [802.16] "IEEE Std 802.16e: IEEE Standard for Local and 616 metropolitan area networks, Amendment for Physical and 617 Medium Access Control Layers for Combined Fixed and Mobile 618 Operation in Licensed Bands", October 2005. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", RFC 2119, March 1997, 622 . 624 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 625 Discovery for IP Version 6 (IPv6)", RFC 2461, 626 December 1998, . 628 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 629 Autoconfiguration", RFC 2462, December 1998, 630 . 632 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 633 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, 634 . 636 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 637 Architecture", RFC 4291, February 2006, 638 . 640 14.2. Informative References 642 [IPv4CS] Madanapalli, S. and S. Park, "Transmission of IPv4 packets 643 over 802.16's IP Convergence Sublayer", February 2007, . 647 [PSDOC] Jee, J., Madanapalli, S., Montenegro, G., Riegel, M., 648 Mandin, J., and S. Park, "IP over 802.16 Problem Statement 649 and Goals", October 2006, . 652 [RFC3041] Narten, T., Draves, R., and S. Krishnan, "Privacy 653 Extensions for Stateless Address Autoconfiguration in 654 IPv6", August 2006, . 657 [RFC3315] Droms, Ed., R., Bound, J., Volz, B., Lemon, T., Perkins, 658 C., and M. Carney, "Dynamic Host Configuration Protocol 659 for IPv6 (DHCPv6)", RFC 3315, July 2003, 660 . 662 [RFC4294] Loughney, Ed., J., "IPv6 Node requirements", RFC 4294, 663 April 2006, . 665 [WMF] "http://www.wimaxforum.org". 667 [WiMAXArch] 668 "WiMAX End-to-End Network Systems Architecture 669 http://www.wimaxforum.org/technology/documents", 670 August 2006. 672 Appendix A. WiMAX network architecture and IPv6 support 674 The WiMAX (Worldwide Interoperability for Microwave Access) forum 675 [WMF] has defined a network architecture in which the air interface 676 is based on the IEEE 802.16 standard. The addressing and operation 677 of IPv6 described in this document is applicable to the WiMAX network 678 as well. 680 The WiMAX network architecture consists of the Access Service Network 681 (ASN) and the Connectivity Service Network (CSN). The ASN is the 682 access network which includes the BS and the AR in addition to other 683 functions such as AAA, Mobile IP Foreign agent, Paging controller, 684 Location Register etc. The ASN is defined as a complete set of 685 network functions needed to provide radio access to a WiMAX 686 subscriber. The ASN is the access network to which the MS attaches. 687 The IPv6 access router is an entity within the ASN. The term ASN is 688 specific to the WiMAX network architecture. The CSN is the entity 689 that provides connectivity to the Internet and includes functions 690 such as Mobile IP Home agent and AAA. The figure below shows the 691 WiMAX reference model: 693 ------------------- 694 | ---- ASN | |----| 695 ---- | |BS|\ R6 -------| |---------| | CSN| 696 |MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | | 697 ---- | |R8 /--|------|----| |-----|Home| 698 | ---- / | | visited| | NSP| 699 | |BS|/ | | NSP | | | 700 | ---- | |---------| | | 701 | NAP | \ |----| 702 ------------------- \---| / 703 | | / 704 | (--|------/----) 705 |R4 ( ) 706 | ( ASP network ) 707 --------- ( or Internet ) 708 | ASN | ( ) 709 --------- (----------) 711 Figure 7: WiMAX Network reference model 713 Three different types of ASN realizations called profiles are defined 714 by the architecture. ASNs of profile types A and C include BS' and 715 ASN-gateway(s) (ASN-GW) which are connected to each other via an R6 716 interface. An ASN of profile type B is one in which the 717 functionality of the BS and other ASN functions are merged together. 718 No ASN-GW is specifically defined in a profile B ASN. The absence of 719 the R6 interface is also a profile B specific characteristic. The MS 720 at the IPv6 layer is associated with the AR in the ASN. The AR may 721 be a function of the ASN-GW in the case of profiles A and C and is a 722 function in the ASN in the case of profile B. When the BS and the AR 723 are separate entities and linked via the R6 interface, IPv6 packets 724 between the BS and the AR are carried over a GRE tunnel. The 725 granularity of the GRE tunnel should be on a per MS basis or on a per 726 service flow basis (an MS can have multiple service flows, each of 727 which are identified uniquely by a service flow ID). The protocol 728 stack in WiMAX for IPv6 is shown below: 730 |-------| 731 | App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 732 | | 733 |-------| /------ ------- 734 | | / IPv6 | | | 735 | IPv6 |- - - - - - - - - - - - - - - - / | | |--> 736 | | --------------- -------/ | | IPv6| 737 |-------| | \Relay/ | | | |- - - | | 738 | | | \ / | | GRE | | | | 739 | | | \ /GRE | - | | | | | 740 | |- - - | |-----| |------| | | | 741 | IPv6CS| |IPv6CS | IP | - | IP | | | | 742 | ..... | |...... |-----| |------|--------| |-----| 743 | MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 | 744 |-------| |------ |-----| |----- |--------| |-----| 745 | PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 | 746 -------- --------------- ----------------- ------- 748 MS BS AR/ASN-GW CSN Rtr 750 Figure 8: WiMAX protocol stack 752 As can be seen from the protocol stack description, the IPv6 end- 753 points are constituted in the MS and the AR. The BS provides lower 754 layer connectivity for the IPv6 link. 756 Appendix B. IPv6 link in WiMAX 758 WiMAX is an example of a network based on the IEEE Std 802.16 air 759 interface. This section describes the IPv6 link in the context of a 760 WiMAX network. The MS and the AR are connected via a combination of 761 : 763 1. The transport connection which is identified by a Connection 764 Identifier (CID) over the air interface, i.e the MS and BS and, 765 2. A GRE tunnel between the BS and AR which transports the IPv6 766 packets 768 From an IPv6 perspective the MS and the AR are connected by a point- 769 to-point link. The combination of transport connection over the air 770 interface and the GRE tunnel between the BS and AR creates a (point- 771 to-point) tunnel at the layer below IPv6. 773 The collection of service flows (tunnels) to an MS is defined as a 774 single link. Each link has only an MS and an AR. Each MS belongs to 775 a different link. No two MSs belong to the same link. A different 776 prefix should be assigned to each unique link. This link is fully 777 consistent with a standard IP link, without exception and conforms 778 with the definition of a point-to-point link in RFC2461 [RFC2461]. 780 Appendix C. IPv6 link establishment in WiMAX 782 The mobile station performs initial network entry as specified in 783 802.16. On succesful completion of the network entry procedure the 784 ASN gateway/AR triggers the establishment of the initial service flow 785 (ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the 786 ASN-GW/AR and the BS. The BS in turn requests the MS to establish a 787 transport connection over the air interface. The end result is a 788 transport connection over the air interface for carrying IPv6 packets 789 and a GRE tunnel between the BS and AR for relaying the IPv6 packets. 790 On succesful completion of the establishment of the ISF, IPv6 packets 791 can be sent and received between the MS and AR. The ISF enables the 792 MS to communicate with the AR for host configuration procedures. 793 After the establishment of the ISF, the AR can send a router 794 advertisement to the MS. An MS can establish multiple service flows 795 with different QoS characteristics. The ISF can be considered as the 796 primary service flow. The ASN-GW/ AR treats each ISF, along with the 797 other service flows to the same MS, as a unique link which is managed 798 as a (virtual) interface. 800 Appendix D. Maximum transmission unit in WiMAX 802 The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. 803 Hence the IPv6 path MTU can be 1500 octets. However because of the 804 overhead of the GRE tunnel used to transport IPv6 packets between the 805 BS and AR and the 6 byte MAC header over the air interface, using a 806 value of 1500 would result in fragmentation of packets. It is 807 recommended that the default MTU for IPv6 be set to 1400 octets for 808 the MS in WiMAX networks. Note that the 1522 octet specification is 809 a WiMAX forum specification and not the size of the SDU that can be 810 transmitted over 802.16, which has a higher limit. 812 Authors' Addresses 814 Basavaraj Patil 815 Nokia 816 6000 Connection Drive 817 Irving, TX 75039 818 USA 820 Email: basavaraj.patil@nokia.com 822 Frank Xia 823 Huawei USA 824 1700 Alma Dr. Suite 100 825 Plano, TX 75075 827 Email: xiayangsong@huawei.com 829 Behcet Sarikaya 830 Huawei USA 831 1700 Alma Dr. Suite 100 832 Plano, TX 75075 834 Email: sarikaya@ieee.org 836 JinHyeock Choi 837 Samsung AIT 838 Networking Technology Lab 839 P.O.Box 111 840 Suwon, Korea 440-600 842 Email: jinchoe@samsung.com 844 Syam Madanapalli 845 LogicaCMG 846 125 Yemlur P.O. 847 Off Airport Road 848 Bangalore, India 560037 850 Email: smadanapalli@gmail.com 852 Full Copyright Statement 854 Copyright (C) The IETF Trust (2007). 856 This document is subject to the rights, licenses and restrictions 857 contained in BCP 78, and except as set forth therein, the authors 858 retain all their rights. 860 This document and the information contained herein are provided on an 861 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 862 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 863 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 864 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 865 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 866 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 868 Intellectual Property 870 The IETF takes no position regarding the validity or scope of any 871 Intellectual Property Rights or other rights that might be claimed to 872 pertain to the implementation or use of the technology described in 873 this document or the extent to which any license under such rights 874 might or might not be available; nor does it represent that it has 875 made any independent effort to identify any such rights. Information 876 on the procedures with respect to rights in RFC documents can be 877 found in BCP 78 and BCP 79. 879 Copies of IPR disclosures made to the IETF Secretariat and any 880 assurances of licenses to be made available, or the result of an 881 attempt made to obtain a general license or permission for the use of 882 such proprietary rights by implementers or users of this 883 specification can be obtained from the IETF on-line IPR repository at 884 http://www.ietf.org/ipr. 886 The IETF invites any interested party to bring to its attention any 887 copyrights, patents or patent applications, or other proprietary 888 rights that may cover technology that may be required to implement 889 this standard. Please address the information to the IETF at 890 ietf-ipr@ietf.org. 892 Acknowledgment 894 Funding for the RFC Editor function is provided by the IETF 895 Administrative Support Activity (IASA).