idnits 2.17.1 draft-ietf-16ng-ipv6-over-ipv6cs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 794. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 15, 2006) is 6340 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: 'FRD' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC2464' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'RFC3756' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC4135' is defined on line 565, 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) == Outdated reference: A later version (-04) exists of draft-ietf-16ng-ps-goals-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Basavaraj Patil 3 Internet-Draft Nokia 4 Intended status: Standards Track Frank Xia 5 Expires: June 18, 2007 Behcet Sarikaya 6 Huawei USA 7 JH. Choi 8 Samsung AIT 9 Syam Madanapalli 10 LogicaCMG 11 December 15, 2006 13 IPv6 Over the IP Specific part of the Packet Convergence sublayer in 14 802.16 Networks 15 draft-ietf-16ng-ipv6-over-ipv6cs-03 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 18, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2006). 46 Abstract 48 IEEE Std 802.16 is an air interface specification. IEEE has 49 specified several service specific convergence sublayers (CS) for 50 802.16 which are used by upper layer protocols. The ATM CS and 51 Packet CS are the two main service-specific convergence sublayers and 52 these are a part of the 802.16 MAC which the upper layers interface 53 to.The packet CS is used for transport for all packet-based protocols 54 such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE 55 Std 802.1Q (VLAN). The IP specific part of the Packet CS enables 56 transport of IPv6 packets directly over the MAC. This document 57 specifies the addressing and operation of IPv6 over the IPv6 specific 58 part of the packet CS for hosts served by a network that utilizes the 59 IEEE Std 802.16 air interface. It recommends the assignment of a 60 unique prefix (or prefixes) to each host and allows the host to use 61 multiple identifiers within that prefix, including support for 62 randomly generated identifiers. 64 Table of Contents 66 1. Conventions used in this document . . . . . . . . . . . . . . 4 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. IEEE 802.16 convergence sublayer support for IPv6 . . . . . . 5 70 4.1. IPv6 encapsulation over the IP CS of the MAC . . . . . . . 7 71 5. Generic network architecture using the 802.16 air interface . 7 72 6. IPv6 link . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6.1. IPv6 link in 802.16 . . . . . . . . . . . . . . . . . . . 9 74 6.2. IPv6 link establishment in 802.16 . . . . . . . . . . . . 9 75 6.3. Maximum transmission unit in 802.16 . . . . . . . . . . . 10 76 7. IPv6 prefix assignment . . . . . . . . . . . . . . . . . . . . 10 77 8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 11 79 8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 11 80 8.3. Router lifetime and periodic router advertisements . . . . 11 81 9. IPv6 addressing for hosts . . . . . . . . . . . . . . . . . . 12 82 9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 12 83 9.2. Duplicate address detection . . . . . . . . . . . . . . . 12 84 9.3. Stateless address autoconfiguration . . . . . . . . . . . 12 85 9.4. Stateful address autoconfiguration . . . . . . . . . . . . 12 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 91 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 92 Appendix A. WiMAX network architecture and IPv6 support . . . . . 14 93 Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 16 94 Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 17 95 Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 17 96 Appendix E. Stateless address autoconfiguration . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 98 Intellectual Property and Copyright Statements . . . . . . . . . . 19 100 1. Conventions used in this document 102 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 103 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 104 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 105 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 106 levels for compliant implementations. 108 2. Introduction 110 IPv6 packets can be carried over the IEEE Std 802.16 specified air 111 interface via either: 113 1. the IP specific part of the Packet CS or, 114 2. the 802.3 specific part of the Packet CS or, 115 3. the 802.1Q specific part of the Packet CS. 117 The 802.16 [802.16] specification includes the Phy and MAC details. 118 The convergence sublayers are a part of the MAC. This document 119 specifies IPv6 from the perspective of the transmission of IPv6 over 120 the IP specific part of the packet convergence sublayer. The mobile 121 station/host is attached to an access router via a base station (BS). 122 The host and the BS are connected via the IEEE Std 802.16 air 123 interface at the link and physical layers. The IPv6 link from the MS 124 terminates at an access router which may be a part of the BS or an 125 entity beyond the BS. The base station is a layer 2 entity (from the 126 perspective of the IPv6 link between the MS and AR) and relays the 127 IPv6 packets between the AR and the host via a point-to-point 128 connection over the air interface. The WiMAX (Worldwide 129 Interoperability for Microwave Access) forum [WMF] has defined a 130 network architecture in which the air interface is based on the IEEE 131 802.16 standard. The addressing and operation of IPv6 described in 132 this document is applicable to the WiMAX network as well. The 133 various aspects of IPv6 over 802.16 as applicable to WiMAX are 134 captured in the appendix sections of this document. 136 3. Terminology 138 The terminology in this document is based on the definitions in 139 [PSDOC], in addition to the ones specified in this section. 141 Access Service Network (ASN) - The ASN is defined as a complete set 142 of network functions needed to provide radio access to a WiMAX 143 subscriber. The ASN is the access network to which the MS attaches. 144 The IPv6 access router is an entity within the ASN. The term ASN is 145 specific to the WiMAX network architecture. 147 4. IEEE 802.16 convergence sublayer support for IPv6 149 The IEEE 802.16 MAC specifies two main service specific convergence 150 sublayers: 152 1. ATM Convergence sublayer 153 2. Packet Convergence sublayer 155 The Packet CS is used for the transport of packet based protocols 156 which inclide: 158 1. IEEE Std 802.3(Ethernet) 159 2. IEEE Std 802.1Q(VLAN) 160 3. Internet Protocol (IPv4 and IPv6) 162 The service specific CS resides on top of the MAC Common Part 163 Sublayer (CPS). The service specific CS is responsible for: 165 o accepting packets (PDUs) from the upper layer, 166 o performing classification of the packet/PDU based on a set of 167 classifiers that are defined which are service specific, 168 o delivering the CS PDU to the appropriate service flow and 169 transport connection and, 170 o receiving PDUs from the peer entity. 172 Payload header suppression (PHS) is also a function of the CS but is 173 optional. 175 The figure below shows the concept of the service-specific CS in 176 relation to the MAC: 178 -----------------------------\ 179 | ATM CS | Packet CS | \ 180 ----------------------------- \ 181 | MAC Common Part Sublayer | \ 182 | (Ranging, scheduling, etc)| 802.16 MAC 183 ----------------------------- / 184 | Security | / 185 |(Auth, encryption,key mgmt)| / 186 -----------------------------/ 187 | PHY | 188 ----------------------------- 190 Figure 1: The 802.16 MAC 192 Classifiers for each of the specific upper-layer protocols, i.e 193 Ethernet, VLAN and IP, are defined which enable the packets from the 194 upper layer to be processed by the appropriate service-specific part 195 of the packet CS. IPv6 can be transported directly over the IP 196 specific part of the packet CS or over 802.3/Ethernet (which in turn 197 is handled by the Ethernet specific part of the packet CS) or over 198 802.1Q (which is handled by the 802.1Q specific part of the packet 199 CS). 201 The figure below shows the options for IPv6 transport over the packet 202 CS of 802.16: 204 ----------------- ----------------- 205 | IPv6 | | IPv6 | 206 ---------------- |---------------| |----------- | 207 | IPv6 | | Ethernet | | 802.1Q | 208 |--------------| |---------------| |----------- | 209 | IP Specific | | 802.3 specific| |802.1Q specific| 210 |part of Pkt CS| |part of Pkt CS | |part of Pkt CS | 211 |..............| |...............| |...............| 212 | MAC | | MAC | | MAC | 213 |--------------| |---------------| |---------------| 214 | PHY | | PHY | | PHY | 215 ---------------- ----------------- ----------------- 217 (1) IPv6 over (2) IPv6 over (3) IPv6 over 218 IP Specific part 802.3/Ethernet 802.1Q 219 of Packet CS 221 Figure 2: IPv6 over IP, 802.3 and 802.1Q specific parts of the Packet 222 CS 224 The scope of this document is limited to IPv6 operation over the IP 225 specific part of the Packet CS only. It should be noted that 226 immediately after ranging (802.16 air interface procedure), the MS 227 and BS exchange their capability negotiation via REG-REQ and REG-RSP. 228 These management frames negotiate parameters such as IP version and 229 Convergence Sublayer support. Additionally during the establishment 230 of the transport connection for transporting IPv6 packets, the DSA- 231 REQ and DSA-RSP messages between the BS and MS indicate via the CS- 232 Specification TLV the CS that the connection being setup shall use. 234 4.1. IPv6 encapsulation over the IP CS of the MAC 236 The IPv6 payload when carried over the IP specfic part of the Packet 237 CS is encapsulated by the 6 byte 802.16 MAC header. Header 238 suppression can also be applied to the IP packet. The format of the 239 IPv6 packet with and without header suppression is shown in the 240 figure below: 242 ---------/ /----------- 243 | MAC SDU | 244 --------/ /------------ 245 || 246 || 247 \/ 248 --------------------------------------------------------- 249 | PHSI=0 | IPv6 Packet (including Header) | 250 --------------------------------------------------------- 251 (i) IPv6 packet without header suppression 253 --------------------------------------------------------- 254 | PHSI=1 | (Header suppressed IPv6 packet) | 255 --------------------------------------------------------- 256 (ii) IPv6 packet with header suppression 258 Figure 3: IPv6 encapsulation 260 For transmission of IPv6 packets via the IP specific part of the 261 Packet CS of 802.16, the IPv6 layer interfaces with the 802.6 MAC 262 directly. The IPv6 layer delivers the IPv6 packet to the Packet CS 263 of the 802.16. The packet CS defines a set of classifiers that are 264 used to determine how to handle the packet. The IP classifiers that 265 are used at the MAC operate on the fields of the IP header and the 266 transport protocol and these include the IP ToS/DSCP, IP Protocol 267 field, Masked IP source and destination addresses and, Protocol 268 source and destination port ranges. Using the classifiers, the MAC 269 maps an upper layer packet to a specific service flow and transport 270 connection to be used. The MAC encapsulates the IPv6 packet in the 6 271 byte MAC header and transmits it. 273 5. Generic network architecture using the 802.16 air interface 275 In a network that utilizes the 802.16 air interface the host/MS is 276 attached to an IPv6 access router (AR) in the network. The BS is a 277 layer 2 entity only. The AR can be an integral part of the BS or the 278 AR could be an entity beyond the BS within the access network. IPv6 279 packets between the MS and BS are carried over a point-to-point 280 transport connection which has a unique connection identifier (CID). 281 The transport connection is a MAC layer link between the MS and the 282 BS. The figures below describe the possible network architectures 283 and are generic in nature. More esoteric architectures are possible 284 but not considered in the scope of this document. Option A: 286 +-----+ CID1 +--------------+ 287 | MS1 |------------/| BS/AR |-----[Internet] 288 +-----+ / +--------------+ 289 . /---/ 290 . CIDn 291 +-----+ / 292 | MSn |---/ 293 +-----+ 295 Figure 4: The IPv6 AR as an integral part of the BS 297 Option B: 299 +-----+ CID1 +-----+ +-----------+ 300 | MS1 |----------/| BS1 |----------| AR |-----[Internet] 301 +-----+ / +-----+ +-----------+ 302 . / ____________ 303 . CIDn / ()__________() 304 +-----+ / L2 Tunnel 305 | MSn |-----/ 306 +-----+ 308 Figure 5: The IPv6 AR is separate from the BS, which acts as a bridge 310 The above network models serve as examples and are shown to 311 illustrate the point to point link between the MS and the AR. The 312 next section shows a realization of the generic architecture by the 313 WiMAX forum. 315 6. IPv6 link 317 RFC 2461 defines link as a communication facility or medium over 318 which nodes can communicate at the link layer, i.e., the layer 319 immediately below IP [RFC2461]. A link is bounded by routers that 320 decrement TTL. When an MS moves within a link, it can keep using its 321 IP addresses. This is a layer 3 definition and note that the 322 definition is not identical with the definition of the term '(L2) 323 link' in IEEE 802 standards. This section presents a model for the 324 last mile link, i.e. the link to which MSs attach themselves. 326 6.1. IPv6 link in 802.16 328 In 802.16, there exists an L2 Transport Connection between an MS and 329 a BS which is used to transport user data, i.e IPv6 packets in this 330 case. A Transport Connection is represented by a CID (Connection 331 Identifier) and multiple Transport Connections can exist between an 332 MS and BS. 334 When an AR and a BS are collocated, the collection of Transport 335 Connections to an MS is defined as a single link. When an AR and a 336 BS are separated, it is recommended that a tunnel is established 337 between the AR and a BS whose granuality is no greater than 'per MS' 338 or 'per service flow' ( An MS can have multiple service flows which 339 are identified by a service flow ID). Then the tunnel(s) for an MS, 340 in combination with the MS's Transport connections, forms a single 341 point-to-point link. 343 The collection of service flows (tunnels) to an MS is defined as a 344 single link. Each link has only an MS and an AR. Each MS belongs to 345 a different link. No two MSs belong to the same link. A different 346 prefix should be assigned to each unique link. This link is fully 347 consistent with a standard IP link, without exception and conforms 348 with the definition of a point-to-point link in RFC2461 [RFC2461]. 349 Hence the point-to-point link model for IPv6 operation over the IP 350 specific part of the Packet CS in 802.16 is recommended. A unique 351 IPv6 prefix(es) per link (MS) is also recommended. 353 6.2. IPv6 link establishment in 802.16 355 In order to enable the sending and receiving of IPv6 packets between 356 the MS and the AR, the link between the MS and the AR via the BS 357 needs to be established. This section illustrates the link 358 establishment procedure. 360 The MS goes through the network entry procedure as specified by 361 802.16. A high level description of the network entry procedure is 362 as follows: 364 1. MS performs initial ranging with the BS. Ranging is a process by 365 which an MS becomes time aligned with the BS. The MS is 366 synchronized with the BS at the succesful completion of ranging 367 and is ready to setup a connection. 368 2. MS and BS perform capability exchange as per 802.16 procedures. 369 The CS capability parameter indicates which classification/PHS 370 options and SDU encapsulation the MS supports. By default, 371 Packet, IPv4 and 802.3/Ethernet shall be supported, thus absence 372 of this parameter in REG-REQ (802.16 message) means that named 373 options are supported by the MS/SS. Support for IPv6 over the IP 374 specific part of the packet CS is indicated by Bit#2 of the CS 375 capability parameter (Refer to [802.16]). 376 3. The MS progresses to an authentication phase. Authentication is 377 based on PKMv2 as defined in the IEEE Std 802.16 specification. 378 4. On succesfull completion of authentication, the MS performs 379 802.16 registration with the network. 380 5. The MS can request the establishment of a service flow for IPv6 381 packets over the IP specific part of the Packet CS. The service 382 flow can also be triggered by the network as a result of pre- 383 provisioning. The service flow establishes a link between the MS 384 and the AR over which IPv6 packets can be sent and received. 385 6. The AR sends a router advertisement to the MS. Alternatively or 386 in addition, the MS can also send a router solicitation. 388 The above flow does not show the actual 802.16 messages that are used 389 for ranging, capability exchange or service flow establishment. 390 Details of these are in [802.16]. 392 6.3. Maximum transmission unit in 802.16 394 The 802.16 MAC header is a 6 byte header followed by the payload and 395 a 4 byte CRC which covers the whole PDU (Protocol Data Unit). The 396 length of the PDU is indicated by the Len parameter in the Generic 397 MAC HDR. The Len parameter has a size of 11 bits. Hence the total 398 PDU size is 2048 bytes. The IPv6 payload can be a max value of 2038 399 bytes (MAC Hader - CRC). The Max value of the IPv6 MTU for 802.16 is 400 2038 bytes and the minimum value of 1280 bytes. The default MTU for 401 IPv6 over 802.16 SHOULD be the same as specified in RFC2460 which is 402 1500 octets. RFC2461 defines an MTU option that an AR can advertise 403 to an MN. If an AR advertises an MTU via the RA MTU option, the MN 404 should use the MTU from the RA. 406 7. IPv6 prefix assignment 408 Each MS can be considered to be on a separate subnet as a result of 409 the point-to-point connection. A CPE (Customer Premise Equipment) 410 type of device which serves multiple IPv6 hosts, may be the end point 411 of the connection. Hence one or more /64 prefixes should be assigned 412 to a link. The prefixes are advertised with the on-link (L-bit) flag 413 set. Each MS MUST be considered to be on a separate subnet as a 414 result of the point-to-point connection. The size and number of the 415 prefixes is a configuration issue. Also, prefix delegation may be 416 used to provide additional prefixes for a router connected over 417 802.16. The other properties of the prefixes are also a 418 configuration issue. But typically the prefixes are advertised with 419 the on-link (L-bit) flag set. 421 8. Router Discovery 423 8.1. Router Solicitation 425 On completion of the establishment of the IPv6 link, the MS may send 426 a router solicitation message to solicit a Router Advertisement 427 message from the AR to acquire necessary information as per RFC2461. 428 An MS that is network attached may also send router solicitations at 429 any time as per RFC2461. 431 8.2. Router Advertisement 433 The AR should send a number (configurable value) of router 434 advertisements as soon as the IPv6 link is established, to the MS. 435 The AR sends unsolicited router advertisements periodically as per 436 RFC2461. 438 8.3. Router lifetime and periodic router advertisements 440 The router lifetime should be set to a large value, preferably in 441 hours. This document over-rides the specification for the value of 442 the router lifetime in RFC2461 [RFC2461]. The AdvDefaultLifetime in 443 the router advertisement MUST be either zero or between 444 MaxRtrAdvInterval and 43200 seconds. The default value is 2 * 445 MaxRtrAdvInterval. 447 802.16 hosts have the capability to transition to an idle mode in 448 which case the radio link between the BS and MS is torn down. Paging 449 is required in case the network needs to deliver packets to the MS. 450 In order to avoid waking a mobile which is in idle mode and consuming 451 resources on the air interface, the interval between periodic router 452 advertisements should be set quite high. The MaxRtrAdvInterval value 453 specified in this document over-rides the recommendation in RFC2461 454 [RFC2461]. The MaxRtrAdvInterval MUST be no less than 4 seconds and 455 no greater than 21600 seconds. Thee default value for 456 MaxRtrAdvInterval is 10800 seconds. 458 9. IPv6 addressing for hosts 460 The addressing scheme for IPv6 hosts in 802.16 network follows the 461 IETFs recommendation for hosts specified in RFC 4294. The IPv6 node 462 requirements RFC RFC4294 [RFC4294] specifies a set of RFCs that are 463 applicable for addressing. 465 9.1. Interface Identifier 467 The MS has a 48-bit MAC address as specified in 802.16 [802.16]. 468 This MAC address can be used if EUI-64 -based interface identifier is 469 needed for autoconfiguration RFC4291 [RFC4291]. As in other links 470 that support IPv6, EUI-64 -based interface identifiers are not 471 mandatory and other mechanisms, such as random interface identifiers 472 RFC3041 [RFC3041] may also be used. 474 9.2. Duplicate address detection 476 DAD is performed as per RFC2461 [RFC2461] and, RFC2462 [RFC2462]. 478 9.3. Stateless address autoconfiguration 480 If the A-bit in the prefix information option (PIO) is set, the MS 481 performs stateless address autoconfiguration as per RFC 2461, 2462. 482 The AR is the default router that advertises a unique prefix (or 483 prefixes) that is used by the MS to configure an address. 485 9.4. Stateful address autoconfiguration 487 The Stateful Address Autoconfiguration is invoked if the M-flag is 488 set in the Router Advertisement. Obtaining the IPv6 address through 489 stateful address autoconfiguration method is specified in RFC3315 490 [RFC3315]. 492 10. IANA Considerations 494 This draft does not require any actions from IANA. 496 11. Security Considerations 498 This document does not introduce any new vulnerabilities to IPv6 499 specifications or operation. The security of the 802.16 air 500 interface is the subject of [802.16]. In addition, the security 501 issues of the network architecture spanning beyond the 802.16 base 502 stations is the subject of the documents defining such architectures, 503 such as WiMAX Network Architecture [WiMAXArch]. 505 12. Acknowledgments 507 The authors would like to acknowledge the contributions of the 16NG 508 working group chairs Daniel Soohong Park and Gabriel Montenegro as 509 well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ 510 Johnston and Dave Thaler for their review and comments. 512 13. References 514 13.1. Normative References 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", RFC 2119, March 1997, 518 . 520 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 521 Discovery for IP Version 6 (IPv6)", RFC 2461, 522 December 1998, . 524 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 525 Autoconfiguration", RFC 2462, December 1998, 526 . 528 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 529 Architecture", RFC 4291, February 2006, 530 . 532 13.2. Informative References 534 [802.16] "IEEE Std 802.16e: IEEE Standard for Local and 535 metropolitan area networks, Amendment for Physical and 536 Medium Access Control Layers for Combined Fixed and Mobile 537 Operation in Licensed Bands", October 2005. 539 [FRD] Choi, JH., Shin, DongYun., and W. Haddad, "Fast Router 540 Discovery with L2 support", August 2006, . 543 [PSDOC] Jee, J., "IP over 802.16 Problem Statement and Goals", 544 October 2006, . 547 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 548 Networks", RFC 2464, December 1998, 549 . 551 [RFC3041] Narten, T., Draves, R., and S. Krishnan, "Privacy 552 Extensions for Stateless Address Autoconfiguration in 553 IPv6", August 2006, . 556 [RFC3315] Droms, Ed., R., Bound, J., Volz, B., Lemon, T., Perkins, 557 C., and M. Carney, "Dynamic Host Configuration Protocol 558 for IPv6 (DHCPv6)", RFC 3315, July 2003, 559 . 561 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 562 Discovery (ND) Trust Models and Threats", RFC 3756, 563 May 2004, . 565 [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network 566 Attachment in IPv6", RFC 4135, August 2005, 567 . 569 [RFC4294] Loughney, Ed., J., "IPv6 Node requirements", RFC 4294, 570 April 2006, . 572 [WMF] "http://www.wimaxforum.org". 574 [WiMAXArch] 575 "WiMAX End-to-End Network Systems Architecture 576 http://www.wimaxforum.org/technology/documents", 577 August 2006. 579 Appendix A. WiMAX network architecture and IPv6 support 581 The WiMAX network architecture consists of the Access Service Network 582 (ASN) and the Connectivity Service Network (CSN). The ASN is the 583 access network which includes the BS and the AR in addition to other 584 functions such as AAA, Mobile IP Foreign agent, Paging controller, 585 Location Register etc. The CSN is the entity that provides 586 connectivity to the Internet and includes functions such as Mobile IP 587 Home agent and AAA. The figure below shows the WiMAX reference 588 model: 590 ------------------- 591 | ---- ASN | |----| 592 ---- | |BS|\ R6 -------| |---------| | CSN| 593 |MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | | 594 ---- | |R8 /--|------|----| |-----|Home| 595 | ---- / | | visited| | NSP| 596 | |BS|/ | | NSP | | | 597 | ---- | |---------| | | 598 | NAP | \ |----| 599 ------------------- \---| / 600 | | / 601 | (--|------/----) 602 |R4 ( ) 603 | ( ASP network ) 604 --------- ( or Internet ) 605 | ASN | ( ) 606 --------- (----------) 608 Figure 6: WiMAX Network reference model 610 Three different types of ASN realizations called profiles are defined 611 by the architecture. ASNs of profile types A and C include BS' and 612 ASN-gateway(s) (ASN-GW) which are connected to each other via an R6 613 interface. An ASN of profile type B is one in which the 614 functionality of the BS and other ASN functions are merged together. 615 No ASN-GW is specifically defined in a profile B ASN. The absence of 616 the R6 interface is also a profile B specific characteristic. The MS 617 at the IPv6 layer is associated with the AR in the ASN. The AR may 618 be a function of the ASN-GW in the case of profiles A and C and is a 619 function in the ASN in the case of profile B. When the BS and the AR 620 are separate entities and linked via the R6 interface, IPv6 packets 621 between the BS and the AR are carried over a GRE tunnel. The 622 granularity of the GRE tunnel should be on a per MS basis or on a per 623 service flow basis (an MS can have multiple service flows, each of 624 which are identified uniquely by a service flow ID). The protocol 625 stack in WiMAX for IPv6 is shown below: 627 |-------| 628 | App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 629 | | 630 |-------| /------ ------- 631 | | / IPv6 | | | 632 | IPv6 |- - - - - - - - - - - - - - - - / | | |--> 633 | | --------------- -------/ | | IPv6| 634 |-------| | \Relay/ | | | |- - - | | 635 | | | \ / | | GRE | | | | 636 | | | \ /GRE | - | | | | | 637 | |- - - | |-----| |------| | | | 638 | IPv6CS| |IPv6CS | IP | - | IP | | | | 639 | ..... | |...... |-----| |------|--------| |-----| 640 | MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 | 641 |-------| |------ |-----| |----- |--------| |-----| 642 | PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 | 643 -------- --------------- ----------------- ------- 645 MS BS AR/ASN-GW CSN Rtr 647 Figure 7: WiMAX protocol stack 649 As can be seen from the protocol stack description, the IPv6 end- 650 points are constituted in the MS and the AR. The BS provides lower 651 layer connectivity for the IPv6 link. 653 Appendix B. IPv6 link in WiMAX 655 WiMAX is an example of a network based on the IEEE Std 802.16 air 656 interface. This section describes the IPv6 link in the context of a 657 WiMAX network. The MS and the AR are connected via a combination of 658 : 660 1. The transport connection which is identified by a Connection 661 Identifier (CID) over the air interface, i.e the MS and BS and, 662 2. A GRE tunnel between the BS and AR which transports the IPv6 663 packets 665 From an IPv6 perspective the MS and the AR are connected by a point- 666 to-point link. The combination of transport connection over the air 667 interface and the GRE tunnel between the BS and AR creates a (point- 668 to-point) tunnel at the layer below IPv6. 670 The collection of service flows (tunnels) to an MS is defined as a 671 single link. Each link has only an MS and an AR. Each MS belongs to 672 a different link. No two MSs belong to the same link. A different 673 prefix should be assigned to each unique link. This link is fully 674 consistent with a standard IP link, without exception and conforms 675 with the definition of a point-to-point link in RFC2461 [RFC2461]. 677 Appendix C. IPv6 link establishment in WiMAX 679 The mobile station performs initial network entry as specified in 680 802.16. On succesful completion of the network entry procedure the 681 ASN gateway/AR triggers the establishment of the initial service flow 682 (ISF) for IPv6 towards the MS. The ISF is a GRE tunnel between the 683 ASN-GW/AR and the BS. The BS in turn requests the MS to establish a 684 transport connection over the air interface. The end result is a 685 transport connection over the air interface for carrying IPv6 packets 686 and a GRE tunnel between the BS and AR for relaying the IPv6 packets. 687 On succesful completion of the establishment of the ISF, IPv6 packets 688 can be sent and received between the MS and AR. The ISF enables the 689 MS to communicate with the AR for host configuration procedures. 690 After the establishment of the ISF, the AR can send a router 691 advertisement to the MS. An MS can establish multiple service flows 692 with different QoS characteristics. The ISF can be considered as the 693 primary service flow. The ASN-GW/ AR treats each ISF, along with the 694 other service flows to the same MS, as a unique link which is managed 695 as a (virtual) interface. 697 Appendix D. Maximum transmission unit in WiMAX 699 The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. 700 Hence the IPv6 path MTU can be 1500 octets. However because of the 701 overhead of the GRE tunnel used to transport IPv6 packets between the 702 BS and AR and the 6 byte MAC header over the air interface, using a 703 value of 1500 would result in fragmentation of packets. It is 704 recommended that the default MTU for IPv6 be set to 1400 octets for 705 the MS in WiMAX networks. Note that the 1522 octet specification is 706 a WiMAX forum specification and not the size of the SDU that can be 707 transmitted over 802.16, which is higher. 709 Appendix E. Stateless address autoconfiguration 711 The MS can perform stateless address autoconfiguration as per 712 RFC2461, 2462 if the A-bit in the prefix information option (PIO) is 713 set. The AR is the default router that advertises a unique /64 714 prefix (or prefixes) that is used by the MS to configure an address. 716 Authors' Addresses 718 Basavaraj Patil 719 Nokia 720 6000 Connection Drive 721 Irving, TX 75039 722 USA 724 Email: basavaraj.patil@nokia.com 726 Frank Xia 727 Huawei USA 728 1700 Alma Dr. Suite 100 729 Plano, TX 75075 731 Email: xiayangsong@huawei.com 733 Behcet Sarikaya 734 Huawei USA 735 1700 Alma Dr. Suite 100 736 Plano, TX 75075 738 Email: sarikaya@ieee.org 740 JinHyeock Choi 741 Samsung AIT 742 Networking Technology Lab 743 P.O.Box 111 744 Suwon, Korea 440-600 746 Email: jinchoe@samsung.com 748 Syam Madanapalli 749 LogicaCMG 750 125 Yemlur P.O. 751 Off Airport Road 752 Bangalore, India 560037 754 Email: smadanapalli@gmail.com 756 Full Copyright Statement 758 Copyright (C) The IETF Trust (2006). 760 This document is subject to the rights, licenses and restrictions 761 contained in BCP 78, and except as set forth therein, the authors 762 retain all their rights. 764 This document and the information contained herein are provided on an 765 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 766 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 767 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 768 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 769 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 770 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 772 Intellectual Property 774 The IETF takes no position regarding the validity or scope of any 775 Intellectual Property Rights or other rights that might be claimed to 776 pertain to the implementation or use of the technology described in 777 this document or the extent to which any license under such rights 778 might or might not be available; nor does it represent that it has 779 made any independent effort to identify any such rights. Information 780 on the procedures with respect to rights in RFC documents can be 781 found in BCP 78 and BCP 79. 783 Copies of IPR disclosures made to the IETF Secretariat and any 784 assurances of licenses to be made available, or the result of an 785 attempt made to obtain a general license or permission for the use of 786 such proprietary rights by implementers or users of this 787 specification can be obtained from the IETF on-line IPR repository at 788 http://www.ietf.org/ipr. 790 The IETF invites any interested party to bring to its attention any 791 copyrights, patents or patent applications, or other proprietary 792 rights that may cover technology that may be required to implement 793 this standard. Please address the information to the IETF at 794 ietf-ipr@ietf.org. 796 Acknowledgment 798 Funding for the RFC Editor function is provided by the IETF 799 Administrative Support Activity (IASA).