idnits 2.17.1 draft-ietf-16ng-ipv6-over-ipv6cs-09.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 888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 912. 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 [I-D.ietf-ipv6-2461bis] 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 12, 2007) is 6248 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) == Unused Reference: 'RFC3810' is defined on line 650, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-04) exists of draft-ietf-16ng-ps-goals-01 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- 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: 2 errors (**), 0 flaws (~~), 4 warnings (==), 10 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 Siemens Networks 4 Intended status: Standards Track Frank Xia 5 Expires: September 13, 2007 Behcet Sarikaya 6 Huawei USA 7 JH. Choi 8 Samsung AIT 9 Syam Madanapalli 10 LogicaCMG 11 March 12, 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-09 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 13, 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 802.3 LAN/MAN CSMA/CD Access Method (Ethernet) and, IEEE 57 Std 802.1Q (VLAN). The IP specific part of the Packet CS enables 58 transport of IPv4 and IPv6 packets directly over the MAC. This 59 document specifies the addressing and operation of IPv6 over the IP 60 specific part of the packet CS for hosts served by a network that 61 utilizes the IEEE Std 802.16 air interface. It recommends the 62 assignment of a unique prefix (or prefixes) to each host and allows 63 the host to use multiple identifiers within that prefix, including 64 support for randomly 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 . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 15 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 . . . . . 17 96 Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 19 97 Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 19 98 Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 20 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 100 Intellectual Property and Copyright Statements . . . . . . . . . . 22 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 [802.3] specific part of the Packet CS or, 125 3. the 802.1Q [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 IP 144 over 802.16 Problem Statement and Goals [I-D.ietf-16ng-ps-goals]. 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 differentiation 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. Hence, the resulting interface 230 is capable of IPv6 only. IPv4 over the IP specific part of the 231 packet CS is specified elsewhere by the 16ng WG, and the resulting 232 interface is capable of IPv4 only. A host with both types of 233 interfaces is therefore a dual-stack host. 235 It should be noted that immediately after ranging (802.16 air 236 interface procedure), the MS and BS exchange their capability 237 negotiation via REG-REQ (Registration Request) and REG-RSP 238 (Registration Response) 802.16 MAC messages. These management frames 239 negotiate parameters such as the Convergence Sublayer support. By 240 default, Packet, IPv4 and 802.3/Ethernet are supported. IPv6 via the 241 Packet CS is supported by the MS and the BS only when the IPv6 242 support bit in the capability negotiation messages (REG-REQ and REG- 243 RSP) implying such support is indicated in the parameter 244 "Classification/PHS options and SDU (Service Data Unit) encapsulation 245 support" (Refer to [802.16]). Additionally during the establishment 246 of the transport connection for transporting IPv6 packets, the DSA- 247 REQ (Dynamic Service Addition) and DSA-RSP messages between the BS 248 and MS indicate via the CS-Specification TLV the CS that the 249 connection being setup shall use. When the IPv6 packet is preceded 250 by the 802.16 six byte MAC header there is no specific indication in 251 the MAC header itself about the payload type. The processing of the 252 packet is based entirely on the classifiers. Based on the 253 classification rules, the MAC layer selects an appropriate transport 254 connection for the transmission of the packet. An IPv6 packet is 255 transported over a transport connection that is specifically 256 established for carrying such packets. 258 Transmission of IPv6 as explained above is possible via multiple 259 methods, i.e, via the IP specific part of the packet CS or via 260 Ethernet or 802.1Q interfaces. The choice of which method to use is 261 implementation specific. When IPv6 is carried via the IP convergence 262 sublayer, this specification SHOULD be followed. In order to ensure 263 interoperability the BS SHOULD support the IP specific part of the 264 packet CS and the Ethernet specific part of the packet CS for IPv6 265 transport. Hosts which may implement one or the other method for 266 transmission would be assured of the ability to establish a transport 267 connection that would enable the transport of IPv6 packets. 268 Inability to negotiate a common convergence sublayer for the 269 transport connection between the MS and BS will result in failure to 270 setup the transport connection and thereby render the host unable to 271 send and receive IPv6 packets. In the case of a host which 272 implements more than one method of transporting IPv6 packets, the 273 choice of which method to use (i.e IPv6 over the IP specific part of 274 the packet CS or IPv6 over 802.3 or, IPv6 over 802.1Q) is 275 implementation specific. The host and the BS SHOULD support the 276 transmission of IPv6 over the IP specific part of the packet 277 convergence sublayer. The default method for IPv6 packet 278 transmission over 802.16 should be via the packet CS. 280 4.1. IPv6 encapsulation over the IP CS of the MAC 282 The IPv6 payload when carried over the IP specific part of the Packet 283 CS is encapsulated by the 6 byte 802.16 generic MAC header. The 284 format of the IPv6 packet encapsulated by the generic MAC header is 285 shown in the figure below. The format of the 6 byte MAC header is 286 described in the [802.16] specification. The CRC (cyclic redundancy 287 check) is optional. It should be noted that the actual MAC address 288 is not included in the MAC header. 290 ---------/ /----------- 291 | MAC SDU | 292 --------/ /------------ 293 || 294 || 295 MSB \/ LSB 296 --------------------------------------------------------- 297 | Generic MAC header| IPv6 Payload | CRC | 298 --------------------------------------------------------- 300 Figure 3: IPv6 encapsulation 302 For transmission of IPv6 packets via the IP specific part of the 303 Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC 304 directly. The IPv6 layer delivers the IPv6 packet to the Packet CS 305 of the 802.16. The packet CS defines a set of classifiers that are 306 used to determine how to handle the packet. The IP classifiers that 307 are used at the MAC operate on the fields of the IP header and the 308 transport protocol and these include the IP Traffic class, Next 309 header field, Masked IP source and destination addresses and, 310 Protocol source and destination port ranges. Next header in this 311 case refers to the last header of the IP header chain. Using the 312 classifiers, the MAC maps an upper layer packet to a specific service 313 flow and transport connection to be used. The MAC encapsulates the 314 IPv6 packet in the 6 byte MAC header (MAC SDU) and transmits it. The 315 figure below shows the operation on the downlink, i.e the 316 transmission from the BS to the host. The reverse is applicable for 317 the uplink transmission. 319 ----------- ---------- 320 | IPv6 Pkt| |IPv6 Pkt| 321 ----------- ---------- 322 | | /|\ 323 | | | 324 --[SAP]--------------------- ---------[SAP]-------- 325 ||-| |----------| | | /|\ | 326 || \ / 0---->[CID1] | | --- |-------- | 327 || Downlink 0\/-->[CID2] | | |Reconstruct| | 328 || classifiers0/\-->[....] | | | (undo PHS)| | 329 || 0---->[CIDn] | | --- ------- | 330 ||--------------| | | /|\ | 331 | | | | | 332 | {SDU, CID,..} | | {SDU, CID,..} | 333 | | | | /|\ | 334 | v | | | | 335 ------[SAP]----------------- |-------[SAP]--------- 336 | 802.16 MAC CPS |------>| 802.16 MAC CPS | 337 ---------------------------- ---------------------- 338 BS MS 340 Figure 4: IPv6 packet transmission: Downlink 342 5. Generic network architecture using the 802.16 air interface 344 In a network that utilizes the 802.16 air interface the host/MS is 345 attached to an IPv6 access router (AR) in the network. The BS is a 346 layer 2 entity only. The AR can be an integral part of the BS or the 347 AR could be an entity beyond the BS within the access network. IPv6 348 packets between the MS and BS are carried over a point-to-point 349 transport connection which has a unique connection identifier (CID). 350 The transport connection is a MAC layer link between the MS and the 351 BS. The figures below describe the possible network architectures 352 and are generic in nature. More esoteric architectures are possible 353 but not considered in the scope of this document. Option A: 355 +-----+ CID1 +--------------+ 356 | MS1 |------------/| BS/AR |-----[Internet] 357 +-----+ / +--------------+ 358 . /---/ 359 . CIDn 360 +-----+ / 361 | MSn |---/ 362 +-----+ 363 Figure 5: The IPv6 AR as an integral part of the BS 365 Option B: 367 +-----+ CID1 +-----+ +-----------+ 368 | MS1 |----------/| BS1 |----------| AR |-----[Internet] 369 +-----+ / +-----+ +-----------+ 370 . / ____________ 371 . CIDn / ()__________() 372 +-----+ / L2 Tunnel 373 | MSn |-----/ 374 +-----+ 376 Figure 6: The IPv6 AR is separate from the BS 378 The above network models serve as examples and are shown to 379 illustrate the point to point link between the MS and the AR. 381 6. IPv6 link 383 Neighbor Discovery for IP Version 6 [I-D.ietf-ipv6-2461bis] defines 384 link as a communication facility or medium over which nodes can 385 communicate at the link layer, i.e., the layer immediately below IP . 386 A link is bounded by routers that decrement the Hop limit field in 387 the IPv6 header. When an MS moves within a link, it can keep using 388 its IP addresses. This is a layer 3 definition and note that the 389 definition is not identical with the definition of the term '(L2) 390 link' in IEEE 802 standards. 392 6.1. IPv6 link in 802.16 394 In 802.16, the Transport Connection between an MS and a BS is used to 395 transport user data, i.e. IPv6 packets in this case. A Transport 396 Connection is represented by a CID (Connection Identifier) and 397 multiple Transport Connections can exist between an MS and BS. 399 When an AR and a BS are collocated, the collection of Transport 400 Connections to an MS is defined as a single link. When an AR and a 401 BS are separated, it is recommended that a tunnel is established 402 between the AR and a BS whose granuality is no greater than 'per MS' 403 or 'per service flow' ( An MS can have multiple service flows which 404 are identified by a service flow ID). Then the tunnel(s) for an MS, 405 in combination with the MS's Transport connections, forms a single 406 point-to-point link. 408 The collection of service flows (tunnels) to an MS is defined as a 409 single link. Each link has only an MS and an AR. Each MS belongs to 410 a different link. A different prefix should be assigned to each 411 unique link. This link is fully consistent with a standard IP link, 412 without exception and conforms with the definition of a point-to- 413 point link in Neighbor discovery for IPv6 [I-D.ietf-ipv6-2461bis]. 414 Hence the point-to-point link model for IPv6 operation over the IP 415 specific part of the Packet CS in 802.16 SHOULD be used. A unique 416 IPv6 prefix(es) per link (MS/host) MUST be assigned. 418 6.2. IPv6 link establishment in 802.16 420 In order to enable the sending and receiving of IPv6 packets between 421 the MS and the AR, the link between the MS and the AR via the BS 422 needs to be established. This section illustrates the link 423 establishment procedure. 425 The MS goes through the network entry procedure as specified by 426 802.16. A high level description of the network entry procedure is 427 as follows: 429 1. MS performs initial ranging with the BS. Ranging is a process by 430 which an MS becomes time aligned with the BS. The MS is 431 synchronized with the BS at the succesful completion of ranging 432 and is ready to setup a connection. 433 2. MS and BS perform capability exchange as per 802.16 procedures. 434 The CS capability parameter indicates which classification/PHS 435 options and SDU encapsulation the MS supports. By default, 436 Packet, IPv4 and 802.3/Ethernet shall be supported, thus absence 437 of this parameter in REG-REQ (802.16 message) means that named 438 options are supported by the MS/SS. Support for IPv6 over the IP 439 specific part of the packet CS is indicated by Bit#2 of the CS 440 capability parameter (Refer to [802.16]). 441 3. The MS progresses to an authentication phase. Authentication is 442 based on PKMv2 as defined in the IEEE Std 802.16 specification. 443 4. On succesful completion of authentication, the MS performs 802.16 444 registration with the network. 445 5. The MS MUST request the establishment of a service flow for IPv6 446 packets over the IP specific part of the Packet CS. The service 447 flow MAY also be triggered by the network as a result of pre- 448 provisioning. The service flow establishes a link between the MS 449 and the AR over which IPv6 packets can be sent and received. 450 6. The AR and MS should send router advertisements and solicitations 451 as specified in Neighbor discovery,[I-D.ietf-ipv6-2461bis]. 453 The above flow does not show the actual 802.16 messages that are used 454 for ranging, capability exchange or service flow establishment. 455 Details of these are in [802.16]. 457 6.3. Maximum transmission unit in 802.16 459 The MTU value for IPv6 packets on an 802.16 link is configurable. 460 The default MTU for IPv6 packets over an 802.16 link MUST be 1500 461 octets. 463 The 802.16 MAC PDU (Protocol Data Unit) is composed of a 6 byte 464 header followed by an optional payload and an optional CRC covering 465 the header and the payload. The length of the PDU is indicated by 466 the Len parameter in the Generic MAC Header. The Len parameter has a 467 size of 11 bits. Hence the total PDU size is 2048 bytes. The IPv6 468 payload can be a max value of 2038 bytes ( Total PDU size minus (MAC 469 Header + CRC)). Hence the Max value of the IPv6 MTU for 802.16 links 470 is 2038 bytes. In certain deployment scenarios the MTU value can be 471 greater than the default. Neighbor Discovery for IPv6 472 [I-D.ietf-ipv6-2461bis] defines an MTU option that an AR can 473 advertise, via router advertisement (RA), to an MN. The MTU option 474 advertised to an MN SHOULD be in the range of 1280 to 2038 bytes. If 475 an AR advertises an MTU via the RA MTU option, the MN SHOULD use the 476 MTU from the RA. Nodes that implement Path MTU discovery [RFC1981] 477 MAY use the mechanism to determine the MTU for the IPv6 packets. 479 7. IPv6 prefix assignment 481 The MS and the AR are connected via a point-to-point connection at 482 the IPv6 layer. Hence each MS can be considered to be on a separate 483 subnet. A CPE (Customer Premise Equipment) type of device which 484 serves multiple IPv6 hosts, may be the end point of the connection. 485 Hence one or more /64 prefixes SHOULD be assigned to a link. The 486 prefixes are advertised with the on-link (L-bit) flag set as 487 specified in [I-D.ietf-ipv6-2461bis]. The size and number of the 488 prefixes is a configuration issue. Also, prefix delegation MAY be 489 used to provide additional prefixes for a router connected over 490 802.16. The other properties of the prefixes are also dealt via 491 configuration. 493 8. Router Discovery 495 8.1. Router Solicitation 497 On completion of the establishment of the IPv6 link, the MS may send 498 a router solicitation message to solicit a Router Advertisement 499 message from the AR to acquire necessary information as per the 500 neighbor discovery for IPv6 specification [I-D.ietf-ipv6-2461bis]. 501 An MS that is network attached may also send router solicitations at 502 any time. Movement detection at the IP layer of an MS in many cases 503 is based on receiving periodic router advertisements. An MS may also 504 detect changes in its attachment via link triggers or other means. 505 The MS can act on such triggers by sending router solicitations. The 506 router solicitation is sent over the IPv6 link that has been 507 previously established. The MS sends router solicitations to the 508 all-routers multicast address. It is carried over the point-to-point 509 link to the AR via the BS. The MS does not need to be aware of the 510 link-local address of the AR in order to send a router solicitation 511 at any time. 513 8.2. Router Advertisement 515 The AR should send a number (configurable value) of router 516 advertisements as soon as the IPv6 link is established, to the MS. 517 The AR sends unsolicited router advertisements periodically as per 518 [I-D.ietf-ipv6-2461bis]. The interval between periodic router 519 advertisements is however greater than the specification in Neighbor 520 discovery for IPv6, and is discussed in the following section. 522 8.3. Router lifetime and periodic router advertisements 524 The router lifetime SHOULD be set to a large value, preferably in 525 hours. This document over-rides the specification for the value of 526 the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) 527 [I-D.ietf-ipv6-2461bis]. The AdvDefaultLifetime in the router 528 advertisement MUST be either zero or between MaxRtrAdvInterval and 529 43200 seconds. The default value is 2 * MaxRtrAdvInterval. 531 802.16 hosts have the capability to transition to an idle mode in 532 which case the radio link between the BS and MS is torn down. Paging 533 is required in case the network needs to deliver packets to the MS. 534 In order to avoid waking a mobile which is in idle mode and consuming 535 resources on the air interface, the interval between periodic router 536 advertisements SHOULD be set quite high. The MaxRtrAdvInterval value 537 specified in this document over-rides the recommendation in Neighbor 538 Discovery for IP Version 6 (IPv6) [I-D.ietf-ipv6-2461bis]. The 539 MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 540 21600 seconds. The default value for MaxRtrAdvInterval is 10800 541 seconds. 543 9. IPv6 addressing for hosts 545 The addressing scheme for IPv6 hosts in 802.16 network follows the 546 IETFs recommendation for hosts specified in IPv6 Node Requirement, 547 RFC 4294. The IPv6 node requirements RFC4294 [RFC4294] specifies a 548 set of RFCs that are applicable for addressing and the same is 549 applicable for hosts that use 802.16 as the link layer for 550 transporting IPv6 packets. 552 9.1. Interface Identifier 554 The MS has a 48-bit globally unique MAC address as specified in 555 802.16 [802.16]. This MAC address MUST be used to generate the 556 modified EUI-64 format-based interface identifier as specified in the 557 IP Version 6 Addressing Architecture [RFC4291]. The modified EUI-64 558 interface identifier is used in stateless address autoconfiguration. 559 As in other links that support IPv6, EUI-64 based interface 560 identifiers are not mandatory and other mechanisms, such as random 561 interface identifiers, Privacy Extensions for Stateless Address 562 Autoconfiguration in IPv6 [RFC3041] MAY also be used. 564 9.2. Duplicate address detection 566 DAD SHOULD be performed as per Neighbor Discovery for IP Version 6, 567 [I-D.ietf-ipv6-2461bis] and, IPv6 Stateless Address 568 Autoconfiguration, [I-D.ietf-ipv6-rfc2462bis]. The IPv6 link over 569 802.16 is specified in this document as a point-to-point link. Based 570 on this criteria, it may be redundant to perform DAD on a global 571 unicast address that is configured using the EUI-64 or generated as 572 per RFC3041 [RFC3041] for the interface as part of the IPv6 stateless 573 address autoconfiguration protocol [I-D.ietf-ipv6-rfc2462bis] as long 574 as the following two conditions are met: 576 1. The prefixes advertised through the router advertisement messages 577 by the access router terminating the 802.16 IPv6 link are unique 578 to that link. 579 2. The access router terminating the 802.16 IPv6 link does not 580 autoconfigure any IPv6 global unicast addresses from the prefix 581 that it advertises. 583 9.3. Stateless address autoconfiguration 585 Stateless address autoconfiguration SHOULD be performed as specified 586 in [I-D.ietf-ipv6-2461bis], [I-D.ietf-ipv6-rfc2462bis] . 588 9.4. Stateful address autoconfiguration 590 Stateful address autoconfiguration SHOULD be performed as specified 591 in [I-D.ietf-ipv6-2461bis], [RFC3315]. 593 10. Multicast Listener Discovery 595 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 596 [I-D.ietf-ipv6-2461bis] SHOULD be supported as specified by the hosts 597 and routers attached to each other via an 802.16 link. The access 598 router which has hosts attached to it via a Point-to-point link over 599 an 802.16 SHOULD not send periodic queries if the host is in idle/ 600 dormant mode. The AR can obtain information about the state of a 601 host from the paging controller in the network. 603 11. IANA Considerations 605 This draft does not require any actions from IANA. 607 12. Security Considerations 609 This document does not introduce any new vulnerabilities to IPv6 610 specifications or operation. The security of the 802.16 air 611 interface is the subject of [802.16]. In addition, the security 612 issues of the network architecture spanning beyond the 802.16 base 613 stations is the subject of the documents defining such architectures, 614 such as WiMAX Network Architecture [WiMAXArch]. 616 13. Acknowledgments 618 The authors would like to acknowledge the contributions of the 16NG 619 working group chairs Soohong Daniel Park and Gabriel Montenegro as 620 well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ 621 Johnston, Dave Thaler, Bruno Sousa, Alexandru Petrescu, Margaret 622 Wasserman and Pekka Savola for their review and comments. 624 14. References 626 14.1. Normative References 628 [802.16] "IEEE Std 802.16e: IEEE Standard for Local and 629 metropolitan area networks, Amendment for Physical and 630 Medium Access Control Layers for Combined Fixed and Mobile 631 Operation in Licensed Bands", October 2005, . 634 [I-D.ietf-ipv6-2461bis] 635 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 636 draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. 638 [I-D.ietf-ipv6-rfc2462bis] 639 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 640 draft-ietf-ipv6-rfc2462bis-08 (work in progress), 641 May 2005. 643 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 644 for IP version 6", RFC 1981, August 1996. 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", RFC 2119, March 1997, 648 . 650 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 651 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 653 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 654 Architecture", RFC 4291, February 2006. 656 14.2. Informative References 658 [802.1Q] "IEEE Std 802.1Q-2005: I E E EStandard for Local and 659 metropolitan area networks - Virtual Bridged Local Area 660 Networks", May 2006, . 663 [802.3] "IEEE Std 802.3-2005: IEEE Standard for Information 664 technology-Telecommunications and information exchange 665 between systems-Local and metropolitan area networks-- 666 Specific requirements Part 3: Carrier Sense Multiple 667 Access with Collision Detection (CSMA/CD) Access Method 668 and Physical Layer Specifications", December 2005, 669 . 671 [I-D.ietf-16ng-ps-goals] 672 Jee, J., "IP over 802.16 Problem Statement and Goals", 673 draft-ietf-16ng-ps-goals-01 (work in progress), 674 February 2007. 676 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 677 Stateless Address Autoconfiguration in IPv6", RFC 3041, 678 January 2001. 680 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 681 and M. Carney, "Dynamic Host Configuration Protocol for 682 IPv6 (DHCPv6)", RFC 3315, July 2003. 684 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 685 April 2006. 687 [WMF] "http://www.wimaxforum.org". 689 [WiMAXArch] 690 "WiMAX End-to-End Network Systems Architecture 691 http://www.wimaxforum.org/technology/documents", 692 August 2006. 694 Appendix A. WiMAX network architecture and IPv6 support 696 The WiMAX (Worldwide Interoperability for Microwave Access) forum 697 [WMF] has defined a network architecture in which the air interface 698 is based on the IEEE 802.16 standard. The addressing and operation 699 of IPv6 described in this document is applicable to the WiMAX network 700 as well. 702 The WiMAX network architecture consists of the Access Service Network 703 (ASN) and the Connectivity Service Network (CSN). The ASN is the 704 access network which includes the BS and the AR in addition to other 705 functions such as AAA, Mobile IP Foreign agent, Paging controller, 706 Location Register etc. The ASN is defined as a complete set of 707 network functions needed to provide radio access to a WiMAX 708 subscriber. The ASN is the access network to which the MS attaches. 709 The IPv6 access router is an entity within the ASN. The term ASN is 710 specific to the WiMAX network architecture. The CSN is the entity 711 that provides connectivity to the Internet and includes functions 712 such as Mobile IP Home agent and AAA. The figure below shows the 713 WiMAX reference model: 715 ------------------- 716 | ---- ASN | |----| 717 ---- | |BS|\ R6 -------| |---------| | CSN| 718 |MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | | 719 ---- | |R8 /--|------|----| |-----|Home| 720 | ---- / | | visited| | NSP| 721 | |BS|/ | | NSP | | | 722 | ---- | |---------| | | 723 | NAP | \ |----| 724 ------------------- \---| / 725 | | / 726 | (--|------/----) 727 |R4 ( ) 728 | ( ASP network ) 729 --------- ( or Internet ) 730 | ASN | ( ) 731 --------- (----------) 733 Figure 7: WiMAX Network reference model 735 Three different types of ASN realizations called profiles are defined 736 by the architecture. ASNs of profile types A and C include BS' and 737 ASN-gateway(s) (ASN-GW) which are connected to each other via an R6 738 interface. An ASN of profile type B is one in which the 739 functionality of the BS and other ASN functions are merged together. 740 No ASN-GW is specifically defined in a profile B ASN. The absence of 741 the R6 interface is also a profile B specific characteristic. The MS 742 at the IPv6 layer is associated with the AR in the ASN. The AR may 743 be a function of the ASN-GW in the case of profiles A and C and is a 744 function in the ASN in the case of profile B. When the BS and the AR 745 are separate entities and linked via the R6 interface, IPv6 packets 746 between the BS and the AR are carried over a GRE tunnel. The 747 granularity of the GRE tunnel should be on a per MS basis or on a per 748 service flow basis (an MS can have multiple service flows, each of 749 which are identified uniquely by a service flow ID). The protocol 750 stack in WiMAX for IPv6 is shown below: 752 |-------| 753 | App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 754 | | 755 |-------| /------ ------- 756 | | / IPv6 | | | 757 | IPv6 |- - - - - - - - - - - - - - - - / | | |--> 758 | | --------------- -------/ | | IPv6| 759 |-------| | \Relay/ | | | |- - - | | 760 | | | \ / | | GRE | | | | 761 | | | \ /GRE | - | | | | | 762 | |- - - | |-----| |------| | | | 763 | IPv6CS| |IPv6CS | IP | - | IP | | | | 764 | ..... | |...... |-----| |------|--------| |-----| 765 | MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 | 766 |-------| |------ |-----| |----- |--------| |-----| 767 | PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 | 768 -------- --------------- ----------------- ------- 770 MS BS AR/ASN-GW CSN Rtr 772 Figure 8: WiMAX protocol stack 774 As can be seen from the protocol stack description, the IPv6 end- 775 points are constituted in the MS and the AR. The BS provides lower 776 layer connectivity for the IPv6 link. 778 Appendix B. IPv6 link in WiMAX 780 WiMAX is an example of a network based on the IEEE Std 802.16 air 781 interface. This section describes the IPv6 link in the context of a 782 WiMAX network. The MS and the AR are connected via a combination of 783 : 785 1. The transport connection which is identified by a Connection 786 Identifier (CID) over the air interface, i.e the MS and BS and, 787 2. A GRE tunnel between the BS and AR which transports the IPv6 788 packets 790 From an IPv6 perspective the MS and the AR are connected by a point- 791 to-point link. The combination of transport connection over the air 792 interface and the GRE tunnel between the BS and AR creates a (point- 793 to-point) tunnel at the layer below IPv6. 795 The collection of service flows (tunnels) to an MS is defined as a 796 single link. Each link has only an MS and an AR. Each MS belongs to 797 a different link. No two MSs belong to the same link. A different 798 prefix should be assigned to each unique link. This link is fully 799 consistent with a standard IP link, without exception and conforms 800 with the definition of a point-to-point link in 801 [I-D.ietf-ipv6-2461bis]. 803 Appendix C. IPv6 link establishment in WiMAX 805 The mobile station performs initial network entry as specified in 806 802.16. On succesful completion of the network entry procedure the 807 ASN gateway/AR triggers the establishment of the initial service flow 808 (ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the 809 ASN-GW/AR and the BS. The BS in turn requests the MS to establish a 810 transport connection over the air interface. The end result is a 811 transport connection over the air interface for carrying IPv6 packets 812 and a GRE tunnel between the BS and AR for relaying the IPv6 packets. 813 On succesful completion of the establishment of the ISF, IPv6 packets 814 can be sent and received between the MS and AR. The ISF enables the 815 MS to communicate with the AR for host configuration procedures. 816 After the establishment of the ISF, the AR can send a router 817 advertisement to the MS. An MS can establish multiple service flows 818 with different QoS characteristics. The ISF can be considered as the 819 primary service flow. The ASN-GW/ AR treats each ISF, along with the 820 other service flows to the same MS, as a unique link which is managed 821 as a (virtual) interface. 823 Appendix D. Maximum transmission unit in WiMAX 825 The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. 826 Hence the IPv6 path MTU can be 1500 octets. However because of the 827 overhead of the GRE tunnel used to transport IPv6 packets between the 828 BS and AR and the 6 byte MAC header over the air interface, using a 829 value of 1500 would result in fragmentation of packets. It is 830 recommended that the default MTU for IPv6 be set to 1400 octets for 831 the MS in WiMAX networks. Note that the 1522 octet specification is 832 a WiMAX forum specification and not the size of the SDU that can be 833 transmitted over 802.16, which has a higher limit. 835 Authors' Addresses 837 Basavaraj Patil 838 Nokia Siemens Networks 839 6000 Connection Drive 840 Irving, TX 75039 841 USA 843 Email: basavaraj.patil@nsn.com 845 Frank Xia 846 Huawei USA 847 1700 Alma Dr. Suite 100 848 Plano, TX 75075 850 Email: xiayangsong@huawei.com 852 Behcet Sarikaya 853 Huawei USA 854 1700 Alma Dr. Suite 100 855 Plano, TX 75075 857 Email: sarikaya@ieee.org 859 JinHyeock Choi 860 Samsung AIT 861 Networking Technology Lab 862 P.O.Box 111 863 Suwon, Korea 440-600 865 Email: jinchoe@samsung.com 866 Syam Madanapalli 867 LogicaCMG 868 125 Yemlur P.O. 869 Off Airport Road 870 Bangalore, India 560037 872 Email: smadanapalli@gmail.com 874 Full Copyright Statement 876 Copyright (C) The IETF Trust (2007). 878 This document is subject to the rights, licenses and restrictions 879 contained in BCP 78, and except as set forth therein, the authors 880 retain all their rights. 882 This document and the information contained herein are provided on an 883 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 884 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 885 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 886 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 887 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 888 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 890 Intellectual Property 892 The IETF takes no position regarding the validity or scope of any 893 Intellectual Property Rights or other rights that might be claimed to 894 pertain to the implementation or use of the technology described in 895 this document or the extent to which any license under such rights 896 might or might not be available; nor does it represent that it has 897 made any independent effort to identify any such rights. Information 898 on the procedures with respect to rights in RFC documents can be 899 found in BCP 78 and BCP 79. 901 Copies of IPR disclosures made to the IETF Secretariat and any 902 assurances of licenses to be made available, or the result of an 903 attempt made to obtain a general license or permission for the use of 904 such proprietary rights by implementers or users of this 905 specification can be obtained from the IETF on-line IPR repository at 906 http://www.ietf.org/ipr. 908 The IETF invites any interested party to bring to its attention any 909 copyrights, patents or patent applications, or other proprietary 910 rights that may cover technology that may be required to implement 911 this standard. Please address the information to the IETF at 912 ietf-ipr@ietf.org. 914 Acknowledgment 916 Funding for the RFC Editor function is provided by the IETF 917 Administrative Support Activity (IASA).