idnits 2.17.1 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 838. 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 date (November 18, 2008) is 5637 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Jeon 3 Internet-Draft ETRI 4 Intended status: Standards Track M. Riegel 5 Expires: May 22, 2009 NSN 6 S. Jeong 7 ETRI 8 November 18, 2008 10 Transmission of IP over Ethernet over IEEE 802.16 Networks 11 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-07.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 22, 2009. 38 Abstract 40 This document describes the transmission of IPv4 over Ethernet as 41 well as IPv6 over Ethernet in an access network deploying the IEEE 42 802.16 cellular radio transmission technology. The Ethernet on top 43 of IEEE 802.16 is realized by bridging connections which the IEEE 44 802.16 provides between a base station and its associated subscriber 45 stations. Due to the resource constraints of radio transmission 46 systems and the limitations of the IEEE 802.16 MAC functionality for 47 the realization of an Ethernet, the transmission of IP over Ethernet 48 over IEEE 802.16 may considerably benefit by adding IP specific 49 support functions in the Ethernet over IEEE 802.16 while maintaining 50 full compatibility with standard IP over Ethernet behavior. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . . 3 58 4.1. Connection Oriented Air Interface . . . . . . . . . . . . 3 59 4.2. MAC addressing in IEEE 802.16 . . . . . . . . . . . . . . 4 60 4.3. Unidirectional Broadcast and Multicast Support . . . . . . 5 61 4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet . . 5 62 5. Ethernet Network Model for IEEE 802.16 . . . . . . . . . . . . 5 63 5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 6 64 5.2. Ethernet without Native Broadcast and Multicast Support . 7 65 5.3. Network-side Bridging Function . . . . . . . . . . . . . . 7 66 5.4. Segmenting the Ethernet into VLAN . . . . . . . . . . . . 8 67 6. Transmission of IP over Ethernet over IEEE 802.16 Link . . . . 8 68 6.1. Generic IP over Ethernet Network Scenario . . . . . . . . 8 69 6.2. Transmission of IP over Ethernet . . . . . . . . . . . . . 9 70 6.2.1. IPv4 over Ethernet Packet Transmission . . . . . . . . 9 71 6.2.2. IPv6 over Ethernet Packet Transmission . . . . . . . . 9 72 6.2.3. Maximum Transmission Unit . . . . . . . . . . . . . . 10 73 6.2.4. Prefix Assignment . . . . . . . . . . . . . . . . . . 10 74 7. Operational Enhancements for IP over Ethernet over IEEE 75 802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. IP Multicast and Broadcast Packet Processing . . . . . . . 11 77 7.1.1. Multicast Transmission Considerations . . . . . . . . 11 78 7.1.2. Broadcast Transmission Considerations . . . . . . . . 11 79 7.2. DHCPv4 Considerations . . . . . . . . . . . . . . . . . . 12 80 7.3. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8. Public Access Recommendations . . . . . . . . . . . . . . . . 12 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 87 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 88 Appendix A. Multicast CID Deployment Considerations . . . . . . . 16 89 Appendix B. Centralized vs. Distributed Bridging . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 91 Intellectual Property and Copyright Statements . . . . . . . . . . 20 93 1. Introduction 95 IEEE 802.16 [802.16] specifies a fixed to mobile broadband wireless 96 access system. 98 The IEEE 802.16 standard defines a packet CS (Convergence Sublayer) 99 for interfacing with specific packet-based protocols as well as a 100 generic packet CS (GPCS) to provide an upper-layer protocol 101 independent interface. This document describes transmission of IPv4 102 and IPv6 over Ethernet via the Ethernet specific part of the packet 103 CS as well as the GPCS in the IEEE 802.16 based access network. 105 Ethernet is a widely deployed transmission technology. It provides 106 unicast transport, handles broadcast and multicast traffic 107 efficiently, and provides rich services such as Virtual LANs. 108 However, Ethernet has been originally architected and designed for a 109 shared medium while the IEEE 802.16 uses a point-to-multipoint 110 architecture like other cellular radio transmission systems. Hence, 111 Ethernet on top of IEEE 802.16 is realized by bridging between IEEE 112 802.16 radio connections between a BS (Base Station) and its 113 associated SSs (Subscriber Stations). 115 Under the resource constraints of radio transmission systems and the 116 particularities of the IEEE 802.16 for the realization of Ethernet, 117 it makes sense to add IP specific support functions in the Ethernet 118 layer above IEEE 802.16 while maintaining full compatibility with 119 standard IP over Ethernet behavior. 121 2. Requirements 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Terminology 129 The terminology in this document is based on the definitions in IP 130 over 802.16 Problem Statement and Goals [RFC5154]. 132 4. The IEEE 802.16 Link Model 134 4.1. Connection Oriented Air Interface 136 The IEEE 802.16 MAC establishes connections between a BS and its 137 associated SSs for the transfer of user data over the air. Each of 138 these connections realizes an individual Service Flow which is 139 identified by a 16-bit CID number and has a defined QoS profile. 141 Multiple connections can be established between a BS and a SS, each 142 with its particular QoS class and direction. Although the BS and all 143 the SSs are associated with unique 48-bit MAC addresses, packets 144 going over the air are only identified in the IEEE 802.16 MAC header 145 by the CID number of the particular connection. The connections are 146 established by MAC management messages between the BS and the SS 147 during network entry or also later on demand. 149 [Subscriber Side] [Network Side] 151 | | | + 152 | | | + 153 +--+--+ +--+--+ +--+-+-+--+ 154 | MAC | | MAC | | MAC | 155 +-----+ +-----+ +---------+ 156 | PHY | | PHY | | PHY | 157 +-+-+-+ +-+-+-+ +-+-+-+-+-+ 158 + + | | | | + + 159 + + | +-----CID#w------+ | + + 160 + + +-------CID#x--------+ + + 161 + +++++++++++++++++CID#y+++++++++++++++++ + 162 +++++++++++++++++++CID#z+++++++++++++++++++ 163 SS#1 SS#2 BS 165 Figure 1. Basic IEEE 802.16 Link Model 167 4.2. MAC addressing in IEEE 802.16 169 Each SS has a unique 48-bit MAC address and the 48-bit MAC address is 170 used during the initial ranging process for the identification of the 171 SS and may be verified by the succeeding PKM (Privacy Key Management) 172 authentication phase. Out of the successful authentication, the BS 173 establishes and maintains the list of attached SSs based on their MAC 174 addresses purely for MAC management purposes. 176 While MAC addresses are assigned to all the BSs as well as the SSs, 177 the forwarding of packets over the air is only based on the CID value 178 of the particular connection in the IEEE 802.16 MAC header. Not 179 relying on the MAC addresses in the payload for reception of a radio 180 frame allows for the transport of arbitrary source and destination 181 MAC addresses in Ethernet frames between a SS and its BS. This is 182 required for bridging Ethernet frames toward a SS which is attached 183 to a bridge connected to another network. 185 Due to the managed assignment of the service flows and associated CID 186 values to individual SSs, the BS is able to bundle all unicast 187 connections belonging to a particular SS into a single link on the 188 network side as shown in Figure 1 so that it provides a single layer 189 2 link between the SS and its associated wired link on the network 190 side. 192 4.3. Unidirectional Broadcast and Multicast Support 194 Current IEEE 802.16 [802.16] does not support bi-directional native 195 broadcast and multicast for IP packets. While downlink connections 196 can be used for multicast transmission to a group of SSs as well as 197 unicast transmission from the BS to a single SS, uplink connections 198 from the SSs to the BS provide only unicast transmission 199 capabilities. Furthermore, the use of multicast CIDs for realizing 200 downlink multicast transmissions is not necessarily preferable due to 201 the reduced transmission efficiency of multicast CIDs for small 202 multicast groups. Appendix A provides more background information 203 about the issues arising with multicast CIDs in IEEE 802.16 systems. 205 MBS (Multicast and Broadcast Service as specified in IEEE 802.16 also 206 does not cover IP broadcast or multicast data because MBS is 207 invisible to the IP layer. 209 4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet 211 IEEE 802.16 provides two solutions to transfer Ethernet frames over 212 IEEE 802.16 MAC connections. 214 The packet CS is defined for handling packet-based protocols by 215 classifying higher-layer packets depending on the values in the 216 packet header fields and assigning the packets to the related service 217 flow. The packet CS comprises multiple protocol specific parts to 218 enable the transmission of different kind of packets over IEEE 219 802.16. The Ethernet specific part of the packet CS supports the 220 transmission of Ethernet by defining classification rules based on 221 Ethernet header information. 223 The GPCS (Generic Packet Convergence Sublayer) may be used as 224 alternative to transfer Ethernet frames over IEEE 802.16. The GPCS 225 does not define classification rules for each kind of payload but 226 relies on higher layer functionality outside of the scope of IEEE 227 802.16 to provide the assignment of packets to particular service 228 flows. 230 5. Ethernet Network Model for IEEE 802.16 232 According to [RFC4861], a link is defined as a communication facility 233 or medium over which IP devices can communicate at the link layer, 234 i.e. the layer immediately below IP. Ethernet fully satisfies the 235 definition of the link. IEEE 802.16, however, has limitations on its 236 transitive connectivity, i.e. IEEE 802.16 provides point-to-point 237 connections between SSs and the BS but does not enable any direct SS 238 to SS connectivity. Hence, it is required to bridge each of the 239 point-to-point connections between SSs and the BS so that Ethernet is 240 realized over IEEE 802.16 access network. 242 5.1. IEEE 802.16 Ethernet Link Model 244 To realize Ethernet on top of IEEE 802.16 all the point-to-point 245 connections belonging to a SS MUST be connected to a network-side 246 bridging function, as shown in Figure 2. This is equivalent to 247 today's switched Ethernet with twisted pair wires or fibres 248 connecting the hosts to a bridge ("Switch"). 250 The network-side bridging function can be realized either by a single 251 centralized network-side bridge or by multiple interconnected 252 bridges, preferable arranged in a hierarchical order. The single 253 centralized network-side bridge allows best control of the 254 broadcasting and forwarding behavior of the Ethernet over IEEE 255 802.16. Appendix B explains the issues of a distributed bridging 256 architecture, when no assumptions about the location of the access 257 router can be made. 259 The BS MUST forward all the Service Flows belonging to one SS to one 260 port of the network-side bridging function. No more than one SS MUST 261 be connected to one port of the network-side bridging function. The 262 separation method for multiple links on the connection between the BS 263 and the network-side bridging function is out of scope for this 264 document. Either Layer 2 transport or Layer 3 tunneling may be used. 266 If the Ethernet over IEEE 802.16 is extended to multiple end stations 267 behind the SS (i.e. SS#4 in the below figure) then the SS SHOULD 268 support bridging according to [802.1D] and its amendment [802.16k], 269 a.k.a. subscriber-side bridge, between all its subscriber side ports 270 and the IEEE 802.16 air link. 272 ------------------------ IP Link -------------------------- 274 [Subscriber Side] [Network Side] [Subscriber Side] 275 | | | | | | 276 ETH ETH ETH ETH ETH ETH 277 | | | | | | 278 | | +---------+---------+ | +-+---+-+ 279 | | | Bridging Function | | |Bridge | 280 | | +--+-+---------+-+--+ | +---+---+ 281 | | | + + | | | 282 +--+--+ +--+--+ +--+-+--+ +--+-+--+ +--+--+ +--+--+ 283 | MAC | | MAC | | MAC | | MAC | | MAC | | MAC | 284 +-----+ +-----+ +-------+ +-------+ +-----+ +-----+ 285 | PHY | | PHY | | PHY | | PHY | | PHY | | PHY | 286 +-+-+-+ +-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+ +-+-+-+ 287 + | | | | + + | | | | + 288 + | +--CID#u-+ | + + | +-CID#x--+ | + 289 + +----CID#v---+ + + +---CID#y----+ + 290 +++++++++++++++CID#w++++++ ++++++CID#z+++++++++++++++ 292 SS#1 SS#2 BS#1 BS#2 SS#3 SS#4 294 Figure 2. IEEE 802.16 Ethernet Link Model 296 5.2. Ethernet without Native Broadcast and Multicast Support 298 Current IEEE 802.16 does not define broadcast and multicast of 299 Ethernet frames. Hence Ethernet broadcast and multicast frames 300 SHOULD be replicated and then carried via unicast transport 301 connections on IEEE 802.16 access link. The network-side bridging 302 function performs the replication and forwarding for Ethernet 303 broadcast and multicast over the IEEE 802.16 radio links 305 5.3. Network-side Bridging Function 307 The network-side bridging function SHOULD create a new radio side 308 port whenever a new SS attaches to any of the BSs of the network or 309 SHOULD remove a radio side port when an associated SS detaches from 310 the BSs. The method for managing the port on the network-side 311 bridging function may depend on the protocol used for establishing 312 multiple links on the connection between the BS and the network-side 313 bridge. The port managing method is out of scope for this document. 315 The network-side bridging function SHALL be based on [802.1D] and its 316 amendment [802.16k] to interconnect the attached SSs and pass 317 Ethernet frames between the point-to-point connections associated 318 with the attached SSs. However, to enhance the IEEE 802.16 Ethernet 319 link model by avoiding broadcast or multicast packet flooding, 320 additional IP specific functionalities MAY be provided by the 321 network-side bridging function in addition to the mandatory functions 322 according to Section 5.1 of [802.1D]. 324 5.4. Segmenting the Ethernet into VLAN 326 It is possible to restrict the size and coverage of the broadcast 327 domain by segmenting the Ethernet over IEEE 802.16 into VLANs and 328 grouping subsets of hosts into particular VLANs with each VLAN 329 representing an IP link. Therefore, the network-side bridging 330 function MAY be enabled to support VLANs according to [802.1Q] by 331 assigning and handling the VLAN-IDs on the virtual bridge ports. 333 If a SS is directly connected to a subscriber-side bridge supporting 334 VLANs, the port associated with such a SS MAY be enabled as trunk 335 port. On trunk ports, Ethernet frames are forwarded in the [802.1Q] 336 frame format. 338 6. Transmission of IP over Ethernet over IEEE 802.16 Link 340 6.1. Generic IP over Ethernet Network Scenario 342 The generic IP over Ethernet network scenario assumes that all hosts 343 are residing on the same link with trust relationship between all of 344 them. It enables the hosts to directly communicate with each other 345 without detouring. There can be multiple ARs on the link, which may 346 reside both on the subscriber side as well as on the network side as 347 shown in Figure 3. 349 +--+--+ 350 ---|AR|SS| 351 +--+--+* +----+ 352 * +----+ +Host| 353 +----+--+ * | +-------+ /+----+ 354 |Host|SS|* * * * **| BS +------+ \ / +----+ 355 +----+--+ * | +-----+ \ \ / ++Host| 356 +----+--+ * +----+ \ \ +-+--------+ / +----+ 357 |Host|SS|* \ +--+ ++ 358 +----+ +----+--+ +---+Bridging| +----+ 359 --+ AR ++ |Function+---+ AR +--- 360 +----+ \ +--+ | +----+ 361 \ +----+ / +-+--------+ 362 +----+ +------+--+ | +---+ / 363 |Host+-+Bridge|SS|* * * *| BS | / 364 +----+ +------+--+ * | +---+ 365 +----+/ * +----+ 366 |Host+ +----+--+ * 367 +----+ |Host|SS|* 368 +----+--+ 370 Figure 3. Generic IP over Ethernet Network Scenario using IEEE 802.16 372 6.2. Transmission of IP over Ethernet 374 6.2.1. IPv4 over Ethernet Packet Transmission 376 [RFC0894] defines the transmission of IPv4 packets over Ethernet 377 networks. It contains the specification of the encapsulation of the 378 IPv4 packets into Ethernet frames as well as rules for mapping of IP 379 addresses onto Ethernet MAC addresses. Hosts transmitting IPv4 over 380 Ethernet packets over the IEEE 802.16 MUST follow the operations 381 specified in [RFC0894]. 383 6.2.1.1. Address Configuration 385 IPv4 addresses can be configured manually or assigned dynamically 386 from DHCPv4 server [RFC2131]. 388 6.2.1.2. Address Resolution 390 Address Resolution Protocol (ARP) [RFC0826] MUST be used for finding 391 the destination Ethernet MAC address. 393 6.2.2. IPv6 over Ethernet Packet Transmission 395 [RFC2464] defines transmission of IPv6 Packets over Ethernet Networks 396 which includes an encapsulation of IPv6 packets into Ethernet frames 397 and mapping rules for IPv6 address to Ethernet address (i.e. MAC 398 address). Host transmitting IPv6 over Ethernet packets over the IEEE 399 802.16 MUST follow the operations specified in [RFC2464]. 401 6.2.2.1. Router Discovery, Prefix Discovery and Parameter Discovery 403 Router Discovery, Prefix Discovery and Parameter Discovery procedures 404 are achieved by receiving Router Advertisement messages. However, 405 periodic Router Advertisement messages can waste radio resource and 406 disturb SSs in dormant mode in IEEE 802.16. Therefore, the 407 AdvDefaultLifetime and MaxRtrAdvInterval SHOULD be overridden with 408 high values specified in Section 8.3 in [RFC5121]. 410 6.2.2.2. Address Configuration 412 When stateful address autoconfiguration is required, the stateful 413 address configuration according to [RFC3315] MUST be performed. In 414 this case, an AR supports DHCP server or relay function. 416 When stateless address autoconfiguration is required, the stateless 417 address configuration according to [RFC4862] and [RFC4861] MUST be 418 performed. 420 6.2.2.3. Address Resolution 422 Neighbor Discovery Protocol (NDP) [RFC4861] MUST be used for 423 determining the destination Ethernet MAC address. 425 6.2.3. Maximum Transmission Unit 427 [RFC2460] mandates 1280 bytes as a minimum Maximum Transmission Unit 428 (MTU) size for link layer and recommends at least 1500 bytes for IPv6 429 over Ethernet transmission. [RFC0894] also specifies 1500 bytes as a 430 maximum length of IPv4 over Ethernet. Therefore, the default MTU of 431 IPv6 packets and IPv4 packets on Ethernet over IEEE 802.16 link MUST 432 be 1500 bytes. 434 6.2.4. Prefix Assignment 436 The same IPv4 prefix and the same set of IPv6 prefixes SHOULD be 437 assigned to all hosts attached to the Ethernet over IEEE 802.16. 438 Sharing the prefix means locating all hosts on the same subnetwork. 440 7. Operational Enhancements for IP over Ethernet over IEEE 802.16 442 This section presents operational enhancements in order to improve 443 network performance and radio resource efficiency for transmission of 444 IP packets over Ethernet over IEEE 802.16 networks. 446 7.1. IP Multicast and Broadcast Packet Processing 448 All multicast and multicast control messages SHOULD be processed in 449 the network-side bridging function according to [RFC4541]. 450 Broadcasting messages to all radio-side side ports SHOULD be 451 prevented. 453 Further information on prevention of multicasting or broadcasting 454 messages to all radio side ports are given in the following sections. 456 7.1.1. Multicast Transmission Considerations 458 Usually, bridges replicate the IP multicast packets and forward them 459 into all of its available ports with the exception of the incoming 460 port. As a result, the IP multicast packets would be transmitted 461 over the air even to hosts which do not participate in the 462 corresponding multicast group. To allow bridges to handle IP 463 multicast more efficiently, the IP multicast membership should be 464 propagated between bridges. 466 In the IEEE 802.16 Ethernet link model in Section 5.1, the network- 467 side bridging function SHOULD process all multicast data and 468 multicast control messages according to [RFC4541] to maintain IP 469 multicast membership lists and forward IP multicast data to only 470 ports suitable for the multicast group. 472 7.1.2. Broadcast Transmission Considerations 474 The ordinary bridge floods the IP broadcast packets out of all 475 connected ports except the port on which the packet was received. 476 This behavior is not appropriate with scarce resources and dormant- 477 mode hosts in a wireless network such as an IEEE 802.16 based access 478 network. 480 The network-side bridging function in the IEEE 802.16 Ethernet link 481 model SHOULD flood all IP broadcast packets except ARP, DHCPv4 and 482 IGMP related traffic. 484 IGMP related broadcast packets SHOULD be forwarded according to the 485 [RFC4541]. ARP related broadcast SHOULD be processed as specified in 486 Section 7.3. DHCPv4 related broadcast packets SHOULD be handled as 487 specified in Section 7.2. 489 7.2. DHCPv4 Considerations 491 DHCPv4 clients may send DHCP DISCOVER and DHCP REQUEST messages with 492 the BROADCAST bit set to request the DHCP server to broadcast its 493 DHCP OFFER and DHCP ACK messages. The network-side bridging function 494 SHOULD filter these broadcast DHCP OFFER and DHCP ACK messages and 495 forwards the broadcast messages only to the host defined by the 496 client hardware address in the chaddr information element. 498 Alternatively, the DHCP Relay Agent Information Option (option-82) 499 [RFC3046] MAY be used to avoid DHCP broadcast replies. The option-82 500 consists of two type of sub-options; Circuit ID and Remote ID. DHCP 501 Relay Agent is usually located on the network-side bridging function 502 as Layer 2 DHCP Relay Agent, like described in [TR101]. Port number 503 of the network-side bridging function is possible as Circuit ID and 504 Remote ID may be left unspecified. Note that using option-82 505 requires option-82 aware DHCP servers. function SHOULD silently 506 discard any received self-ARP Requests. 508 7.3. Proxy ARP 510 Proxy ARP provides the function in which a device on the same link as 511 the hosts answers ARP Requests instead of the remote host. When 512 transmitting IPv4 packets over the IEEE 802.16 Ethernet link , the 513 Proxy ARP mechanism is used by the network-side bridging function to 514 avoid broadcasting ARP Requests over the air. 516 The network-side bridging function SHOULD maintain an ARP cache large 517 enough to accommodate ARP entries for all its serving SSs. The ARP 518 cache SHOULD be updated by any packets including ARP Requests from 519 SSs in the same way the normal layer-2 bridging device is updating 520 its Filtering Database according to [802.1D]. 522 Upon receiving an ARP Request from a SS, the network-side bridging 523 function SHOULD unicast an ARP Reply back to the SS with the Ethernet 524 address of the target host provided that the target address matches 525 an entry in the ARP Cache. Otherwise, the ARP Request MAY be 526 flooded. The network-side bridging function SHOULD silently discard 527 any received self-ARP Request. 529 8. Public Access Recommendations 531 In the Public Access scenario, direct communication between nodes is 532 restricted because of security and accounting issues. Figure 4 533 depicts the public access scenario. 535 In the scenario, the AR is connected to a network-side bridge. The 536 AR MAY perform security filtering, policing and accounting of all 537 traffic from hosts, e.g. like a NAS (Network Access Server). 539 If the AR functions as the NAS, all the traffic from SSs SHOULD be 540 forwarded to the AR, not bridged at the network-side bridging 541 function, even in the case of traffic between SSs served by the same 542 AR. The bridge SHOULD forward upstream traffic from hosts toward the 543 AR but SHALL perform normal bridging operation for downstream traffic 544 from the AR and SHALL bridge SEcure Neighbor Discovery (SEND) 545 [RFC3971] messages to allow applicability of security schemes. 547 In IPv4 over Ethernet case, MAC-Forced Forwarding (MAC-FF) [RFC4562] 548 SHOULD be used for the public access network to ensure that traffic 549 from all hosts is always directed to the AR. The MAC-FF is performed 550 in the network-side bridging function, thus the bridge filters 551 broadcast ARP Requests from all the hosts and responds to the ARP 552 Requests with an Ethernet MAC address of the AR. 554 In IPv6 over Ethernet case, assigning unique IPv6 prefix per SS can 555 forces all IPv6 packets from SSs to be transferred to the AR. 556 However, this leads the AR to replicate multicast packets on each 557 virtually separated IP links to hosts joined to a corresponding 558 multicast group. It cannot exploit the efficient multicast support 559 of Ethernet link in the network side. Therefore, the AR in the 560 public access link model SHOULD assign common IPv6 prefixes to all 561 SSs served by the AR. A Prefix Information Option (PIO) [RFC4861] 562 carrying the common IPv6 prefixes SHOULD be advertised with On-link 563 flag (L-Flag) reset so that it is not assumed that the addresses 564 matching the prefixes are available on-link. 566 The AR should relay packets between SSs within the same AR. 568 +-+--+ 569 |H|SS| +- - - - - - - - - - + 570 +-+--+* +----+ | +------+ 571 +-+--+ * | +-----+ | | 572 |H|SS|* * * * * *| BS +-----+Bridge+-+ 573 +-+--+ * | +-----+ | | +-----+ | 574 * +----+ | +------+ | | B | 575 +-+--+ * | +-+ r | | +-------+ 576 |H|SS|* | i +---+AR(NAS)+-- 577 +---+ +-+--+ | | d | | +-------+ 578 | H ++ +-+ g | 579 +---+ \ +----+ | +------+ | | e | | 580 +---+ +--+--+ | +----+ | | +-----+ 581 | H +--+Br|SS|* * * * | BS | | |Bridge+-+ | 582 +---+ +--+--+ * | +----+ | 583 +---+ / * +----+ | +------+ | 584 | H ++ +-+--+ * 585 +---+ |H|SS|* | Bridging Function | 586 +-+--+ +- - - - - - - - - - + 588 Figure 4. Public Access Network using IEEE 802.16 590 9. IANA Considerations 592 This document has no actions for IANA. 594 10. Security Considerations 596 This document does not introduce any new vulnerabilities to IPv4 and 597 IPv6 specifications or operations. The security of the IEEE 802.16 598 air interface between SSs and BS is the subject of [802.16] and the 599 security issues of Ethernet bridging are the subjects of [802.1D]. 600 The generic IP over Ethernet network using IEEE 802.16 emulates 601 Ethernet link, since existing IPv4 and IPv6 security mechanisms over 602 Ethernet can be still used. While the public access network ensures 603 secure isolation of each of upstream link between hosts and AR, it 604 still adopts SEcure Neighbor Discovery (SEND) [RFC3971] for securing 605 neighbor discovery processes and it does not introduce any new 606 vulnerabilities over those of Ethernet bridging. 608 11. Acknowledgments 610 The authors would like to thank David Johnston, Dave Thaler, Jari 611 Arkko and others for their inputs to this work. 613 12. References 615 12.1. Normative References 617 [802.16] P802.16Rev2D7, "Draft Standard for Local and metropolitan 618 area networks, Part 16: Air Interface for Fixed Broadband 619 Wireless Access Systems (to be updated according to the 620 released IEEE 802.16-2009 standard)", October 2008. 622 [802.16k] IEEE Std 802.16k-2007, "IEEE Standard for Local and 623 metropolitan area networks, Media Access Control (MAC) 624 Bridges, Amendment 5: Bridging of IEEE 802.16", 625 March 2007. 627 [802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and 628 metropolitan area networks, Media Access Control (MAC) 629 Bridges", June 2004. 631 [802.1Q] IEEE Std 802.1Q-2005, "IEEE Standard for Local and 632 metropolitan area networks, Virtual Bridged Local Area 633 Networks", May 2005. 635 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 636 converting network protocol addresses to 48.bit Ethernet 637 address for transmission on Ethernet hardware", STD 37, 638 RFC 826, November 1982. 640 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 641 over Ethernet networks", STD 41, RFC 894, April 1984. 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 647 RFC 2131, March 1997. 649 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 650 (IPv6) Specification", RFC 2460, December 1998. 652 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 653 Networks", RFC 2464, December 1998. 655 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 656 and M. Carney, "Dynamic Host Configuration Protocol for 657 IPv6 (DHCPv6)", RFC 3315, July 2003. 659 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 660 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 661 September 2007. 663 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 664 Address Autoconfiguration", RFC 4862, September 2007. 666 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 667 Madanapalli, "Transmission of IPv6 via the IPv6 668 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 669 February 2008. 671 12.2. Informative References 673 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 674 RFC 3046, January 2001. 676 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 677 Neighbor Discovery (SEND)", RFC 3971, March 2005. 679 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 680 "Considerations for Internet Group Management Protocol 681 (IGMP) and Multicast Listener Discovery (MLD) Snooping 682 Switches", RFC 4541, May 2006. 684 [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method 685 for Subscriber Separation on an Ethernet Access Network", 686 RFC 4562, June 2006. 688 [RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE 689 802.16 Problem Statement and Goals", RFC 5154, April 2008. 691 [TR101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation", 692 April 2006. 694 Appendix A. Multicast CID Deployment Considerations 696 Multicast CIDs are highly efficient means to distribute the same 697 information concurrently to multiple SSs under the same BS. However, 698 the deployment of multicast CIDs for multicast or broadcast data 699 services suffers from following drawbacks. 701 A drawback of multicast CIDs for Ethernet over IEEE 802.16 is the 702 unidirectional nature of multicast CIDs. While it is possible to 703 multicast information downstream to a number of SSs in parallel, 704 there are no upstream multicast connections. In upstream direction, 705 unicast CIDs have to be used for sending multicast messages over the 706 air to the BS requiring a special multicast forwarding function for 707 sending the information back to the other SSs on a multicast CID. 708 While similar in nature to a bridging function, there is no 709 appropriate forwarding model available. [802.1D] cannot take 710 advantage of the multicast CIDs because it relies on unicast 711 connections or bidirectional broadcast connections. 713 A further drawback of deploying multicast CIDs for distributing 714 broadcast control messages like ARP requests is the inability to 715 prevent the wake-up of dormant-mode SSs by messages not aimed for 716 them. Whenever a message is sent over a multicast CID, all 717 associated stations have to power up and receive and process the 718 message. While this behavior is desirable for multicast and 719 broadcast traffic, it is harmful for link layer broadcast control 720 messages aimed for a single SS, like an ARP Request. All other SSs 721 are wasting scarce battery power for receiving, decoding and 722 discarding the message. Low power consumption is an extremely 723 important aspect in a wireless communication. 725 Furthermore, it should keep in mind that multicast CIDs are only 726 efficient for a large number of subscribed SSs in a cell. Due to 727 incompatibility with advanced radio layer algorithms based on 728 feedback information from the receiver side, multicast connections 729 require much more radio resource for transferring the same 730 information as unicast connections. 732 Appendix B. Centralized vs. Distributed Bridging 734 This specification introduces a network-side bridging function, which 735 can be realized either by a centralized device or by multiple 736 interconnected bridges in a distributed manner. One common 737 implementation of the distributed model is the scenario where a 738 bridge is directly attached to the BS, such that the interface 739 between BS and bridging function is becoming a software interface 740 within the operation system of the BS/Bridge device. 742 The operational enhancements described in Section 7 of this document 743 are based on the availability of additional information about all the 744 hosts attached to the Ethernet. Flooding all ports of the bridge can 745 be avoided when a-priori information is available to determine the 746 port to which an Ethernet frame has to be delivered. 748 Best performance can be reached by a centralized database containing 749 all information about the hosts attached to the Ethernet. A 750 centralized database can be established either by a centralized 751 bridge device or by a hierarchical bridging structure with dedicated 752 uplink and downlink ports like in the public access case, where the 753 uppermost bridge is able to retrieve and maintain all the 754 information. 756 As the generic case of the IP over Ethernet over IEEE 802.16 link 757 model does not make any assumption of the location of the AR (an AR 758 may eventually be attached to a SS), a centralized bridging system is 759 recommended for the generic case. In the centralized system, every 760 connection over the air of a link should be attached to a single 761 centralized bridge. The support functions of Multicast/Broadcast 762 bridging according to Section 7.1, handling of DHCP broadcasts 763 according to Section 7.2, proxy ARP function according to Section 7.3 764 and MAC-Forced Forwarding according to Section 8 are implemented in 765 the centralized bridge. 767 A distributed bridging model is in particular appropriate for the 768 public access mode, where Ethernet frames, which do not have entries 769 in the bridge behind the BS, are send upstream to a bridge finally 770 having an entry for the destination MAC address. 772 Authors' Addresses 774 Hongseok Jeon 775 Electronics Telecommunications Research Institute 776 161 Gajeong-dong, Yuseong-gu 777 Daejeon, 305-350 778 KOREA 780 Phone: +82-42-860-3892 781 Email: hongseok.jeon@gmail.com 783 Max Riegel 784 Nokia Siemens Networks 785 St-Martin-Str 76 786 Munich, 81541 787 Germany 789 Phone: +49-89-636-75194 790 Email: maximilian.riegel@nsn.com 791 Sangjin Jeong 792 Electronics Telecommunications Research Institute 793 161 Gajeong-dong, Yuseong-gu 794 Daejeon, 305-350 795 KOREA 797 Phone: +82-42-860-1877 798 Email: sjjeong@gmail.com 800 Full Copyright Statement 802 Copyright (C) The IETF Trust (2008). 804 This document is subject to the rights, licenses and restrictions 805 contained in BCP 78, and except as set forth therein, the authors 806 retain all their rights. 808 This document and the information contained herein are provided on an 809 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 810 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 811 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 812 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 813 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 814 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 816 Intellectual Property 818 The IETF takes no position regarding the validity or scope of any 819 Intellectual Property Rights or other rights that might be claimed to 820 pertain to the implementation or use of the technology described in 821 this document or the extent to which any license under such rights 822 might or might not be available; nor does it represent that it has 823 made any independent effort to identify any such rights. Information 824 on the procedures with respect to rights in RFC documents can be 825 found in BCP 78 and BCP 79. 827 Copies of IPR disclosures made to the IETF Secretariat and any 828 assurances of licenses to be made available, or the result of an 829 attempt made to obtain a general license or permission for the use of 830 such proprietary rights by implementers or users of this 831 specification can be obtained from the IETF on-line IPR repository at 832 http://www.ietf.org/ipr. 834 The IETF invites any interested party to bring to its attention any 835 copyrights, patents or patent applications, or other proprietary 836 rights that may cover technology that may be required to implement 837 this standard. Please address the information to the IETF at 838 ietf-ipr@ietf.org.