idnits 2.17.1 draft-ietf-16ng-ipv6-over-ipv6cs-10.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 935. 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 (November 12, 2007) is 6003 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 653, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-07) exists of draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-00 == Outdated reference: A later version (-04) exists of draft-ietf-16ng-ps-goals-02 -- 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: May 15, 2008 Behcet Sarikaya 6 Huawei USA 7 JH. Choi 8 Samsung AIT 9 Syam Madanapalli 10 Ordyn Technologies 11 November 12, 2007 13 Transmission of IPv6 via the IPv6 CS over IEEE 802.16 Networks 14 draft-ietf-16ng-ipv6-over-ipv6cs-10 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 15, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 IEEE Std 802.16 is an air interface specification for fxed and mobile 48 Broadband Wireless Access Systems. Service specific convergence 49 sublayers to which upper layer protocols interface are a part of the 50 IEEE 802.16 MAC (Medium Access Control). The Packet convergence 51 sublayer is used for the transport of all packet-based protocols such 52 as Internet Protocol (IP) and, IEEE 802.3 LAN/MAN CSMA/CD Access 53 Method (Ethernet). IPv6 packets can be sent and received via the IP 54 specific part of the packet convergence sublayer. This document 55 specifies the addressing and operation of IPv6 over the IP specific 56 part of the packet CS for hosts served by a network that utilizes the 57 IEEE Std 802.16 air interface. It recommends the assignment of a 58 unique prefix (or prefixes) to each host and allows the host to use 59 multiple identifiers within that prefix, including support for 60 randomly generated interface identifiers. 62 Table of Contents 64 1. Conventions used in this document . . . . . . . . . . . . . . 4 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. IEEE 802.16 convergence sublayer support for IPv6 . . . . . . 5 68 4.1. IPv6 encapsulation over the IP CS of the MAC . . . . . . . 8 69 5. Generic network architecture using the 802.16 air interface . 9 70 6. IPv6 link . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1. IPv6 link in 802.16 . . . . . . . . . . . . . . . . . . . 10 72 6.2. IPv6 link establishment in 802.16 . . . . . . . . . . . . 11 73 6.3. Maximum transmission unit in 802.16 . . . . . . . . . . . 12 74 7. IPv6 prefix assignment . . . . . . . . . . . . . . . . . . . . 12 75 8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 13 77 8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 13 78 8.3. Router lifetime and periodic router advertisements . . . . 13 79 9. IPv6 addressing for hosts . . . . . . . . . . . . . . . . . . 14 80 9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 14 81 9.2. Duplicate address detection . . . . . . . . . . . . . . . 14 82 9.3. Stateless address autoconfiguration . . . . . . . . . . . 14 83 9.4. Stateful address autoconfiguration . . . . . . . . . . . . 15 84 10. Multicast Listener Discovery . . . . . . . . . . . . . . . . . 15 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 90 14.2. Informative References . . . . . . . . . . . . . . . . . . 16 91 Appendix A. WiMAX network architecture and IPv6 support . . . . . 17 92 Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 19 93 Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 20 94 Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 96 Intellectual Property and Copyright Statements . . . . . . . . . . 22 98 1. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2. Introduction 106 IEEE 802.16e is an air interface for fixed and mobile broadband 107 wireless access systems. The IEEE 802.16 standard specifies the air 108 interface, including the medium access control (MAC) layer and 109 multiple physical layer (PHY) specifications. It can be deployed in 110 licensed as well as unlicensed spectrum. While the PHY and MAC are 111 specified in IEEE 802.16, the details of IPv4 and IPv6 operation over 112 the air interface are not included. This document specifies the 113 operation of IPv6 over the IEEE 802.16 air interface. 115 IPv6 packets can be carried over the IEEE Std 802.16 specified air 116 interface via : 118 1. the IP specific part of the Packet CS or, 119 2. the 802.3 [802.3] specific part of the Packet CS 121 The scope of this specification is limited to the operation of IPv6 122 over IP CS only. 124 The IEEE 802.16 [802.16] specification includes the Phy and MAC 125 details. The convergence sublayers are a part of the MAC. The 126 packet convergence sublayer includes the IP specific part which is 127 used by the IPv6 layer. 129 The mobile station(MS)/host is attached to an access router via a 130 base station (BS). The host and the BS are connected via the IEEE 131 Std 802.16 air interface at the link and physical layers. The IPv6 132 link from the MS terminates at an access router which may be a part 133 of the BS or an entity beyond the BS. The base station is a layer 2 134 entity (from the perspective of the IPv6 link between the MS and AR) 135 and relays the IPv6 packets between the AR and the host via a point- 136 to-point connection over the air interface. 138 3. Terminology 140 The terminology in this document is based on the definitions in IP 141 over 802.16 Problem Statement and Goals [I-D.ietf-16ng-ps-goals]. 143 o IP CS - The IP specific part of the packet convergence sublayer is 144 refered to as IP CS. 145 o Subscriber station (SS), Mobile Station (MS), Mobile Node (MN) - 146 The term subscriber station, mobile station and mobile node are 147 used interchangeably in this document and mean the same, i.e an IP 148 host. 150 4. IEEE 802.16 convergence sublayer support for IPv6 152 The IEEE 802.16 MAC specifies two main service specific convergence 153 sublayers: 155 1. ATM Convergence sublayer 156 2. Packet Convergence sublayer 158 The Packet CS is used for the transport of packet based protocols 159 which include: 161 1. IEEE Std 802.3(Ethernet) 162 2. Internet Protocol (IPv4 and IPv6) 164 The service specific CS resides on top of the MAC Common Part 165 Sublayer (CPS) as shown in figure 1. The service specific CS is 166 responsible for: 168 o accepting packets (PDUs) from the upper layer, 169 o performing classification of the packet/PDU based on a set of 170 classifiers that are defined which are service specific, 171 o delivering the CS PDU to the appropriate service flow and 172 transport connection and, 173 o receiving PDUs from the peer entity. 175 Payload header suppression (PHS) is also a function of the CS but is 176 optional. 178 The figure below shows the concept of the service specific CS in 179 relation to the MAC: 181 -----------------------------\ 182 | ATM CS | Packet CS | \ 183 ----------------------------- \ 184 | MAC Common Part Sublayer | \ 185 | (Ranging, scheduling, etc)| 802.16 MAC 186 ----------------------------- / 187 | Security | / 188 |(Auth, encryption,key mgmt)| / 189 -----------------------------/ 190 | PHY | 191 ----------------------------- 193 Figure 1: The IEEE 802.16 MAC 195 Classifiers for each of the specific upper-layer protocols, i.e 196 Ethernet and IP, are defined in the IEEE 802.16 specification, which 197 enable the packets from the upper layer to be processed by the 198 appropriate service specific part of the packet CS. IPv6 can be 199 transported directly over the IP specific part of the packet CS (IP 200 CS). IPv4 packets also are transported over the IP specific part of 201 the packet CS. The classifiers used by IP CS enable the 202 differentiation of IPv4 and IPv6 packets and their mapping to 203 specific transport connections over the air-interface. 205 The figure below shows the options for IPv6 transport over the packet 206 CS of IEEE 802.16: 208 ----------------- 209 | IPv6 | 210 ---------------- |---------------| 211 | IPv6 | | Ethernet | 212 |--------------| |---------------| 213 | IP Specific | | 802.3 specific| 214 |part of Pkt CS| |part of Pkt CS | 215 |..............| |...............| 216 | MAC | | MAC | 217 |--------------| |---------------| 218 | PHY | | PHY | 219 ---------------- ----------------- 221 (1) IPv6 over (2) IPv6 over 222 IP Specific part 802.3/Ethernet 223 of Packet CS 224 Figure 2: IPv6 over IP and 802.3 specific parts of the Packet CS 226 The figure above shows that while there are multiple methods by which 227 IPv6 can be transmitted over an 802.16 air interface, the scope of 228 this document is limited to IPv6 operation over IP CS only. 229 Transmission of IP over Ethernet is specified in 230 [I-D.ietf-16ng-ip-over-ethernet-over-802.16]. Transmission of IPv4 231 over IP CS is specified by the 16ng WG in 232 [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs]. 234 It should be noted that immediately after ranging (802.16 air 235 interface procedure) and exchange of SBC-REQ/RSP messages (802.16 236 specific), the MS and BS exchange their capabilities via REG-REQ 237 (Registration Request) and REG-RSP (Registration Response) 802.16 MAC 238 messages. These management frames negotiate parameters such as the 239 Convergence Sublayer supported by the MS and BS. By default, Packet, 240 IPv4 and 802.3/Ethernet are supported. IPv6 via the IP CS is 241 supported by the MS and the BS only when the IPv6 support bit in the 242 capability negotiation messages (REG-REQ and REG-RSP) implying such 243 support is indicated in the parameter "Classification/PHS options and 244 SDU (Service Data Unit) encapsulation support" (Refer to [802.16]). 245 Additionally during the establishment of the transport connection for 246 transporting IPv6 packets, the DSA-REQ (Dynamic Service Addition) and 247 DSA-RSP messages between the BS and MS indicate via the CS- 248 Specification TLV the CS that the connection being setup shall use. 249 When the IPv6 packet is preceded by the IEEE 802.16 six byte MAC 250 header there is no specific indication in the MAC header itself about 251 the payload type. The processing of the packet is based entirely on 252 the classifiers. Based on the classification rules, the MAC layer 253 selects an appropriate transport connection for the transmission of 254 the packet. An IPv6 packet is transported over a transport 255 connection that is specifically established for carrying such 256 packets. 258 Transmission of IPv6 as explained above is possible via multiple 259 methods, i.e, via IP CS or via Ethernet interfaces. Every Internet 260 host connected via an 802.16 link : 262 1. MUST be able to send and receive IPv6 packets via IP CS when the 263 MS and BS indicate IPv6 protocol support over IP CS 264 2. SHOULD be able to send and receive IPv6 packets over the Ethernet 265 (802.3) specific part of the packet CS when the MS and BS 266 indicate IPv6 protocol support over Ethernet CS 268 When the MS and BS support IPv6 over IP CS, it MUST be used as the 269 default mode for transporting IPv6 packets over IEEE 802.16 and the 270 recommendations in this document followed. Inability to negotiate a 271 common convergence sublayer for IPv6 transport between the MS and BS 272 will result in failure to setup the transport connection and thereby 273 render the host unable to send and receive IPv6 packets. In the case 274 of a host which implements more than one method of transporting IPv6 275 packets, the default choice of which method to use (i.e IPv6 over the 276 IP CS or IPv6 over 802.3) is IPv6 over IP CS when the BS also 277 supports such capability. 279 4.1. IPv6 encapsulation over the IP CS of the MAC 281 The IPv6 payload when carried over the IP specific part of the Packet 282 CS is encapsulated by the 6 byte IEEE 802.16 generic MAC header. The 283 format of the IPv6 packet encapsulated by the generic MAC header is 284 shown in the figure below. The format of the 6 byte MAC header is 285 described in the [802.16] specification. The CRC (cyclic redundancy 286 check) is optional. It should be noted that the actual MAC address 287 is not included in the MAC header. 289 ---------/ /----------- 290 | MAC SDU | 291 --------/ /------------ 292 || 293 || 294 MSB \/ LSB 295 --------------------------------------------------------- 296 | Generic MAC header| IPv6 Payload | CRC | 297 --------------------------------------------------------- 299 Figure 3: IPv6 encapsulation 301 For transmission of IPv6 packets via the IP CS over IEEE 802.16, the 302 IPv6 layer interfaces with the 802.16 MAC directly. The IPv6 layer 303 delivers the IPv6 packet to the Packet CS of the IEEE 802.16 MAC. 304 The packet CS defines a set of classifiers that are used to determine 305 how to handle the packet. The IP classifiers that are used at the 306 MAC operate on the fields of the IP header and the transport protocol 307 and these include the IP Traffic class, Next header field, Masked IP 308 source and destination addresses and, Protocol source and destination 309 port ranges. Next header in this case refers to the last header of 310 the IP header chain. Parsing these classifiers, the MAC maps an 311 upper layer packet to a specific service flow and transport 312 connection to be used. The MAC encapsulates the IPv6 packet in the 6 313 byte MAC header (MAC SDU) and transmits it. The figure below shows 314 the operation on the downlink, i.e the transmission from the BS to 315 the host. The reverse is applicable for the uplink transmission. 317 ----------- ---------- 318 | IPv6 Pkt| |IPv6 Pkt| 319 ----------- ---------- 320 | | /|\ 321 | | | 322 --[SAP]--------------------- ---------[SAP]-------- 323 ||-| |----------| | | /|\ | 324 || \ / 0---->[CID1] | | --- |-------- | 325 || Downlink 0\/-->[CID2] | | |Reconstruct| | 326 || classifiers0/\-->[....] | | | (undo PHS)| | 327 || 0---->[CIDn] | | --- ------- | 328 ||--------------| | | /|\ | 329 | | | | | 330 | {SDU, CID,..} | | {SDU, CID,..} | 331 | | | | /|\ | 332 | v | | | | 333 ------[SAP]----------------- |-------[SAP]--------- 334 | 802.16 MAC CPS |------>| 802.16 MAC CPS | 335 ---------------------------- ---------------------- 336 BS MS 338 Figure 4: IPv6 packet transmission: Downlink 340 5. Generic network architecture using the 802.16 air interface 342 In a network that utilizes the 802.16 air interface the host/MS is 343 attached to an IPv6 access router (AR) in the network. The BS is a 344 layer 2 entity only. The AR can be an integral part of the BS or the 345 AR could be an entity beyond the BS within the access network. An AR 346 nay be attached to multiple BS' in a network. IPv6 packets between 347 the MS and BS are carried over a point-to-point transport connection 348 which is identified by a unique connection identifier (CID). The 349 transport connection is a MAC layer link between the MS and the BS. 350 The figures below describe the possible network architectures and are 351 generic in nature. More esoteric architectures are possible but not 352 considered in the scope of this document. Option A: 354 +-----+ CID1 +--------------+ 355 | MS1 |------------/| BS/AR |-----[Internet] 356 +-----+ / +--------------+ 357 . /---/ 358 . CIDn 359 +-----+ / 360 | MSn |---/ 361 +-----+ 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 [RFC4861] defines link as a 384 communication facility or medium over which nodes can communicate at 385 the link layer, i.e., the layer immediately below IP . A link is 386 bounded by routers that decrement the Hop limit field in the IPv6 387 header. When an MS moves within a link, it can keep using its IP 388 addresses. This is a layer 3 definition and note that the definition 389 is not identical with the definition of the term '(L2) link' in IEEE 390 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 colocated, 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 granularity 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 that use the same higher layer protocol has 410 only an MS and an AR. Each MS belongs to a different link. A 411 different prefix should be assigned to each unique link. This link 412 is fully consistent with a standard IP link, without exception and 413 conforms with the definition of a point-to-point link in Neighbor 414 discovery for IPv6 [RFC4861]. Hence the point-to-point link model 415 for IPv6 operation over the IP specific part of the Packet CS in 416 802.16 SHOULD be used. A unique IPv6 prefix(es) per link (MS/host) 417 MUST be assigned. 419 6.2. IPv6 link establishment in 802.16 421 In order to enable the sending and receiving of IPv6 packets between 422 the MS and the AR, the link between the MS and the AR via the BS 423 needs to be established. This section illustrates the link 424 establishment procedure. 426 The MS goes through the network entry procedure as specified by 427 802.16. A high level description of the network entry procedure is 428 as follows: 430 1. MS performs initial ranging with the BS. Ranging is a process by 431 which an MS becomes time aligned with the BS. The MS is 432 synchronized with the BS at the successful completion of ranging 433 and is ready to setup a connection. 434 2. The MS and BS exchange basic capabilities that are necessary for 435 effective communication during the initialization using SBC-REQ/ 436 RSP (802.16 specific) messages. 437 3. The MS progresses to an authentication phase. Authentication is 438 based on PKMv2 as defined in the IEEE Std 802.16 specification. 439 4. On successful completion of authentication, the MS performs 440 802.16 registration with the network. 441 5. MS and BS perform capability exchange as per 802.16 procedures. 442 Protocol support is indicated in this exchange. The CS 443 capability parameter indicates which classification/PHS options 444 and SDU encapsulation the MS supports. By default, Packet, IPv4 445 and 802.3/Ethernet shall be supported, thus absence of this 446 parameter in REG-REQ (802.16 message) means that named options 447 are supported by the MS/SS. Support for IPv6 over the IP 448 specific part of the packet CS is indicated by Bit#2 of the CS 449 capability parameter (Refer to [802.16]). 451 6. The MS MUST request the establishment of a service flow for IPv6 452 packets over IP CS if the MS and BS have confirmed capability for 453 supporting IPv6 over IP CS. The service flow MAY also be 454 triggered by the network as a result of pre-provisioning. The 455 service flow establishes a link between the MS and the AR over 456 which IPv6 packets can be sent and received. 457 7. The AR and MS SHOULD send router advertisements and solicitations 458 as specified in Neighbor discovery,[RFC4861]. 460 The above flow does not show the actual 802.16 messages that are used 461 for ranging, capability exchange or service flow establishment. 462 Details of these are in [802.16]. 464 6.3. Maximum transmission unit in 802.16 466 The MTU value for IPv6 packets on an 802.16 link is configurable. 467 The default MTU for IPv6 packets over an 802.16 link MUST be 1500 468 octets. 470 The 802.16 MAC PDU (Protocol Data Unit) is composed of a 6 byte 471 header followed by an optional payload and an optional CRC covering 472 the header and the payload. The length of the PDU is indicated by 473 the Len parameter in the Generic MAC Header. The Len parameter has a 474 size of 11 bits. Hence the total MAC PDU size is 2048 bytes. The 475 IPv6 payload size can vary. In certain deployment scenarios the MTU 476 value can be greater than the default. Neighbor Discovery for IPv6 477 [RFC4861] defines an MTU option that an AR can advertise, via router 478 advertisement (RA), to a Mobile Node (MN). If an AR advertises an 479 MTU via the RA MTU option, the MN SHOULD use the MTU from the RA. 480 Nodes that implement Path MTU discovery [RFC1981] MAY use the 481 mechanism to determine the MTU for the IPv6 packets. 483 7. IPv6 prefix assignment 485 The MS and the AR are connected via a point-to-point connection at 486 the IPv6 layer. Hence each MS can be considered to be on a separate 487 subnet. A CPE (Customer Premise Equipment) type of device which 488 serves multiple IPv6 hosts, may be the end point of the connection. 489 Hence one or more /64 prefixes SHOULD be assigned to a link. The 490 prefixes are advertised with the on-link (L-bit) flag set as 491 specified in [RFC4861]. The size and number of the prefixes is a 492 configuration issue. Also, DHCP or AAA-based prefix delegation MAY 493 be used to provide one or more prefixes to MS for an AR connected 494 over 802.16. The other properties of the prefixes are also dealt 495 with via configuration. 497 8. Router Discovery 499 8.1. Router Solicitation 501 On completion of the establishment of the IPv6 link, the MS may send 502 a router solicitation message to solicit a Router Advertisement 503 message from the AR to acquire necessary information as per the 504 neighbor discovery for IPv6 specification [RFC4861]. An MS that is 505 network attached may also send router solicitations at any time. 506 Movement detection at the IP layer of an MS in many cases is based on 507 receiving periodic router advertisements. An MS may also detect 508 changes in its attachment via link triggers or other means. The MS 509 can act on such triggers by sending router solicitations. The router 510 solicitation is sent over the IPv6 link that has been previously 511 established. The MS sends router solicitations to the all-routers 512 multicast address. It is carried over the point-to-point link to the 513 AR via the BS. The MS does not need to be aware of the link-local 514 address of the AR in order to send a router solicitation at any time. 515 The use of router advertisements as a means for movement detection is 516 not recommended for MNs connected via 802.16 links as the frequency 517 of periodic router advertisements can be high. 519 8.2. Router Advertisement 521 The AR SHOULD send a number (configurable value) of router 522 advertisements as soon as the IPv6 link is established, to the MS. 523 The AR sends unsolicited router advertisements periodically as per 524 [RFC4861]. The interval between periodic router advertisements is 525 however greater than the specification in Neighbor discovery for 526 IPv6, and is discussed in the following section. 528 8.3. Router lifetime and periodic router advertisements 530 The router lifetime SHOULD be set to a large value, preferably in 531 hours. This document over-rides the specification for the value of 532 the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) 533 [RFC4861]. The AdvDefaultLifetime in the router advertisement MUST 534 be either zero or between MaxRtrAdvInterval and 43200 seconds. The 535 default value is 2 * MaxRtrAdvInterval. 537 802.16 hosts have the capability to transition to an idle mode in 538 which case the radio link between the BS and MS is torn down. Paging 539 is required in case the network needs to deliver packets to the MS. 540 In order to avoid waking a mobile which is in idle mode and consuming 541 resources on the air interface, the interval between periodic router 542 advertisements SHOULD be set quite high. The MaxRtrAdvInterval value 543 specified in this document over-rides the recommendation in Neighbor 544 Discovery for IP Version 6 (IPv6) [RFC4861]. The MaxRtrAdvInterval 545 MUST be no less than 4 seconds and no greater than 21600 seconds. 546 The default value for MaxRtrAdvInterval is 10800 seconds. 548 9. IPv6 addressing for hosts 550 The addressing scheme for IPv6 hosts in 802.16 networks follows the 551 IETFs recommendation for hosts specified in IPv6 Node Requirement, 552 RFC 4294. The IPv6 node requirements RFC4294 [RFC4294] specifies a 553 set of RFCs that are applicable for addressing and the same is 554 applicable for hosts that use 802.16 as the link layer for 555 transporting IPv6 packets. 557 9.1. Interface Identifier 559 The MS has a 48-bit globally unique MAC address as specified in 560 802.16 [802.16]. This MAC address MUST be used to generate the 561 modified EUI-64 format-based interface identifier as specified in the 562 IP Version 6 Addressing Architecture [RFC4291]. The modified EUI-64 563 interface identifier is used in stateless address autoconfiguration. 564 As in other links that support IPv6, EUI-64 based interface 565 identifiers are not mandatory and other mechanisms, such as random 566 interface identifiers, Privacy Extensions for Stateless Address 567 Autoconfiguration in IPv6 [RFC3041] MAY also be used. 569 9.2. Duplicate address detection 571 DAD SHOULD be performed as per Neighbor Discovery for IP Version 6, 572 [RFC4861] and, IPv6 Stateless Address Autoconfiguration, [RFC4862]. 573 The IPv6 link over 802.16 is specified in this document as a point- 574 to-point link. Based on this criteria, it may be redundant to 575 perform DAD on a global unicast address that is configured using the 576 EUI-64 or generated as per RFC3041 [RFC3041] for the interface as 577 part of the IPv6 stateless address autoconfiguration protocol 578 [RFC4862] as long as the following two conditions are met: 580 1. The prefixes advertised through the router advertisement messages 581 by the access router terminating the 802.16 IPv6 link are unique 582 to that link. 583 2. The access router terminating the 802.16 IPv6 link does not 584 autoconfigure any IPv6 global unicast addresses from the prefix 585 that it advertises. 587 9.3. Stateless address autoconfiguration 589 When stateless address autoconfiguration is performed, it MUST be 590 performed as specified in [RFC4861] and, [RFC4862]. 592 9.4. Stateful address autoconfiguration 594 When stateful address autoconfiguration is performed, it MUST be 595 performed as specified in [RFC4861] and, [RFC3315]. 597 10. Multicast Listener Discovery 599 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 [RFC4861] 600 SHOULD be supported as specified by the hosts and routers attached to 601 each other via an 802.16 link. The access router which has hosts 602 attached to it via a Point-to-point link over an 802.16 SHOULD NOT 603 send periodic queries if the host is in idle/dormant mode. The AR 604 can obtain information about the state of a host from the paging 605 controller in the network. 607 11. IANA Considerations 609 This draft does not require any actions from IANA. 611 12. Security Considerations 613 This document does not introduce any new vulnerabilities to IPv6 614 specifications or operation. The security of the 802.16 air 615 interface is the subject of [802.16]. It should be noted that 802.16 616 provides capability to cipher the traffic carried over the transport 617 connections. A traffic encryption key (TEK) is generated by the MS 618 and BS on completion of successful authentication and is used to 619 secure the traffic over the air interface. An MS may still use IPv6 620 security mechanisms even in the presence of security over the 802.16 621 link. In addition, the security issues of the network architecture 622 spanning beyond the 802.16 base stations is the subject of the 623 documents defining such architectures, such as WiMAX Network 624 Architecture [WiMAXArch] in Sections 7.2 and 7.3 of Stage 2 Part 2. 626 13. Acknowledgments 628 The authors would like to acknowledge the contributions of the 16NG 629 working group chairs Soohong Daniel Park and Gabriel Montenegro as 630 well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ 631 Johnston, Dave Thaler, Bruno Sousa, Alexandru Petrescu, Margaret 632 Wasserman and Pekka Savola for their review and comments. Review and 633 comments by Phil Barber have also helped in improving the document 634 quality. 636 14. References 638 14.1. Normative References 640 [802.16] "IEEE Std 802.16e: IEEE Standard for Local and 641 metropolitan area networks, Amendment for Physical and 642 Medium Access Control Layers for Combined Fixed and Mobile 643 Operation in Licensed Bands", October 2005, . 646 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 647 for IP version 6", RFC 1981, August 1996. 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", RFC 2119, March 1997, 651 . 653 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 654 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 656 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 657 Architecture", RFC 4291, February 2006. 659 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 660 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 661 September 2007. 663 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 664 Address Autoconfiguration", RFC 4862, September 2007. 666 14.2. Informative References 668 [802.3] "IEEE Std 802.3-2005: IEEE Standard for Information 669 technology-Telecommunications and information exchange 670 between systems-Local and metropolitan area networks-- 671 Specific requirements Part 3: Carrier Sense Multiple 672 Access with Collision Detection (CSMA/CD) Access Method 673 and Physical Layer Specifications", December 2005, 674 . 676 [I-D.ietf-16ng-ip-over-ethernet-over-802.16] 677 Jeon, H., "Transmission of IP over Ethernet over IEEE 678 802.16 Networks", 679 draft-ietf-16ng-ip-over-ethernet-over-802.16-02 (work in 680 progress), July 2007. 682 [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs] 683 Madanapalli, S., "Transmission of IPv4 packets over IEEE 684 802.16's IP Convergence Sublayer", 685 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-00 (work in 686 progress), May 2007. 688 [I-D.ietf-16ng-ps-goals] 689 Jee, J., "IP over 802.16 Problem Statement and Goals", 690 draft-ietf-16ng-ps-goals-02 (work in progress), 691 August 2007. 693 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 694 Stateless Address Autoconfiguration in IPv6", RFC 3041, 695 January 2001. 697 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 698 and M. Carney, "Dynamic Host Configuration Protocol for 699 IPv6 (DHCPv6)", RFC 3315, July 2003. 701 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 702 April 2006. 704 [WMF] "http://www.wimaxforum.org". 706 [WiMAXArch] 707 "WiMAX End-to-End Network Systems Architecture 708 http://www.wimaxforum.org/technology/documents", 709 August 2006. 711 Appendix A. WiMAX network architecture and IPv6 support 713 The WiMAX (Worldwide Interoperability for Microwave Access) forum 714 [WMF] has defined a network architecture in which the air interface 715 is based on the IEEE 802.16 standard. The addressing and operation 716 of IPv6 described in this document is applicable to the WiMAX network 717 as well. 719 WiMAX is an example architecture of a network that uses the 802.16 720 specification for the air interface. WiMAX networks are also in the 721 process of being deployed in various parts of the world and the 722 operation of IPv6 within a WiMAX network is explained in this 723 appendix. 725 The WiMAX network architecture consists of the Access Service Network 726 (ASN) and the Connectivity Service Network (CSN). The ASN is the 727 access network which includes the BS and the AR in addition to other 728 functions such as AAA, Mobile IP Foreign agent, Paging controller, 729 Location Register etc. The ASN is defined as a complete set of 730 network functions needed to provide radio access to a WiMAX 731 subscriber. The ASN is the access network to which the MS attaches. 732 The IPv6 access router is an entity within the ASN. The term ASN is 733 specific to the WiMAX network architecture. The CSN is the entity 734 that provides connectivity to the Internet and includes functions 735 such as Mobile IP Home agent and AAA. The figure below shows the 736 WiMAX reference model: 738 ------------------- 739 | ---- ASN | |----| 740 ---- | |BS|\ R6 -------| |---------| | CSN| 741 |MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | | 742 ---- | |R8 /--|------|----| |-----|Home| 743 | ---- / | | visited| | NSP| 744 | |BS|/ | | NSP | | | 745 | ---- | |---------| | | 746 | NAP | \ |----| 747 ------------------- \---| / 748 | | / 749 | (--|------/----) 750 |R4 ( ) 751 | ( ASP network ) 752 --------- ( or Internet ) 753 | ASN | ( ) 754 --------- (----------) 756 Figure 7: WiMAX Network reference model 758 Three different types of ASN realizations called profiles are defined 759 by the architecture. ASNs of profile types A and C include BS' and 760 ASN-gateway(s) (ASN-GW) which are connected to each other via an R6 761 interface. An ASN of profile type B is one in which the 762 functionality of the BS and other ASN functions are merged together. 763 No ASN-GW is specifically defined in a profile B ASN. The absence of 764 the R6 interface is also a profile B specific characteristic. The MS 765 at the IPv6 layer is associated with the AR in the ASN. The AR may 766 be a function of the ASN-GW in the case of profiles A and C and is a 767 function in the ASN in the case of profile B. When the BS and the AR 768 are separate entities and linked via the R6 interface, IPv6 packets 769 between the BS and the AR are carried over a GRE tunnel. The 770 granularity of the GRE tunnel should be on a per MS basis or on a per 771 service flow basis (an MS can have multiple service flows, each of 772 which are identified uniquely by a service flow ID). The protocol 773 stack in WiMAX for IPv6 is shown below: 775 |-------| 776 | App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 777 | | 778 |-------| /------ ------- 779 | | / IPv6 | | | 780 | IPv6 |- - - - - - - - - - - - - - - - / | | |--> 781 | | --------------- -------/ | | IPv6| 782 |-------| | \Relay/ | | | |- - - | | 783 | | | \ / | | GRE | | | | 784 | | | \ /GRE | - | | | | | 785 | |- - - | |-----| |------| | | | 786 | IPv6CS| |IPv6CS | IP | - | IP | | | | 787 | ..... | |...... |-----| |------|--------| |-----| 788 | MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 | 789 |-------| |------ |-----| |----- |--------| |-----| 790 | PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 | 791 -------- --------------- ----------------- ------- 793 MS BS AR/ASN-GW CSN Rtr 795 Figure 8: WiMAX protocol stack 797 As can be seen from the protocol stack description, the IPv6 end- 798 points are constituted in the MS and the AR. The BS provides lower 799 layer connectivity for the IPv6 link. 801 Appendix B. IPv6 link in WiMAX 803 WiMAX is an example of a network based on the IEEE Std 802.16 air 804 interface. This section describes the IPv6 link in the context of a 805 WiMAX network. The MS and the AR are connected via a combination of 806 : 808 1. The transport connection which is identified by a Connection 809 Identifier (CID) over the air interface, i.e the MS and BS and, 810 2. A GRE tunnel between the BS and AR which transports the IPv6 811 packets 813 From an IPv6 perspective the MS and the AR are connected by a point- 814 to-point link. The combination of transport connection over the air 815 interface and the GRE tunnel between the BS and AR creates a (point- 816 to-point) tunnel at the layer below IPv6. 818 The collection of service flows (tunnels) to an MS is defined as a 819 single link. Each link has only an MS and an AR. Each MS belongs to 820 a different link. No two MSs belong to the same link. A different 821 prefix should be assigned to each unique link. This link is fully 822 consistent with a standard IP link, without exception and conforms 823 with the definition of a point-to-point link in [RFC4861]. 825 Appendix C. IPv6 link establishment in WiMAX 827 The mobile station performs initial network entry as specified in 828 802.16. On successful completion of the network entry procedure the 829 ASN gateway/AR triggers the establishment of the initial service flow 830 (ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the 831 ASN-GW/AR and the BS. The BS in turn requests the MS to establish a 832 transport connection over the air interface. The end result is a 833 transport connection over the air interface for carrying IPv6 packets 834 and a GRE tunnel between the BS and AR for relaying the IPv6 packets. 835 On successful completion of the establishment of the ISF, IPv6 836 packets can be sent and received between the MS and AR. The ISF 837 enables the MS to communicate with the AR for host configuration 838 procedures. After the establishment of the ISF, the AR can send a 839 router advertisement to the MS. An MS can establish multiple service 840 flows with different QoS characteristics. The ISF can be considered 841 as the primary service flow. The ASN-GW/ AR treats each ISF, along 842 with the other service flows to the same MS, as a unique link which 843 is managed as a (virtual) interface. 845 Appendix D. Maximum transmission unit in WiMAX 847 The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. 848 Hence the IPv6 path MTU can be 1500 octets. However because of the 849 overhead of the GRE tunnel used to transport IPv6 packets between the 850 BS and AR and the 6 byte MAC header over the air interface, using a 851 value of 1500 would result in fragmentation of packets. It is 852 recommended that the default MTU for IPv6 be set to 1400 octets for 853 the MS in WiMAX networks. Note that the 1522 octet specification is 854 a WiMAX forum specification and not the size of the SDU that can be 855 transmitted over 802.16, which has a higher limit. 857 Authors' Addresses 859 Basavaraj Patil 860 Nokia Siemens Networks 861 6000 Connection Drive 862 Irving, TX 75039 863 USA 865 Email: basavaraj.patil@nsn.com 867 Frank Xia 868 Huawei USA 869 1700 Alma Dr. Suite 100 870 Plano, TX 75075 872 Email: xiayangsong@huawei.com 874 Behcet Sarikaya 875 Huawei USA 876 1700 Alma Dr. Suite 100 877 Plano, TX 75075 879 Email: sarikaya@ieee.org 881 JinHyeock Choi 882 Samsung AIT 883 Networking Technology Lab 884 P.O.Box 111 885 Suwon, Korea 440-600 887 Email: jinchoe@samsung.com 889 Syam Madanapalli 890 Ordyn Technologies 891 1st Floor, Creator Building, ITPL. 892 Off Airport Road 893 Bangalore, India 560066 895 Email: smadanapalli@gmail.com 897 Full Copyright Statement 899 Copyright (C) The IETF Trust (2007). 901 This document is subject to the rights, licenses and restrictions 902 contained in BCP 78, and except as set forth therein, the authors 903 retain all their rights. 905 This document and the information contained herein are provided on an 906 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 907 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 908 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 909 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 910 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 911 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 913 Intellectual Property 915 The IETF takes no position regarding the validity or scope of any 916 Intellectual Property Rights or other rights that might be claimed to 917 pertain to the implementation or use of the technology described in 918 this document or the extent to which any license under such rights 919 might or might not be available; nor does it represent that it has 920 made any independent effort to identify any such rights. Information 921 on the procedures with respect to rights in RFC documents can be 922 found in BCP 78 and BCP 79. 924 Copies of IPR disclosures made to the IETF Secretariat and any 925 assurances of licenses to be made available, or the result of an 926 attempt made to obtain a general license or permission for the use of 927 such proprietary rights by implementers or users of this 928 specification can be obtained from the IETF on-line IPR repository at 929 http://www.ietf.org/ipr. 931 The IETF invites any interested party to bring to its attention any 932 copyrights, patents or patent applications, or other proprietary 933 rights that may cover technology that may be required to implement 934 this standard. Please address the information to the IETF at 935 ietf-ipr@ietf.org. 937 Acknowledgment 939 Funding for the RFC Editor function is provided by the IETF 940 Administrative Support Activity (IASA).