idnits 2.17.1 draft-ietf-16ng-ipv6-over-ipv6cs-11.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 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 940. 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 6010 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 657, 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-11 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 . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 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. IPv6 CS and IP CS are used interchangeably. 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 Packet CS | | part of Packet 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 Specific part 224 of Packet CS 226 Figure 2: IPv6 over IP and 802.3 specific parts of the Packet CS 228 The figure above shows that while there are multiple methods by which 229 IPv6 can be transmitted over an 802.16 air interface, the scope of 230 this document is limited to IPv6 operation over IP CS only. 231 Transmission of IP over Ethernet is specified in 232 [I-D.ietf-16ng-ip-over-ethernet-over-802.16]. Transmission of IPv4 233 over IP CS is specified by the 16ng WG in 234 [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs]. 236 It should be noted that immediately after ranging (802.16 air 237 interface procedure) and exchange of SBC-REQ/RSP messages (802.16 238 specific), the MS and BS exchange their capabilities via REG-REQ 239 (Registration Request) and REG-RSP (Registration Response) 802.16 MAC 240 messages. These management frames negotiate parameters such as the 241 Convergence Sublayer supported by the MS and BS. By default, Packet, 242 IPv4 and 802.3/Ethernet are supported. IPv6 via the IP CS is 243 supported by the MS and the BS only when the IPv6 support bit in the 244 capability negotiation messages (REG-REQ and REG-RSP) implying such 245 support is indicated in the parameter "Classification/PHS options and 246 SDU (Service Data Unit) encapsulation support" (Refer to [802.16]). 247 Additionally during the establishment of the transport connection for 248 transporting IPv6 packets, the DSA-REQ (Dynamic Service Addition) and 249 DSA-RSP messages between the BS and MS indicate via the CS- 250 Specification TLV the CS that the connection being setup shall use. 251 When the IPv6 packet is preceded by the IEEE 802.16 six byte MAC 252 header there is no specific indication in the MAC header itself about 253 the payload type. The processing of the packet is based entirely on 254 the classifiers. Based on the classification rules, the MAC layer 255 selects an appropriate transport connection for the transmission of 256 the packet. An IPv6 packet is transported over a transport 257 connection that is specifically established for carrying such 258 packets. 260 Transmission of IPv6 as explained above is possible via multiple 261 methods, i.e, via IP CS or via Ethernet interfaces. Every Internet 262 host connected via an 802.16 link : 264 1. MUST be able to send and receive IPv6 packets via IP CS when the 265 MS and BS indicate IPv6 protocol support over IP CS 266 2. MUST be able to send and receive IPv6 packets over the Ethernet 267 (802.3) specific part of the packet CS when the MS and BS 268 indicate IPv6 protocol support over Ethernet CS. However when 269 the MS and BS indicate IPv6 protocol support over both IP CS and 270 Ethernet CS, the MS and BS MUST use IP CS for sending and 271 receiving IPv6 packets. 273 When the MS and BS support IPv6 over IP CS, it MUST be used as the 274 default mode for transporting IPv6 packets over IEEE 802.16 and the 275 recommendations in this document followed. Inability to negotiate a 276 common convergence sublayer for IPv6 transport between the MS and BS 277 will result in failure to setup the transport connection and thereby 278 render the host unable to send and receive IPv6 packets. In the case 279 of a host which implements more than one method of transporting IPv6 280 packets, the default choice of which method to use (i.e IPv6 over the 281 IP CS or IPv6 over 802.3) is IPv6 over IP CS when the BS also 282 supports such capability. 284 4.1. IPv6 encapsulation over the IP CS of the MAC 286 The IPv6 payload when carried over the IP specific part of the Packet 287 CS is encapsulated by the 6 byte IEEE 802.16 generic MAC header. The 288 format of the IPv6 packet encapsulated by the generic MAC header is 289 shown in the figure below. The format of the 6 byte MAC header is 290 described in the [802.16] specification. The CRC (cyclic redundancy 291 check) is optional. It should be noted that the actual MAC address 292 is not included in the MAC header. 294 ---------/ /----------- 295 | MAC SDU | 296 --------/ /------------ 297 || 298 || 299 MSB \/ LSB 300 --------------------------------------------------------- 301 | Generic MAC header| IPv6 Payload | CRC | 302 --------------------------------------------------------- 304 Figure 3: IPv6 encapsulation 306 For transmission of IPv6 packets via the IP CS over IEEE 802.16, the 307 IPv6 layer interfaces with the 802.16 MAC directly. The IPv6 layer 308 delivers the IPv6 packet to the Packet CS of the IEEE 802.16 MAC. 309 The packet CS defines a set of classifiers that are used to determine 310 how to handle the packet. The IP classifiers that are used at the 311 MAC operate on the fields of the IP header and the transport protocol 312 and these include the IP Traffic class, Next header field, Masked IP 313 source and destination addresses and, Protocol source and destination 314 port ranges. Next header in this case refers to the last header of 315 the IP header chain. Parsing these classifiers, the MAC maps an 316 upper layer packet to a specific service flow and transport 317 connection to be used. The MAC encapsulates the IPv6 packet in the 6 318 byte MAC header (MAC SDU) and transmits it. The figure below shows 319 the operation on the downlink, i.e the transmission from the BS to 320 the host. The reverse is applicable for the uplink transmission. 322 ----------- ---------- 323 | IPv6 Pkt| |IPv6 Pkt| 324 ----------- ---------- 325 | | /|\ 326 | | | 327 --[SAP]--------------------- ---------[SAP]-------- 328 ||-| |----------| | | /|\ | 329 || \ / 0---->[CID1] | | --- |-------- | 330 || Downlink 0\/-->[CID2] | | |Reconstruct| | 331 || classifiers0/\-->[....] | | | (undo PHS)| | 332 || 0---->[CIDn] | | --- ------- | 333 ||--------------| | | /|\ | 334 | | | | | 335 | {SDU, CID,..} | | {SDU, CID,..} | 336 | | | | /|\ | 337 | v | | | | 338 ------[SAP]----------------- |-------[SAP]--------- 339 | 802.16 MAC CPS |------>| 802.16 MAC CPS | 340 ---------------------------- ---------------------- 341 BS MS 343 Figure 4: IPv6 packet transmission: Downlink 345 5. Generic network architecture using the 802.16 air interface 347 In a network that utilizes the 802.16 air interface the host/MS is 348 attached to an IPv6 access router (AR) in the network. The BS is a 349 layer 2 entity only. The AR can be an integral part of the BS or the 350 AR could be an entity beyond the BS within the access network. An AR 351 nay be attached to multiple BS' in a network. IPv6 packets between 352 the MS and BS are carried over a point-to-point transport connection 353 which is identified by a unique connection identifier (CID). The 354 transport connection is a MAC layer link between the MS and the BS. 355 The figures below describe the possible network architectures and are 356 generic in nature. More esoteric architectures are possible but not 357 considered in the scope of this document. Option A: 359 +-----+ CID1 +--------------+ 360 | MS1 |------------/| BS/AR |-----[Internet] 361 +-----+ / +--------------+ 362 . /---/ 363 . CIDn 364 +-----+ / 365 | MSn |---/ 366 +-----+ 368 Figure 5: The IPv6 AR as an integral part of the BS 370 Option B: 372 +-----+ CID1 +-----+ +-----------+ 373 | MS1 |----------/| BS1 |----------| AR |-----[Internet] 374 +-----+ / +-----+ +-----------+ 375 . / ____________ 376 . CIDn / ()__________() 377 +-----+ / L2 Tunnel 378 | MSn |-----/ 379 +-----+ 381 Figure 6: The IPv6 AR is separate from the BS 383 The above network models serve as examples and are shown to 384 illustrate the point to point link between the MS and the AR. 386 6. IPv6 link 388 Neighbor Discovery for IP Version 6 [RFC4861] defines link as a 389 communication facility or medium over which nodes can communicate at 390 the link layer, i.e., the layer immediately below IP . A link is 391 bounded by routers that decrement the Hop limit field in the IPv6 392 header. When an MS moves within a link, it can keep using its IP 393 addresses. This is a layer 3 definition and note that the definition 394 is not identical with the definition of the term '(L2) link' in IEEE 395 802 standards. 397 6.1. IPv6 link in 802.16 399 In 802.16, the Transport Connection between an MS and a BS is used to 400 transport user data, i.e. IPv6 packets in this case. A Transport 401 Connection is represented by a CID (Connection Identifier) and 402 multiple Transport Connections can exist between an MS and BS. 404 When an AR and a BS are colocated, the collection of Transport 405 Connections to an MS is defined as a single link. When an AR and a 406 BS are separated, it is recommended that a tunnel is established 407 between the AR and a BS whose granularity is no greater than 'per MS' 408 or 'per service flow' ( An MS can have multiple service flows which 409 are identified by a service flow ID). Then the tunnel(s) for an MS, 410 in combination with the MS's Transport connections, forms a single 411 point-to-point link. 413 The collection of service flows (tunnels) to an MS is defined as a 414 single link. Each link that use the same higher layer protocol has 415 only an MS and an AR. Each MS belongs to a different link. A 416 different prefix should be assigned to each unique link. This link 417 is fully consistent with a standard IP link, without exception and 418 conforms with the definition of a point-to-point link in Neighbor 419 discovery for IPv6 [RFC4861]. Hence the point-to-point link model 420 for IPv6 operation over the IP specific part of the Packet CS in 421 802.16 SHOULD be used. A unique IPv6 prefix(es) per link (MS/host) 422 MUST be assigned. 424 6.2. IPv6 link establishment in 802.16 426 In order to enable the sending and receiving of IPv6 packets between 427 the MS and the AR, the link between the MS and the AR via the BS 428 needs to be established. This section illustrates the link 429 establishment procedure. 431 The MS goes through the network entry procedure as specified by 432 802.16. A high level description of the network entry procedure is 433 as follows: 435 1. MS performs initial ranging with the BS. Ranging is a process by 436 which an MS becomes time aligned with the BS. The MS is 437 synchronized with the BS at the successful completion of ranging 438 and is ready to setup a connection. 439 2. The MS and BS exchange basic capabilities that are necessary for 440 effective communication during the initialization using SBC-REQ/ 441 RSP (802.16 specific) messages. 442 3. The MS progresses to an authentication phase. Authentication is 443 based on PKMv2 as defined in the IEEE Std 802.16 specification. 444 4. On successful completion of authentication, the MS performs 445 802.16 registration with the network. 446 5. MS and BS perform capability exchange as per 802.16 procedures. 447 Protocol support is indicated in this exchange. The CS 448 capability parameter indicates which classification/PHS options 449 and SDU encapsulation the MS supports. By default, Packet, IPv4 450 and 802.3/Ethernet shall be supported, thus absence of this 451 parameter in REG-REQ (802.16 message) means that named options 452 are supported by the MS/SS. Support for IPv6 over the IP 453 specific part of the packet CS is indicated by Bit#2 of the CS 454 capability parameter (Refer to [802.16]). 455 6. The MS MUST request the establishment of a service flow for IPv6 456 packets over IP CS if the MS and BS have confirmed capability for 457 supporting IPv6 over IP CS. The service flow MAY also be 458 triggered by the network as a result of pre-provisioning. The 459 service flow establishes a link between the MS and the AR over 460 which IPv6 packets can be sent and received. 461 7. The AR and MS SHOULD send router advertisements and solicitations 462 as specified in Neighbor discovery,[RFC4861]. 464 The above flow does not show the actual 802.16 messages that are used 465 for ranging, capability exchange or service flow establishment. 466 Details of these are in [802.16]. 468 6.3. Maximum transmission unit in 802.16 470 The MTU value for IPv6 packets on an 802.16 link is configurable. 471 The default MTU for IPv6 packets over an 802.16 link MUST be 1500 472 octets. 474 The 802.16 MAC PDU (Protocol Data Unit) is composed of a 6 byte 475 header followed by an optional payload and an optional CRC covering 476 the header and the payload. The length of the PDU is indicated by 477 the Len parameter in the Generic MAC Header. The Len parameter has a 478 size of 11 bits. Hence the total MAC PDU size is 2048 bytes. The 479 IPv6 payload size can vary. In certain deployment scenarios the MTU 480 value can be greater than the default. Neighbor Discovery for IPv6 481 [RFC4861] defines an MTU option that an AR can advertise, via router 482 advertisement (RA), to a Mobile Node (MN). If an AR advertises an 483 MTU via the RA MTU option, the MN SHOULD use the MTU from the RA. 484 Nodes that implement Path MTU discovery [RFC1981] MAY use the 485 mechanism to determine the MTU for the IPv6 packets. 487 7. IPv6 prefix assignment 489 The MS and the AR are connected via a point-to-point connection at 490 the IPv6 layer. Hence each MS can be considered to be on a separate 491 subnet. A CPE (Customer Premise Equipment) type of device which 492 serves multiple IPv6 hosts, may be the end point of the connection. 493 Hence one or more /64 prefixes SHOULD be assigned to a link. The 494 prefixes are advertised with the on-link (L-bit) flag set as 495 specified in [RFC4861]. The size and number of the prefixes is a 496 configuration issue. Also, DHCP or AAA-based prefix delegation MAY 497 be used to provide one or more prefixes to MS for an AR connected 498 over 802.16. The other properties of the prefixes are also dealt 499 with via configuration. 501 8. Router Discovery 503 8.1. Router Solicitation 505 On completion of the establishment of the IPv6 link, the MS may send 506 a router solicitation message to solicit a Router Advertisement 507 message from the AR to acquire necessary information as per the 508 neighbor discovery for IPv6 specification [RFC4861]. An MS that is 509 network attached may also send router solicitations at any time. 510 Movement detection at the IP layer of an MS in many cases is based on 511 receiving periodic router advertisements. An MS may also detect 512 changes in its attachment via link triggers or other means. The MS 513 can act on such triggers by sending router solicitations. The router 514 solicitation is sent over the IPv6 link that has been previously 515 established. The MS sends router solicitations to the all-routers 516 multicast address. It is carried over the point-to-point link to the 517 AR via the BS. The MS does not need to be aware of the link-local 518 address of the AR in order to send a router solicitation at any time. 519 The use of router advertisements as a means for movement detection is 520 not recommended for MNs connected via 802.16 links as the frequency 521 of periodic router advertisements can be high. 523 8.2. Router Advertisement 525 The AR SHOULD send a number (configurable value) of router 526 advertisements as soon as the IPv6 link is established, to the MS. 527 The AR sends unsolicited router advertisements periodically as per 528 [RFC4861]. The interval between periodic router advertisements is 529 however greater than the specification in Neighbor discovery for 530 IPv6, and is discussed in the following section. 532 8.3. Router lifetime and periodic router advertisements 534 The router lifetime SHOULD be set to a large value, preferably in 535 hours. This document over-rides the specification for the value of 536 the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) 537 [RFC4861]. The AdvDefaultLifetime in the router advertisement MUST 538 be either zero or between MaxRtrAdvInterval and 43200 seconds. The 539 default value is 2 * MaxRtrAdvInterval. 541 802.16 hosts have the capability to transition to an idle mode in 542 which case the radio link between the BS and MS is torn down. Paging 543 is required in case the network needs to deliver packets to the MS. 544 In order to avoid waking a mobile which is in idle mode and consuming 545 resources on the air interface, the interval between periodic router 546 advertisements SHOULD be set quite high. The MaxRtrAdvInterval value 547 specified in this document over-rides the recommendation in Neighbor 548 Discovery for IP Version 6 (IPv6) [RFC4861]. The MaxRtrAdvInterval 549 MUST be no less than 4 seconds and no greater than 21600 seconds. 550 The default value for MaxRtrAdvInterval is 10800 seconds. 552 9. IPv6 addressing for hosts 554 The addressing scheme for IPv6 hosts in 802.16 networks follows the 555 IETFs recommendation for hosts specified in IPv6 Node Requirement, 556 RFC 4294. The IPv6 node requirements RFC4294 [RFC4294] specifies a 557 set of RFCs that are applicable for addressing and the same is 558 applicable for hosts that use 802.16 as the link layer for 559 transporting IPv6 packets. 561 9.1. Interface Identifier 563 The MS has a 48-bit globally unique MAC address as specified in 564 802.16 [802.16]. This MAC address MUST be used to generate the 565 modified EUI-64 format-based interface identifier as specified in the 566 IP Version 6 Addressing Architecture [RFC4291]. The modified EUI-64 567 interface identifier is used in stateless address autoconfiguration. 568 As in other links that support IPv6, EUI-64 based interface 569 identifiers are not mandatory and other mechanisms, such as random 570 interface identifiers, Privacy Extensions for Stateless Address 571 Autoconfiguration in IPv6 [RFC3041] MAY also be used. 573 9.2. Duplicate address detection 575 DAD SHOULD be performed as per Neighbor Discovery for IP Version 6, 576 [RFC4861] and, IPv6 Stateless Address Autoconfiguration, [RFC4862]. 577 The IPv6 link over 802.16 is specified in this document as a point- 578 to-point link. Based on this criteria, it may be redundant to 579 perform DAD on a global unicast address that is configured using the 580 EUI-64 or generated as per RFC3041 [RFC3041] for the interface as 581 part of the IPv6 stateless address autoconfiguration protocol 582 [RFC4862] as long as the following two conditions are met: 584 1. The prefixes advertised through the router advertisement messages 585 by the access router terminating the 802.16 IPv6 link are unique 586 to that link. 587 2. The access router terminating the 802.16 IPv6 link does not 588 autoconfigure any IPv6 global unicast addresses from the prefix 589 that it advertises. 591 9.3. Stateless address autoconfiguration 593 When stateless address autoconfiguration is performed, it MUST be 594 performed as specified in [RFC4861] and, [RFC4862]. 596 9.4. Stateful address autoconfiguration 598 When stateful address autoconfiguration is performed, it MUST be 599 performed as specified in [RFC4861] and, [RFC3315]. 601 10. Multicast Listener Discovery 603 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 [RFC4861] 604 SHOULD be supported as specified by the hosts and routers attached to 605 each other via an 802.16 link. The access router which has hosts 606 attached to it via a Point-to-point link over an 802.16 SHOULD NOT 607 send periodic queries if the host is in idle/dormant mode. The AR 608 can obtain information about the state of a host from the paging 609 controller in the network. 611 11. IANA Considerations 613 This draft does not require any actions from IANA. 615 12. Security Considerations 617 This document does not introduce any new vulnerabilities to IPv6 618 specifications or operation. The security of the 802.16 air 619 interface is the subject of [802.16]. It should be noted that 802.16 620 provides capability to cipher the traffic carried over the transport 621 connections. A traffic encryption key (TEK) is generated by the MS 622 and BS on completion of successful authentication and is used to 623 secure the traffic over the air interface. An MS may still use IPv6 624 security mechanisms even in the presence of security over the 802.16 625 link. In addition, the security issues of the network architecture 626 spanning beyond the 802.16 base stations is the subject of the 627 documents defining such architectures, such as WiMAX Network 628 Architecture [WiMAXArch] in Sections 7.2 and 7.3 of Stage 2 Part 2. 630 13. Acknowledgments 632 The authors would like to acknowledge the contributions of the 16NG 633 working group chairs Soohong Daniel Park and Gabriel Montenegro as 634 well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ 635 Johnston, Dave Thaler, Bruno Sousa, Alexandru Petrescu, Margaret 636 Wasserman and Pekka Savola for their review and comments. Review and 637 comments by Phil Barber have also helped in improving the document 638 quality. 640 14. References 642 14.1. Normative References 644 [802.16] "IEEE Std 802.16e: IEEE Standard for Local and 645 metropolitan area networks, Amendment for Physical and 646 Medium Access Control Layers for Combined Fixed and Mobile 647 Operation in Licensed Bands", October 2005, . 650 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 651 for IP version 6", RFC 1981, August 1996. 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", RFC 2119, March 1997, 655 . 657 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 658 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 660 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 661 Architecture", RFC 4291, February 2006. 663 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 664 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 665 September 2007. 667 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 668 Address Autoconfiguration", RFC 4862, September 2007. 670 14.2. Informative References 672 [802.3] "IEEE Std 802.3-2005: IEEE Standard for Information 673 technology-Telecommunications and information exchange 674 between systems-Local and metropolitan area networks-- 675 Specific requirements Part 3: Carrier Sense Multiple 676 Access with Collision Detection (CSMA/CD) Access Method 677 and Physical Layer Specifications", December 2005, 678 . 680 [I-D.ietf-16ng-ip-over-ethernet-over-802.16] 681 Jeon, H., "Transmission of IP over Ethernet over IEEE 682 802.16 Networks", 683 draft-ietf-16ng-ip-over-ethernet-over-802.16-02 (work in 684 progress), July 2007. 686 [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs] 687 Madanapalli, S., "Transmission of IPv4 packets over IEEE 688 802.16's IP Convergence Sublayer", 689 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-00 (work in 690 progress), May 2007. 692 [I-D.ietf-16ng-ps-goals] 693 Jee, J., "IP over 802.16 Problem Statement and Goals", 694 draft-ietf-16ng-ps-goals-02 (work in progress), 695 August 2007. 697 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 698 Stateless Address Autoconfiguration in IPv6", RFC 3041, 699 January 2001. 701 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 702 and M. Carney, "Dynamic Host Configuration Protocol for 703 IPv6 (DHCPv6)", RFC 3315, July 2003. 705 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 706 April 2006. 708 [WMF] "http://www.wimaxforum.org". 710 [WiMAXArch] 711 "WiMAX End-to-End Network Systems Architecture http:// 712 www.wimaxforum.org/technology/documents/ 713 WiMAX_End-to-End_Network_Systems_Architecture_Stage_2- 714 3_Release_1.1.0.zip", September 2007. 716 Appendix A. WiMAX network architecture and IPv6 support 718 The WiMAX (Worldwide Interoperability for Microwave Access) forum 719 [WMF] has defined a network architecture in which the air interface 720 is based on the IEEE 802.16 standard. The addressing and operation 721 of IPv6 described in this document is applicable to the WiMAX network 722 as well. 724 WiMAX is an example architecture of a network that uses the 802.16 725 specification for the air interface. WiMAX networks are also in the 726 process of being deployed in various parts of the world and the 727 operation of IPv6 within a WiMAX network is explained in this 728 appendix. 730 The WiMAX network architecture consists of the Access Service Network 731 (ASN) and the Connectivity Service Network (CSN). The ASN is the 732 access network which includes the BS and the AR in addition to other 733 functions such as AAA, Mobile IP Foreign agent, Paging controller, 734 Location Register etc. The ASN is defined as a complete set of 735 network functions needed to provide radio access to a WiMAX 736 subscriber. The ASN is the access network to which the MS attaches. 737 The IPv6 access router is an entity within the ASN. The term ASN is 738 specific to the WiMAX network architecture. The CSN is the entity 739 that provides connectivity to the Internet and includes functions 740 such as Mobile IP Home agent and AAA. The figure below shows the 741 WiMAX reference model: 743 ------------------- 744 | ---- ASN | |----| 745 ---- | |BS|\ R6 -------| |---------| | CSN| 746 |MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | | 747 ---- | |R8 /--|------|----| |-----|Home| 748 | ---- / | | visited| | NSP| 749 | |BS|/ | | NSP | | | 750 | ---- | |---------| | | 751 | NAP | \ |----| 752 ------------------- \---| / 753 | | / 754 | (--|------/----) 755 |R4 ( ) 756 | ( ASP network ) 757 --------- ( or Internet ) 758 | ASN | ( ) 759 --------- (----------) 761 Figure 7: WiMAX Network reference model 763 Three different types of ASN realizations called profiles are defined 764 by the architecture. ASNs of profile types A and C include BS' and 765 ASN-gateway(s) (ASN-GW) which are connected to each other via an R6 766 interface. An ASN of profile type B is one in which the 767 functionality of the BS and other ASN functions are merged together. 768 No ASN-GW is specifically defined in a profile B ASN. The absence of 769 the R6 interface is also a profile B specific characteristic. The MS 770 at the IPv6 layer is associated with the AR in the ASN. The AR may 771 be a function of the ASN-GW in the case of profiles A and C and is a 772 function in the ASN in the case of profile B. When the BS and the AR 773 are separate entities and linked via the R6 interface, IPv6 packets 774 between the BS and the AR are carried over a GRE tunnel. The 775 granularity of the GRE tunnel should be on a per MS basis or on a per 776 service flow basis (an MS can have multiple service flows, each of 777 which are identified uniquely by a service flow ID). The protocol 778 stack in WiMAX for IPv6 is shown below: 780 |-------| 781 | App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 782 | | 783 |-------| /------ ------- 784 | | / IPv6 | | | 785 | IPv6 |- - - - - - - - - - - - - - - - / | | |--> 786 | | --------------- -------/ | | IPv6| 787 |-------| | \Relay/ | | | |- - - | | 788 | | | \ / | | GRE | | | | 789 | | | \ /GRE | - | | | | | 790 | |- - - | |-----| |------| | | | 791 | IPv6CS| |IPv6CS | IP | - | IP | | | | 792 | ..... | |...... |-----| |------|--------| |-----| 793 | MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 | 794 |-------| |------ |-----| |----- |--------| |-----| 795 | PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 | 796 -------- --------------- ----------------- ------- 798 MS BS AR/ASN-GW CSN Rtr 800 Figure 8: WiMAX protocol stack 802 As can be seen from the protocol stack description, the IPv6 end- 803 points are constituted in the MS and the AR. The BS provides lower 804 layer connectivity for the IPv6 link. 806 Appendix B. IPv6 link in WiMAX 808 WiMAX is an example of a network based on the IEEE Std 802.16 air 809 interface. This section describes the IPv6 link in the context of a 810 WiMAX network. The MS and the AR are connected via a combination of 811 : 813 1. The transport connection which is identified by a Connection 814 Identifier (CID) over the air interface, i.e the MS and BS and, 815 2. A GRE tunnel between the BS and AR which transports the IPv6 816 packets 818 From an IPv6 perspective the MS and the AR are connected by a point- 819 to-point link. The combination of transport connection over the air 820 interface and the GRE tunnel between the BS and AR creates a (point- 821 to-point) tunnel at the layer below IPv6. 823 The collection of service flows (tunnels) to an MS is defined as a 824 single link. Each link has only an MS and an AR. Each MS belongs to 825 a different link. No two MSs belong to the same link. A different 826 prefix should be assigned to each unique link. This link is fully 827 consistent with a standard IP link, without exception and conforms 828 with the definition of a point-to-point link in [RFC4861]. 830 Appendix C. IPv6 link establishment in WiMAX 832 The mobile station performs initial network entry as specified in 833 802.16. On successful completion of the network entry procedure the 834 ASN gateway/AR triggers the establishment of the initial service flow 835 (ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the 836 ASN-GW/AR and the BS. The BS in turn requests the MS to establish a 837 transport connection over the air interface. The end result is a 838 transport connection over the air interface for carrying IPv6 packets 839 and a GRE tunnel between the BS and AR for relaying the IPv6 packets. 840 On successful completion of the establishment of the ISF, IPv6 841 packets can be sent and received between the MS and AR. The ISF 842 enables the MS to communicate with the AR for host configuration 843 procedures. After the establishment of the ISF, the AR can send a 844 router advertisement to the MS. An MS can establish multiple service 845 flows with different QoS characteristics. The ISF can be considered 846 as the primary service flow. The ASN-GW/ AR treats each ISF, along 847 with the other service flows to the same MS, as a unique link which 848 is managed as a (virtual) interface. 850 Appendix D. Maximum transmission unit in WiMAX 852 The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. 853 Hence the IPv6 path MTU can be 1500 octets. However because of the 854 overhead of the GRE tunnel used to transport IPv6 packets between the 855 BS and AR and the 6 byte MAC header over the air interface, using a 856 value of 1500 would result in fragmentation of packets. It is 857 recommended that the default MTU for IPv6 be set to 1400 octets for 858 the MS in WiMAX networks. Note that the 1522 octet specification is 859 a WiMAX forum specification and not the size of the SDU that can be 860 transmitted over 802.16, which has a higher limit. 862 Authors' Addresses 864 Basavaraj Patil 865 Nokia Siemens Networks 866 6000 Connection Drive 867 Irving, TX 75039 868 USA 870 Email: basavaraj.patil@nsn.com 872 Frank Xia 873 Huawei USA 874 1700 Alma Dr. Suite 100 875 Plano, TX 75075 877 Email: xiayangsong@huawei.com 879 Behcet Sarikaya 880 Huawei USA 881 1700 Alma Dr. Suite 100 882 Plano, TX 75075 884 Email: sarikaya@ieee.org 886 JinHyeock Choi 887 Samsung AIT 888 Networking Technology Lab 889 P.O.Box 111 890 Suwon, Korea 440-600 892 Email: jinchoe@samsung.com 894 Syam Madanapalli 895 Ordyn Technologies 896 1st Floor, Creator Building, ITPL. 897 Off Airport Road 898 Bangalore, India 560066 900 Email: smadanapalli@gmail.com 902 Full Copyright Statement 904 Copyright (C) The IETF Trust (2007). 906 This document is subject to the rights, licenses and restrictions 907 contained in BCP 78, and except as set forth therein, the authors 908 retain all their rights. 910 This document and the information contained herein are provided on an 911 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 912 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 913 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 914 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 915 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 916 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 918 Intellectual Property 920 The IETF takes no position regarding the validity or scope of any 921 Intellectual Property Rights or other rights that might be claimed to 922 pertain to the implementation or use of the technology described in 923 this document or the extent to which any license under such rights 924 might or might not be available; nor does it represent that it has 925 made any independent effort to identify any such rights. Information 926 on the procedures with respect to rights in RFC documents can be 927 found in BCP 78 and BCP 79. 929 Copies of IPR disclosures made to the IETF Secretariat and any 930 assurances of licenses to be made available, or the result of an 931 attempt made to obtain a general license or permission for the use of 932 such proprietary rights by implementers or users of this 933 specification can be obtained from the IETF on-line IPR repository at 934 http://www.ietf.org/ipr. 936 The IETF invites any interested party to bring to its attention any 937 copyrights, patents or patent applications, or other proprietary 938 rights that may cover technology that may be required to implement 939 this standard. Please address the information to the IETF at 940 ietf-ipr@ietf.org. 942 Acknowledgment 944 Funding for the RFC Editor function is provided by the IETF 945 Administrative Support Activity (IASA).