idnits 2.17.1 draft-shin-16ng-ipv6-transmission-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 624. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (February 23, 2006) is 6630 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) == Missing Reference: 'RFC 2119' is mentioned on line 96, but not defined == Unused Reference: 'RFC2119' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC2462' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'I-D.mandin-ip-over-80216-ethcs' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'IEEE802.16e' is defined on line 575, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 1972 (Obsoleted by RFC 2464) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M-K. Shin 3 Internet-Draft ETRI 4 Expires: August 27, 2006 H-J. Jang 5 Samsung AIT 6 February 23, 2006 8 Transmission of IPv6 Packets over IEEE 802.16 9 draft-shin-16ng-ipv6-transmission-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 27, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies the frame format for transmission of IPv6 43 packets and the method of forming IPv6 link-local addresses and 44 statelessly autoconfigured addresses on IEEE 802.16 networks. It 45 also specifies how to send IPv6 unicast and multicast packets over 46 IEEE 802.16 networks. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5 53 4. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 5. Stateless Autoconfiguration and Link-Local Addresses . . . . . 8 55 6. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 9 56 7. Packet Transmission . . . . . . . . . . . . . . . . . . . . . 10 57 7.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 10 58 7.1.1. Unicast Transmission . . . . . . . . . . . . . . . . . 11 59 7.1.2. Multicast Transmission . . . . . . . . . . . . . . . . 11 60 7.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 11 61 7.2.1. Unicast Transmission . . . . . . . . . . . . . . . . . 12 62 7.2.2. Multicast Transmission . . . . . . . . . . . . . . . . 12 63 7.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 12 64 7.3.1. Unicast Transmission . . . . . . . . . . . . . . . . . 13 65 7.3.2. Multicast Transmission . . . . . . . . . . . . . . . . 13 66 7.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 13 67 7.4.1. Unicast Transmission . . . . . . . . . . . . . . . . . 14 68 7.4.2. Multicast Transmission . . . . . . . . . . . . . . . . 14 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 75 Intellectual Property and Copyright Statements . . . . . . . . . . 20 77 1. Introduction 79 Recently, broadband wireless access network is emerging for wireless 80 communication for user requirements such as high quality data/voice 81 service, fast mobility, wide coverage, etc. The IEEE 802.16 Working 82 Group on broadband wireless access standards develops standards and 83 recommended practices to support the development and deployment of 84 broadband wireless metropolitan area networks. 86 As the deployment of wireless broadband access network progresses, 87 users will be connected to IPv6 networks. This document specifies 88 the frame format for transmission of IPv6 packets and the method of 89 forming IPv6 link-local addresses and statelessly autoconfigured 90 addresses on IEEE 802.16 networks. It also specifies how to send 91 IPv6 unicast and multicast packets over IEEE 802.16 networks. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC 2119]. 97 2. Terminology 99 SS: Subscriber Station. A general equipment set providing 100 connectivity between subscriber equipment and a BS. 102 MS: Mobile Station. A station in the mobile service intended to be 103 used while in motion or during halts at unspecified points. A mobile 104 station (MS) is always a subscriber station (SS). 106 BS: Base Station. A generalized equipment set providing 107 connectivity, management and control of MS connections. A 108 unidirectional mapping between BS and MS medium access control (MAC) 109 peers for the purpose of transporting a service flow's traffic. 110 Connections are identified by a connection identifier (CID). All 111 traffic is carried on a connection. 113 PHS : Payload Header Suppression. 115 PDU : Protocol Data Unit. This refers to the data format passed from 116 the lower edge of the 802.16 MAC to the 802.16 PHY, which typically 117 contains SDU data after fragmentation, encryption, etc. 119 SDU : Service Data Unit. This refers to the data format passed to 120 the upper edge of the 802.16 MAC 122 3. Maximum Transmission Unit 124 IEEE 802.16 permits fragmentation and reassembly. This capabilities 125 are compleletely different from IP fragmentation and reassembly 126 process. 128 Fragmentation is the process by which a MAC SDU is divided into one 129 or more MAC PDU. This process is undertaken to allow efficient use 130 of availabe bandwidth relative to the QoS requirements of 131 connection's service flow. 133 The default MTU size for IPv6 packets over IEEE 802.16 is not defined 134 in [IEEE802.16]. Fragmentation frame size can be variable according 135 to the bandwidth relative to the QoS requirements of connection's 136 service flow. Also, it may be dependent on type of Convergence 137 Sublayers (CS). For example, the default MTU size for IPv6 packets 138 on an Ethernet CS would be 1500 octets. Mannual configuration of 139 each node may be required, if necessary. 141 4. Frame Format 143 IEEE 802.16 [IEEE802.16] defines the MAC and PHY layers for OFDM and 144 OFDMA-based broadband wireless access. 146 IEEE 802.16 PDU (Protocol Data Unit) which is the data format passed 147 from the lower edge of the 802.16 MAC to the 802.16 PHY, which 148 typically contains SDU data after fragmentation, encryption, etc. 149 consists of a 6-byte MAC header, various optional subheaders, and a 150 data payload. 152 The 802.16 6-byte MAC header carries the Connection Identifer (CID) 153 of the connection with which the PDU is associated. 155 It is importmant to see that there is no source or destination MAC 156 address in IEEE 802.16 the MAC header format. Similar to general 157 point-to-point links, the MAC address is not used for link-layer 158 transmission. Hence, mapping unicast or multicast addresses to IEEE 159 802.16 MAC addresses is unnecessary. Also, link-local addressess may 160 be not needed for transmission of link-local destination packets. 161 Instead, CID is used to identify connections to equivalent peers in 162 the MAC of the BS and the MS in IEEE 802.16 networks. 164 IEEE 820.16 SDU (Service Data Unit) which is the data format passed 165 to the upper edge of the 802.16 MAC. 167 IEEE 802.16 Convergence Sublayer (CS) provides the tunneling of 168 IP(v6) packets over IEEE 802.16 air-link. The tunnels are identified 169 by the Connection Identifier (CID). Generally, CS performs the 170 following functions in terms of IP packet transmission: 1) Receipt of 171 protocol data units (PDUs) from the higher layer, 2) Performing 172 classification and CID mapping of the PDUs, 3) Delivering the PDUs to 173 the appropriate MAC SAP, 4) Receipt of PDUs from the peer MAC SAP. 175 [IEEE802.16] defines several CSs for carrying IP packets. The 176 several CSs are classified into two types of CS: IP CS and Ethernet 177 CS. Frame formats are different accordding to the CS types. 179 IPv6 packets can be transmitted in 802.16 frames. In case of IP CS 180 type, the data field contains the IPv6 header and payload, as shown 181 in Fig 1. With Ethernet CS, Ethernet header MUST be included in 182 802.16 frame's data field, as shown in Fig 2. 184 0 1 185 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |H|E| Type |R|C|EKS|R|LEN | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | LEN LSB | CID MSB | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | CID LSB | HCS | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | IPv6 | 194 +- -+ 195 | header | 196 +- -+ 197 | and | 198 +- -+ 199 / payload ... / 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Fig. 1 204 0 1 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |H|E| Type |R|C|EKS|R|LEN | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | LEN LSB | CID MSB | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | CID LSB | HCS | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Ethernet | 214 +- -+ 215 / header / 216 / / 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | IPv6 | 219 +- -+ 220 | header | 221 +- -+ 222 | and | 223 +- -+ 224 / payload ... / 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Fig. 2 229 5. Stateless Autoconfiguration and Link-Local Addresses 231 Like other IEEE 802 interfaces, the Interface Identifier for an IEEE 232 802.16 interface is based on the EUI-64 identifier derived from the 233 interface's built-in 48-bit IEEE 802 address. 235 The Interface Identifier is then formed from the EUI-64 by 236 complementing the "Universal/Local" (U/L) bit, which is the next-to- 237 lowest order bit of the first octet of the EUI-64. 239 For example, the Interface Identifier for an IEEE 802.16 interface 240 whose built-in address is, in hexadecimal, "34-56-78-9A-BC-DE" would 241 be "36-56-78-FF-FE-9A-BC-DE". 243 A different MAC address set manually or by software should not be 244 used to derive the Interface Identifier. If such a MAC address must 245 be used, its global uniqueness property should be reflected in the 246 value of the U/L bit. 248 An IPv6 address prefix used for stateless autoconfiguration of an 249 IEEE 820.16 interface must have a length of 64 bits. 251 The IPv6 link-local address for an IEEE 802.16 interface is formed by 252 appending the Interface Identifier, as defined above, to the prefix 253 FE80::/64. 255 10 bits 54 bits 64 bits 256 +----------+-----------------------+----------------------------+ 257 |1111111010| (zeros) | Interface Identifier | 258 +----------+-----------------------+----------------------------+ 260 Fig. 3 262 6. Address Mapping 264 In general, the procedure for mapping IPv6 unicast addresses into 265 IEEE 802.16 link-layer addresses is directly not applied as described 266 in [RFC1972], since IEEE 802.16 MAC header does not contain any 267 source or destination 802 MAC addresses. 269 In case of IP CS type, mapping unicast or multicast addresses to IEEE 270 802.16 MAC addresses is unnecessary. 272 Instead, in order to identify connections to equivalent peers in the 273 MAC of the BS/router and the MS, CID is used. In certain cases, 274 multicast CID may be provided for in the downlink. It can be useful 275 to tranmit efficiently link-local multicast destination packets (e.g, 276 Router Advertisements) from BS/router to MSs. 278 So, CID or multicast CID may be mapped to IPv6 unicast or multicast 279 addresses with TCP/UDP ports. This mapping is dependent on how to 280 implement it. 282 However, in case of Ethernet CS type, source and Ethernet addresses 283 are required to form the frame for Ethernet CS. In such case, 284 address mapping is the same as [RFC1972]. 286 7. Packet Transmission 288 IEEE 802.16 is different from existing wireless access technologies 289 such as IEEE 802.11, and, while 802.16 defines the encapsulation of 290 an IP datagram in an IEEE 802.16 MAC payload, complete description of 291 IPv6 operation is not present and can benefit from IETF input and 292 specification. 294 Classification is the process by which a MAC SDU is mapped onto a 295 particular connection for transmission between MAC peers. This 296 mapping process associates a MAC SDU with a connection based on some 297 criteria such as protocol-specific packet information, which is 298 called as classification parameters according to [Section 5.2 802.16- 299 2004]. For IP CS, the packet may be classified by IP source/ 300 destination addresses, etc. For Ethernet CS (IP over Ethernet CS), 301 the packet may be classified by Ethernet source/destination addresses 302 and IP source/destination addresses, source/destination port numbers, 303 etc. This is dependent on how to implement it. 305 Base Station (BS) generates the flow based on the classification (IP 306 CS or Ethernet CS). It also decides where to send the packet, since 307 IEEE 802.16 connection always ends at BS while IPv6 connection 308 terminates at a default router. This operation and limitation may be 309 dependent on subnet model. 311 While deploying IPv6 in the approach described in earlier sections, 312 there are four possible typical scenarios as discussed below 313 [I-D.shin-v6ops-802.16-deployment-scenarios]. 315 7.1. Scenario A 317 Scenario A represents IEEE 802.16 access network deployment where a 318 BS is integrated with a router, composing one box in view of 319 implementation. In this scenario, a subnet consists of only single 320 BS/router and single MS. 322 +-----+ 323 | MS1 |<-------------+ 324 +-----+ v 325 +-----+ +-------+ +--------+ 326 | MS2 |<---------->|BS/AR1 |---------| Edge | ISP 327 +-----+ +-------+ | Router +==>Network 328 +--------+ 329 +-----+ +-------+ | 330 | Ms3 |<---------->|BS/AR2 |-----------+ 331 +-----+ +-------+ 332 <---> IP termination 333 Fig. 4 Scenario A 335 7.1.1. Unicast Transmission 337 o Outbound unicast packet from MS is always forwarded on a particular 338 transport connection in the uplink direction to the BS/AR. 340 o When BS/AR receives the packet destined to same subnet (as MS) from 341 MS, it does not relay the packet anymore. 343 o Otherwise, BS/AR forwards the packet to the edge router, which 344 forwards the packet accordingly based on its routing table such as 345 IGP. 347 7.1.2. Multicast Transmission 349 Link-local and Non-link-local Multicast packet could be classified 350 based on destination Ethernet address in Ethernet header (Ethernet 351 CS) or IPv6 destination address in IP header. (IP or Ethernet CS) 353 o Outbound multicast packet from the MS is always forwarded on a 354 particular transport connection in the uplink direction to the BS/AR. 356 o When BS/AR receives the multicast packet with link-local scope from 357 MS, it does not forward the packet anymore. 359 o When BS/AR receives the multicast packet with non-link-local scope 360 from MS, it looks up the IPv6 ulticasting routing table and forwards 361 the packets to the edge router according to the result. 363 7.2. Scenario B 365 Scenario B represents IEEE 802.16 access network deployment where a 366 BS is integrated with a router, composing one box in view of 367 implementation, and a subnet consists of only single BS/AR and 368 multiple MSs. 370 +-----+ 371 | MS1 |<------+ 372 +-----+ | 373 +-----+ | +-------+ +--------+ 374 | MS2 |<------+--->|BS/AR1 |---------| Edge | ISP 375 +-----+ +-------+ | Router +==>Network 376 +--------+ 377 +-----+ +-------+ | 378 | Ms3 |<---------->|BS/AR2 |-----------+ 379 +-----+ +-------+ 380 <---> IP termination 381 Fig. 5 Scenario B 383 7.2.1. Unicast Transmission 385 o Outbound unicast packet from the MS is always forwarded on a 386 particular transport connection in the uplink direction to the BS/AR. 388 o When BS/AR receives the packet destined to same subnet from MS but 389 not to itself, it forwards to downlink after uplink CID is replaced 390 with the corresponding downlink CID (which may be associated with the 391 specified Ethernet addresses in Ethernet CS or IP addresses in 392 Ethernet/IP CS). 394 o When BS/AR receives the packet destined to other subnet from MS, it 395 forwards the packet to the edge router, which forwards the packet 396 accordingly based on its routing table such as IGP. 398 7.2.2. Multicast Transmission 400 o Outbound unicast packet from the MS is always forwarded on a 401 particular transport connection in the uplink direction to the BS/AR. 403 o When BS/AR receives the multicast packet with link-local scope from 404 MS, it sends back the packet to the downlink by using CID for 405 multicast. 407 o When BS/AR receives the multicast packet with non-link-local scope 408 from MS, BS/AR looks up the IPv6 multicasting routing table and 409 forwards the packets to the edge router according to the result. 411 7.3. Scenario C 413 Scenario C represents IEEE 802.16 access network deployment where a 414 BS is separated from a router, and a subnet consists of only single 415 BS and single router and multiple MSs. 417 +-----+ 418 | MS1 |<------+ 419 +-----+ | 420 +-----+ | +-----+ +-----+ +--------+ 421 | MSs |<------+----| BS1 |---->| AR |----| Edge | ISP 422 +-----+ +-----+ +-----+ | Router +==>Network 423 ^ +--------+ 424 +-----+ +-----+ | 425 | Mss |<-----------| BS2 |--------+ 426 +-----+ +-----+ 427 <---> IP termination 428 Fig. 6 Scenario C 430 7.3.1. Unicast Transmission 432 o Outbound unicast packet from the MS is always forwarded on a 433 particular transport connection in the uplink direction to the BS. 435 o When BS receives the packet destined to same subnet from MS but not 436 to AR, the uplink CID is replaced with the corresponding downlink CID 437 (which may be associated with the specified Ethernet addresses in 438 Ethernet CS or IP addresses in Ethernet/IP CS), then forwarded to 439 downlink. 441 o Otherwise, BS decapsulates the 802.16 header and forwards the 442 packet to AR. . In case of Ethernet CS, it will be delivered to the 443 AR naturally since the destination address in Ethernet header is the 444 AR's address. In case of IP CS, the BS is responsible to deliver it 445 with the proper Ethernet header. AR performs routing and then 446 forwards it to other BS or edge router according to the routing 447 result. 449 7.3.2. Multicast Transmission 451 o Outbound unicast packets from the MS are always forwarded on a 452 particular transport connection in the uplink direction to the BS. 454 o When BS/AR receives the multicast packet with link-local scope from 455 MS, it sends back the packet to the downlink by using CID for 456 multicast. It also sends the packet to an AR after decapsulating 457 802.16 header. 459 o When BS/AR receives the multicast packet with non-link-local scope 460 from MS, the packet is sent back to the downlink by using CID for 461 multicast. It is also sent to the AR based after decapsulating 462 802.16 header. In case of Ethernet CS, it will be delivered to the 463 AR naturally since the destination address in Ethernet header is the 464 multicast address. In case of IP CS, the BS is responsible to 465 deliver it with the proper Ethernet header. AR looks up the IPv6 466 multicasting routing table and then forwards the packets to other BSs 467 or edge router according to the result. 469 7.4. Scenario D 471 Scenario D represents IEEE 802.16 network deployment where a BS is 472 separated from a router, and a subnet consists of multiple BS and 473 multiple MSs. 475 +-----+ +-----+ +-----+ ISP 1 476 | MS1 |<-----+ +->| AR1 |----| ER1 |===>Network 477 +-----+ | | +-----+ +-----+ 478 +-----+ | +-----+ | 479 | MS2 |<-----+-----| BS1 |--| 480 +-----+ +-----+ | +-----+ +-----+ ISP 2 481 +->| AR2 |----| ER2 |===>Network 482 +-----+ +-----+ | +-----+ +-----+ 483 | Ms3 |<-----------| BS2 |--+ 484 +-----+ +-----+ 485 <---> IP termination 486 Fig. 7 Scenario D 488 7.4.1. Unicast Transmission 490 o Outbound unicast packet from the MS is always forwarded on a 491 particular transport connection in the uplink direction to the BS. 493 o If BS receives the packet destined to same subnet and to MS under 494 the serving BS, the uplink CID is replaced with the corresponding 495 downlink CID (which may be associated with the specified Ethernet 496 addresses in Ethernet CS or IP addresses in Ethernet/IP CS), 498 o Otherwise, BS decapsulates the 802.16 header and forwards the 499 packet onto the wired network. In case of Ethernet CS, if the packet 500 is destined to one of ARs, it will be delivered to the AR naturally 501 since the destination address in Ethernet header is the AR's address. 502 If the packet is destined to MS under other BS, the target BS under 503 which the MS exists should catch this packet instead by acting as a 504 proxy of the MS and send it to MS by using corresponding downlink 505 CID. In case of IP CS, if the packet is destined to one of ARs, the 506 BS is responsible to deliver it with the proper Ethernet header. If 507 the packet is destined to MS under other BS, the target BS should 508 catch this packet instead by acting as a proxy of the MS and send it 509 to MS by using corresponding downlink CID. 511 7.4.2. Multicast Transmission 513 o Outbound unicast packets from the MS are always forwarded on a 514 particular transport connection in the uplink direction to the BS. 516 o When BS receives the multicast packet with link-local scope from 517 MS, it sends back the packet to the downlink by using CID for 518 multicast. It also sends the packet onto the wired network after 519 decapsulating 802.16 header. ARs will get this, and other BSs will 520 receive this and send it by using CID for multicast. 522 o When BS receives the multicast packet with non-link-local scope 523 from MS, it sends back the packet to the downlink by using CID for 524 multicast. It also sends the packet onto the wired network after 525 decapsulating the 802.16 header. Other BSs will receive this and 526 send it by using CID for multicast. The multicast router receiving 527 this will look up the IPv6 multicasting routing table and then 528 forwards the packets to edge router according to the result. 530 8. IANA Considerations 532 This document requests no action by IANA. 534 9. Security Considerations 536 TBD 538 10. References 540 10.1. Normative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 546 Discovery for IP Version 6 (IPv6)", RFC 2461, 547 December 1998. 549 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 550 (IPv6) Specification", RFC 2460, December 1998. 552 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 553 Autoconfiguration", RFC 2462, December 1998. 555 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 556 Packets over Ethernet Networks", RFC 1972, August 1996. 558 10.2. Informative References 560 [I-D.shin-ipv6-ieee802.16] 561 Shin, M., "Scenarios and Considerations of IPv6 in IEEE 562 802.16 Networks", draft-shin-ipv6-ieee802.16-01 (work in 563 progress), October 2005. 565 [I-D.mandin-ip-over-80216-ethcs] 566 Mandin, J., "Transport of IP over 802.16", 567 draft-mandin-ip-over-80216-ethcs-00 (work in progress), 568 October 2005. 570 [IEEE802.16] 571 "IEEE 802.16-2004, IEEE standard for Local and 572 metropolitan area networks, Part 16:Air Interface for 573 fixed broadband wireless access systems", October 2004. 575 [IEEE802.16e] 576 "IEEE 802.16e/D10 Draft, IEEE Standard for Local and 577 metropolitan area networks, Part 16: Air Interface for 578 Fixed and Mobile Broadband Wireless Access Systems 579 Amendment for Physical and Medium Access Control Layers 580 for Combined Fixed and Mobile Operation in Licensed 581 Bands", August 2005. 583 Authors' Addresses 585 Myung-Ki Shin 586 ETRI 587 161 Gajeong-dong Yuseng-gu 588 Daejeon, 305-350 589 Korea 591 Phone: +82 42 860 4847 592 Email: myungki.shin@gmail.com 594 Hee-Jin Jang 595 Samsung AIT 596 P.O. Box 111 597 Suwon 440-600 598 Korea 600 Email: heejin.jang@samsung.com 602 Intellectual Property Statement 604 The IETF takes no position regarding the validity or scope of any 605 Intellectual Property Rights or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; nor does it represent that it has 609 made any independent effort to identify any such rights. Information 610 on the procedures with respect to rights in RFC documents can be 611 found in BCP 78 and BCP 79. 613 Copies of IPR disclosures made to the IETF Secretariat and any 614 assurances of licenses to be made available, or the result of an 615 attempt made to obtain a general license or permission for the use of 616 such proprietary rights by implementers or users of this 617 specification can be obtained from the IETF on-line IPR repository at 618 http://www.ietf.org/ipr. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights that may cover technology that may be required to implement 623 this standard. Please address the information to the IETF at 624 ietf-ipr@ietf.org. 626 Disclaimer of Validity 628 This document and the information contained herein are provided on an 629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 631 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 632 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 633 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 Copyright Statement 638 Copyright (C) The Internet Society (2006). This document is subject 639 to the rights, licenses and restrictions contained in BCP 78, and 640 except as set forth therein, the authors retain all their rights. 642 Acknowledgment 644 Funding for the RFC Editor function is currently provided by the 645 Internet Society.