idnits 2.17.1 draft-ietf-16ng-ipv6-over-ipv6cs-01.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 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 660. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 23, 2006) is 6394 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: 'RFC3756' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC4921' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'WiMAXArch' is defined on line 577, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 3314 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3756 ** Downref: Normative reference to an Informational RFC: RFC 4135 ** Obsolete normative reference: RFC 4294 (Obsoleted by RFC 6434) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Basavaraj. Patil 3 Internet-Draft Nokia 4 Intended status: Standards Track Frank. Xia 5 Expires: April 26, 2007 Behcet. Sarikaya 6 Huawei USA 7 JH. Choi 8 Samsung AIT 9 Syam. Madanapalli 10 LogicaCMG 11 October 23, 2006 13 IPv6 Over IPv6 Convergence sublayer in 802.16 Networks 14 draft-ietf-16ng-ipv6-over-ipv6cs-01 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 April 26, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 The IEEE 802.16d/e has specified several convergence sublayers which 48 are a part of the MAC that can be used for carrying IPv6 packets. 50 The IPv6 convergence sublayer enables transport of IPv6 packets 51 directly over the MAC. Between the 802.16d/e host and the base 52 station IPv6 packets are carried over a MAC layer transport 53 connection which is a virtual point-to-point link. This document 54 specifies the addressing and operation of IPv6 hosts served by a 55 network that utilizes the 802.16d/e air interface. It recommends the 56 assignment of a unique prefix to each host and allow the host to use 57 multiple identifiers within that prefix, including support for 58 randomly generated identifiers. 60 Table of Contents 62 1. Conventions used in this document . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. IEEE 802.16d/e convergence sublayer support for IPv6 . . . . . 4 66 5. Generic network architecture using the 802.16d/e air 67 interface . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5.1. WiMAX network architecture and IPv6 support . . . . . . . 6 69 6. IPv6 link . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. IPv6 link in 802.16 . . . . . . . . . . . . . . . . . . . 8 71 6.1.1. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . . 8 72 6.2. IPv6 link establishment in 802.16 . . . . . . . . . . . . 8 73 6.2.1. IPv6 link establishment in WiMAX . . . . . . . . . . . 9 74 6.3. Maximum transmission unit in 802.16 . . . . . . . . . . . 9 75 6.3.1. Maximum transmission unit in WiMAX . . . . . . . . . . 10 76 7. IPv6 prefix assignment . . . . . . . . . . . . . . . . . . . . 10 77 8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Router Solictation . . . . . . . . . . . . . . . . . . . . 10 79 8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 11 80 8.3. Router lifetime and periodic router advertisements . . . . 11 81 9. IPv6 addressing for hosts . . . . . . . . . . . . . . . . . . 11 82 9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 11 83 9.2. Duplicate address detection . . . . . . . . . . . . . . . 11 84 9.3. Stateless address autoconfiguration . . . . . . . . . . . 11 85 9.4. Stateful address autoconfiguration . . . . . . . . . . . . 12 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 91 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 93 Intellectual Property and Copyright Statements . . . . . . . . . . 15 95 1. Conventions used in this document 97 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 98 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 99 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 100 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 101 levels for compliant implementations. 103 2. Introduction 105 IPv6 transport over the IEEE 802.16d/e specified air interface can be 106 accomplished via either the IPv6 convergence sublayer or the Ethernet 107 convergence sublayer. The 802.16d/e [802.16e] specification includes 108 the Phy and MAC details. The convergence sublayers are a part of the 109 MAC. This document specifies IPv6 from the perspective of the IPv6 110 convergence sublayer. The mobile station/host is attached to an 111 access router via a base station (BS). The host and the BS are 112 conected via the 802.16d/e at the link and physical layers. The IPv6 113 layer terminates at an access router which may be a part of the BS or 114 an entity beyond the BS. The base station is a layer 2 entity and 115 relays the IPv6 packets between the AR and the host via a point-to- 116 point connection over the air interface. The WiMAX (Worldwide 117 Interoperability for Microwave Access) forum has defined a network 118 architecture in which the air interface is based on the 802.16d/e 119 standard. The addressing and operation of IPv6 described in this 120 document is applicable to the WiMAX network as well. 122 3. Terminology 124 The terminology is based on the definitions used in the network 125 architecture specified by the WiMAX forum. 127 BS - The Base Station (BS) is a logical entity that embodies a full 128 instance of the 802.16d/e MAC and PHY in compliance with the IEEE 129 802.16 suite of applicable standards. It provides the layer 1/2 130 connectivity between the network and the MS. 132 MS - The mobile station is an IPv6 host that connects to the AR in 133 the network via an 802.16d/e module. 135 Transport Connection - 802.16 MAC is connection oriented. Several 136 types of connections are defined and these include broadcast, unicast 137 and multicast. Each connection is uniquely identified by a 16 bit 138 connection identifier (CID). A transport connection is a unicast 139 connection intended for user traffic. A transport connection is 140 identified by an uplink and downlink CID. The scope of the transport 141 connection is between the MS and the BS. 143 Access Service Network (ASN) - The ASN is defined as a complete set 144 of network functions needed to provide radio access to a WiMAX 145 subscriber. The ASN is the access network to which the MS attaches. 146 The IPv6 access router is an entity within the ASN. 148 Access Router (AR) - The Access router is the 1st hop default IPv6 149 router from the perspective of the MS. The AR is an entity that can 150 be an integral part of the BS or a separate entity within the access 151 network. 153 4. IEEE 802.16d/e convergence sublayer support for IPv6 155 IEEE 802.16d/e has specified multiple convergence sublayers (CS) in 156 the MAC. The convergence sublayers and MAC specifications are 157 available in [802.16e]. IPv6 can be implemented in two ways: 159 1. Over the IPv6 convergence sublayer or 160 2. Over Ethernet (which runs over Ethernet CS). 162 The figure below shows the options for IPv6 implementation in WiMAX: 164 -------------- --------------- 165 | IPv6 | | IPV6 | 166 -------------- --------------- 167 | IPv6 CS | | Ethernet | 168 | .......... | --------------- 169 | MAC | | Ethernet CS | 170 -------------- | ........... | 171 | PHY | | MAC | 172 -------------- --------------- 173 IPv6 over IPv6 CS | PHY | 174 --------------- 175 IPv6 over Ethernet 177 Figure 1: IPv6 over IPv6 CS and over Ethernet 179 The scope of this document is limited to IPv6 operation over IPv6 CS 180 only. 182 5. Generic network architecture using the 802.16d/e air interface 184 In a network that utilizes the 802.16d/e air interface the host/MS is 185 attached to an IPv6 access router (AR) in the network. The BS is a 186 layer 2 entity only. The AR can be an integral part of the BS or the 187 AR could be an entity beyond the BS within the access network. IPv6 188 packets between the MS and BS are carried over a transport connection 189 which has a unique connection identifier (CID). The transport 190 connection is a MAC layer link between the MS and the BS. The 191 figures below describe the possible network architectures and are 192 generic in nature. More esoteric architectures are possible but not 193 considered in the scope of this document. Option A: 195 +-----+ CID1 +--------------+ 196 | MS1 |------------/| BS/AR |-----[Internet] 197 +-----+ / +--------------+ 198 . /---/ 199 . CIDn 200 +-----+ / 201 | MSn |---/ 202 +-----+ 204 Figure 2: The IPv6 AR as an integral part of the BS 206 Option B: 208 +-----+ CID1 +-----+ +-----------+ 209 | MS1 |----------/| BS1 |----------| AR |-----[Internet] 210 +-----+ / +-----+ +-----------+ 211 . / ____________ 212 . CIDn / ()__________() 213 +-----+ / L2 Tunnel 214 | MSn |-----/ 215 +-----+ 217 Figure 3: The IPv6 AR is separate from the BS, which acts as a bridge 219 The above network models serve as examples and are shown to 220 illustrate the point to point link between the MS and the AR. The 221 next section shows a realization of the generic architecture by the 222 WiMAX forum. 224 5.1. WiMAX network architecture and IPv6 support 226 The WiMAX network architecture consists of the Access Service Network 227 (ASN) and the Connectivity Service Network (CSN). The ASN is the 228 access network which includes the BS and the AR in addition to other 229 functions such as AAA, Mobile IP Foreign agent, Paging controller, 230 Location Register etc. The CSN is the entity that provides 231 connectivity to the Internet and includes functions such as Mobile IP 232 Home agent and AAA. The figure below shows the WiMAX reference 233 model: 235 ------------------- 236 | ---- ASN | |----| 237 ---- | |BS|\ R6 -------| |---------| | CSN| 238 |MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | | 239 ---- | |R8 /--|------|----| |-----|Home| 240 | ---- / | | visited| | NSP| 241 | |BS|/ | | NSP | | | 242 | ---- | |---------| | | 243 | NAP | \ |----| 244 ------------------- \---| / 245 | | / 246 | (--|------/----) 247 |R4 ( ) 248 | ( ASP network ) 249 --------- ( or Internet ) 250 | ASN | ( ) 251 --------- (----------) 253 Figure 4: WiMAX Network reference model 255 Three different types of ASN realizations called profiles are defined 256 by the architecture. ASNs of profile types A and C include BS' and 257 ASN-gateway(s) which are connected to each other via an R6 interface. 258 An ASN of profile type B is one in which the functionality of the BS 259 and other ASN functions are merged together. No ASN-GW is 260 specifically defined in a profile B ASN. However all the functions 261 of an ASN such as the MIP4 FA, AAA, AR exist within the scope of an 262 ASN. The absence of the R6 interface is also a profile B specific 263 characteristic. The MS at the IPv6 layer is associated with the AR 264 in the ASN. The AR may be a function of the ASN-GW in the case of 265 profiles A and C and is a function in the ASN in the case of profile 266 B. When the BS and the AR are separate entities and linked via the R6 267 interface, IPv6 packets between the BS and the AR are carried over a 268 GRE tunnel. The granularity of the GRE tunnel can be on a per flow 269 basis, per MS basis or on a BS basis. The protocol stack in WiMAX 270 for IPv6 is shown below: 272 |-------| 273 | App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 274 | | 275 |-------| /------ ------- 276 | | / IPv6 | | | 277 | IPv6 |- - - - - - - - - - - - - - - - / | | |--> 278 | | --------------- -------/ | | IPv6| 279 |-------| | \Relay/ | | | |- - - | | 280 | | | \ / | | GRE | | | | 281 | | | \ /GRE | - | | | | | 282 | |- - - | |-----| |------| | | | 283 | IPv6CS| |IPv6CS | IP | - | IP | | | | 284 | ..... | |...... |-----| |------|--------| |-----| 285 | MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 | 286 |-------| |------ |-----| |----- |--------| |-----| 287 | PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 | 288 -------- --------------- ----------------- ------- 290 MS BS AR/ASN-GW CSN Rtr 292 Figure 5: WiMAX protocol stack 294 As can be seen from the protocol stack description, the IPv6 end- 295 points are constituted in the MS and the AR. The BS provides lower 296 layer connectivity for the IPv6 link. 298 6. IPv6 link 300 RFC 2461 defines link as a communication facility or medium over 301 which nodes can communicate at the link layer, i.e., the layer 302 immediately below IP [RFC2461]. Usually a link is bounded by routers 303 that decrement TTL. When an MS moves within a link, it can keep 304 using its IP addresses. This is a layer 3 definition and note that 305 the definition is not identical with the definition of the term '(L2) 306 link' in IEEE 802 standards. This section presents a model for the 307 last mile link, i.e. the link to which MSs attach themselves. 309 6.1. IPv6 link in 802.16 311 For 802.16 network, following the 3GPP precedent [RFC3314], point-to- 312 point link model is recommended. In 802.16, there exists L2 layer 313 Transport Connection between an MS and a BS over which packets are 314 transferred. A Transport Connection is represented by CID 315 (Connection Identifier) and multiple Transport Connections can be 316 assigned to an MS. 318 When an AR and a BS is collocated, the collection of Transport 319 Connections to an MS is defined as a single link. When an AR and a 320 BS is separated, it is recommended that a tunnel is established 321 between the AR and a BS whose granuality is no greater than 'per MS'. 322 Then the tunnel(s) for an MS, in combination with the MS's Transport 323 Connections, forms a single point-to-point link. 325 6.1.1. IPv6 link in WiMAX 327 The MS and the AR are connected via a combination of : 329 1. The transport connection which is identified by a Connection 330 Identifier (CID) over the air interface, i.e the MS and BS and, 331 2. A GRE tunnel between the BS and AR which transports the IPv6 332 packets 334 From an IPv6 perspective the MS and the AR are connected by a point- 335 to-point link. The combination of transport connection over the air 336 interface and the GRE tunnel between the BS and AR creates a (point- 337 to-point) tunnel at the layer below IPv6. 339 The collection of service flows (tunnels) to an MS is defined as a 340 single link. Each link has only an MS and an AR. Each MS belongs to 341 a different link. No two MSs belong to the same link. A different 342 prefix should be assigned to a different link. This link is fully 343 consistent with a standard IP link, without exception and conforms 344 with the definition of a point-to-point link in RFC2461 [RFC2461]. 346 6.2. IPv6 link establishment in 802.16 348 The MS goes through the network entry procedure as specified by 349 802.16d/e. At a high level the network entry procedure can be 350 described as follows: 352 1. MS performs initial ranging with the BS. Ranging is a process by 353 which an MS becomes time aligned with the BS. The MS is 354 synchronized with the BS at the succesful completion of ranging 355 and is ready to setup a connection. 357 2. The MS does capability exchange with the BS. As part of this 358 step, the MS indicates its capability which includes support for 359 IPv6 convergence sublayer among others. 360 3. The MS now progresses to an authentication phase. Authentication 361 is based on PKMv2 as defined in the 802.16e specification. 362 4. On succesfull completion of authentication, the MS performs 363 802.16e registration with the network. 364 5. The MS can request the establishment of a service flow over the 365 IPv6 convergence sublayer. The service flow can also be 366 triggered by the network as a result of pre-provisioning. The 367 service flow establishes a link between the MS and the AR over 368 which IPv6 packets can be sent and received. 369 6. The AR sends a router advertisement to the MS. 371 The above flow does not show the actual 802.16e messages that are 372 used for ranging, capability exchange or service flow establishment. 373 Details of these are in [802.16e]. 375 6.2.1. IPv6 link establishment in WiMAX 377 The mobile station performs initial network entry as specified in 378 802.16e. On succesful completion of the network entry procedure the 379 ASN gateway/AR triggers the establishment of the initial service flow 380 (ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the 381 ASN-GW/AR and the BS. The BS in turn requests the MS to establish a 382 transport connection over the air interface. The end result is a 383 transport connection over the air interface for carrying IPv6 packets 384 and a GRE tunnel between the BS and AR for relaying the IPv6 packets. 385 On succesful completion of the establishment of the ISF, IPv6 packets 386 can be sent and received between the MS and AR. The ISF enables the 387 MS to communicate with the AR for host configuration procedures. 388 After the establishment of the ISF, the AR can send a router 389 advertisement to the MS. An MS can establish multiple service flows 390 with different QoS characteristics. The ISF can be considered as the 391 primary service flow. The ASN GW/ AR treats each ISF, along with the 392 other service flows to the same MS, as a unique link which is managed 393 as a (virtual) interface. 395 6.3. Maximum transmission unit in 802.16 397 The MAC PDU is of the format shown in the figure below: 399 |--------------------------//----------------| 400 |Generic MAC HDR | Payload | CRC | 401 |-------------------------//-----------------| 402 Figure 6: MAC PDU Format 404 The MAC HDR is a 6 byte header followed by the payload and a 4 byte 405 CRC which covers the whole PDU. The length of the PDU is indicated 406 by the Len parameter in the Generic MAC HDR. The Len parameter has a 407 size of 11 bits. Hence the total PDU size is 2048 bytes. The IPv6 408 payload can be a max value of 2038 bytes (MAC HDR - CRC). IPv6 MTU 409 for 802.16 may be a value which is less than 2038 bytes. 411 6.3.1. Maximum transmission unit in WiMAX 413 The WiMAX forum [WMF] has specified the SDU size as 1522 octets. 414 Hence the IPv6 path MTU can be 1500 octets. However because of the 415 overhead of the GRE tunnel used to transport IPv6 packets between the 416 BS and AR and the 6 byte MAC header over the air interface, using a 417 value of 1500 would result in fragmentation of packets. It is 418 recommended that the default MTU for IPv6 be set to 1400 octets for 419 the MS. Note that the 1522 octet specification is a WiMAX forum 420 specification and not the size of the SDU that can be transmitted 421 over 802.16d/e, which is higher. RFC2461 [RFC2461] recommends that 422 IPv6 nodes implement Path MTU discovery. In such cases the default 423 value can be over-ridden. Additionally if the 802.16d/e MAC layer 424 can provide an indication of the MTU size to be used, the MS can use 425 that as the default MTU. 427 7. IPv6 prefix assignment 429 Each MS can be considered to be on a separate subnet as a result of 430 the point-to-point connection. A CPE type of device which serves 431 multiple IPv6 hosts, may be the end point of the connection. Hence 432 one or more /64 prefixes should be assigned to a link. The prefixes 433 are advertised with the on-link (L-bit) flag set to facilitate 434 Detecting Network Attachment (DNA) operation [RFC4135]. 436 8. Router Discovery 438 8.1. Router Solictation 440 On completion of the establishment of the IPv6 link, the MS may send 441 a router solicitation message to solicit a Router Advertisement 442 message from the AR to acquire necessary information as specified in 443 RFC2461 [RFC2461]. An MS that is network attached may also send 444 router solicitations at any time. 446 8.2. Router Advertisement 448 The AR should send a number of router advertisements as soon as the 449 IPv6 link is established to the MS [FRD]. The AR may send 450 unsolicited router advertisements periodically as specified in 451 RFC2461 [RFC2461]. However to conserve the battery lifetime of hosts 452 and to conserve radio resources over the air interface, unsolicited 453 router advertisement transmission are not recommended. 455 8.3. Router lifetime and periodic router advertisements 457 The router lifetime should be set to a large value, preferably in 458 hours. 802.16d/e hosts have the capability to transition to an idle 459 mode in which case the radio link between the BS and MS is torn down. 460 Paging is required in case the network needs to deliver packets to 461 the MS. In order to avoid waking a mobile which is in idle mode and 462 consuming resources on the air interface, the interval between 463 periodic router advertisements should be set quite high. The 464 MaxRtrAdvInterval should be configurable to a value which is greater 465 than 1800 seconds. 467 9. IPv6 addressing for hosts 469 The addressing scheme for IPv6 hosts in 802.16 network follows the 470 IETFs recommendation for hosts specified in RFC 4294. The IPv6 node 471 requirements RFC RFC4294 [RFC4294] specifies a set of RFCs that are 472 applicable for addressing. 474 9.1. Interface Identifier 476 The MS has a 48-bit MAC address as specified in 802.16e [802.16e]. 477 This MAC address is used to generate the 64 bit interface identifier 478 which is used by the MS for address autoconfiguration. The IID is 479 generated by the MS as specified in RFC2464 [RFC2464]. For addresses 480 that are based on privacy extensions, the MS may generate random IIDs 481 as specified in RFC3041 [RFC3041]. 483 9.2. Duplicate address detection 485 DAD is performed as per RFC2461 [RFC2461] and, RFC2462 [RFC2462]. 487 9.3. Stateless address autoconfiguration 489 If the A-bit in the prefix information option (PIO) are set, the MS 490 performs stateless address autoconfiguration as per RFC 2461, 2462. 491 The AR is the default router that advertises a unique /64 prefix (or 492 prefixes) that is used by the MS to configure an address. 494 9.4. Stateful address autoconfiguration 496 The Stateful Address Autoconfiguration is invoked if the M-flag is 497 set in the Router Advertisement. Obtaining the IPv6 address through 498 stateful address autoconfiguration method is specified in the RFC3315 499 [RFC3315]. 501 10. IANA Considerations 503 This draft does not require any actions from IANA. 505 11. Security Considerations 507 This document does not introduce any new vulnerabilities to IPv6 508 specifications or operation as a result of the 802.16d/e air 509 interface or the WiMAX network architecture. 511 12. Acknowledgments 513 TBD. 515 13. References 517 13.1. Normative References 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", RFC 2119, March 1997, 521 . 523 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 524 Discovery for IP Version 6 (IPv6)", RFC 2461, 525 December 1998, . 527 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 528 Autoconfiguration", RFC 2462, December 1998, 529 . 531 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 532 Networks", RFC 2464, December 1998, 533 . 535 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 536 Stateless Address Autoconfiguration in IPv6", RFC 3041, 537 January 2001, . 539 [RFC3314] Wasserman, Ed., M., "Recommendations for IPv6 in Third 540 Generation Partnership Project (3GPP) Standards", 541 RFC 3314, September 2002, 542 . 544 [RFC3315] Droms, Ed., R., Bound, J., Volz, B., Lemon, T., Perkins, 545 C., and M. Carney, "Dynamic Host Configuration Protocol 546 for IPv6 (DHCPv6)", RFC 3315, July 2003, 547 . 549 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 550 Discovery (ND) Trust Models and Threats", RFC 3756, 551 May 2004, . 553 [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network 554 Attachment in IPv6", RFC 4135, August 2005, 555 . 557 [RFC4294] Loughney, Ed., J., "IPv6 Node requirements", RFC 4294, 558 April 2006, . 560 [RFC4921] Hinden, R. and S. Deering, "IP Version 6 Addressing 561 Architecture", RFC 4921, February 2006, 562 . 564 13.2. Informative References 566 [802.16e] "IEEE Std 802.16e: IEEE Standard for Local and 567 metropolitan area networks, Amendment for Physical and 568 Medium Access Control Layers for Combined Fixed and Mobile 569 Operation in Licensed Bands", October 2005. 571 [FRD] Choi, JH., Shin, DongYun., and W. Haddad, "Fast Router 572 Discovery with L2 support", August 2006, . 575 [WMF] "http://www.wimaxforum.org". 577 [WiMAXArch] 578 "WiMAX End-to-End Network Systems Architecture 579 http://www.wimaxforum.org/technology/documents", 580 August 2006. 582 Authors' Addresses 584 Basavaraj Patil 585 Nokia 586 6000 Connection Drive 587 Irving, TX 75039 588 USA 590 Email: basavaraj.patil@nokia.com 592 Frank Xia 593 Huawei USA 594 1700 Alma Dr. Suite 100 595 Plano, TX 75075 597 Email: xiayangsong@huawei.com 599 Behcet Sarikaya 600 Huawei USA 601 1700 Alma Dr. Suite 100 602 Plano, TX 75075 604 Email: sarikaya@ieee.org 606 JinHyeock Choi 607 Samsung AIT 608 Networking Technology Lab 609 P.O.Box 111 610 Suwon, Korea 440-600 612 Email: jinchoe@samsung.com 614 Syam Madanapalli 615 LogicaCMG 616 125 Yemlur P.O. 617 Off Airport Road 618 Bangalore, India 560037 620 Email: smadanapalli@gmail.com 622 Full Copyright Statement 624 Copyright (C) The Internet Society (2006). 626 This document is subject to the rights, licenses and restrictions 627 contained in BCP 78, and except as set forth therein, the authors 628 retain all their rights. 630 This document and the information contained herein are provided on an 631 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 632 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 633 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 634 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 635 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 636 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 638 Intellectual Property 640 The IETF takes no position regarding the validity or scope of any 641 Intellectual Property Rights or other rights that might be claimed to 642 pertain to the implementation or use of the technology described in 643 this document or the extent to which any license under such rights 644 might or might not be available; nor does it represent that it has 645 made any independent effort to identify any such rights. Information 646 on the procedures with respect to rights in RFC documents can be 647 found in BCP 78 and BCP 79. 649 Copies of IPR disclosures made to the IETF Secretariat and any 650 assurances of licenses to be made available, or the result of an 651 attempt made to obtain a general license or permission for the use of 652 such proprietary rights by implementers or users of this 653 specification can be obtained from the IETF on-line IPR repository at 654 http://www.ietf.org/ipr. 656 The IETF invites any interested party to bring to its attention any 657 copyrights, patents or patent applications, or other proprietary 658 rights that may cover technology that may be required to implement 659 this standard. Please address the information to the IETF at 660 ietf-ipr@ietf.org. 662 Acknowledgment 664 Funding for the RFC Editor function is provided by the IETF 665 Administrative Support Activity (IASA).