idnits 2.17.1 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors Copyright Line does not match the current year -- The document date (January 28, 2009) is 5560 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 (==), 2 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: August 1, 2009 NSN 6 S. Jeong 7 ETRI 8 January 28, 2009 10 Transmission of IP over Ethernet over IEEE 802.16 Networks 11 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-08.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and 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 1, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This document describes the transmission of IPv4 over Ethernet as 51 well as IPv6 over Ethernet in an access network deploying the IEEE 52 802.16 cellular radio transmission technology. The Ethernet on top 53 of IEEE 802.16 is realized by bridging connections which the IEEE 54 802.16 provides between a base station and its associated subscriber 55 stations. Due to the resource constraints of radio transmission 56 systems and the limitations of the IEEE 802.16 MAC functionality for 57 the realization of an Ethernet, the transmission of IP over Ethernet 58 over IEEE 802.16 may considerably benefit by adding IP specific 59 support functions in the Ethernet over IEEE 802.16 while maintaining 60 full compatibility with standard IP over Ethernet behavior. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . . 4 68 4.1. Connection Oriented Air Interface . . . . . . . . . . . . 4 69 4.2. MAC addressing in IEEE 802.16 . . . . . . . . . . . . . . 5 70 4.3. Unidirectional Broadcast and Multicast Support . . . . . . 6 71 4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet . . 6 72 5. Ethernet Network Model for IEEE 802.16 . . . . . . . . . . . . 6 73 5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 7 74 5.2. Ethernet without Native Broadcast and Multicast Support . 8 75 5.3. Network-side Bridging Function . . . . . . . . . . . . . . 8 76 5.4. Segmenting the Ethernet into VLAN . . . . . . . . . . . . 9 77 6. Transmission of IP over Ethernet over IEEE 802.16 Link . . . . 9 78 6.1. Generic IP over Ethernet Network Scenario . . . . . . . . 9 79 6.2. Transmission of IP over Ethernet . . . . . . . . . . . . . 10 80 6.2.1. IPv4 over Ethernet Packet Transmission . . . . . . . . 10 81 6.2.2. IPv6 over Ethernet Packet Transmission . . . . . . . . 10 82 6.2.3. Maximum Transmission Unit . . . . . . . . . . . . . . 11 83 6.2.4. Prefix Assignment . . . . . . . . . . . . . . . . . . 11 84 7. Operational Enhancements for IP over Ethernet over IEEE 85 802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 7.1. IP Multicast and Broadcast Packet Processing . . . . . . . 12 87 7.1.1. Multicast Transmission Considerations . . . . . . . . 12 88 7.1.2. Broadcast Transmission Considerations . . . . . . . . 12 89 7.2. DHCPv4 Considerations . . . . . . . . . . . . . . . . . . 13 90 7.3. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . 13 91 8. Public Access Recommendations . . . . . . . . . . . . . . . . 13 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 98 Appendix A. Multicast CID Deployment Considerations . . . . . . . 17 99 Appendix B. Centralized vs. Distributed Bridging . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 IEEE 802.16 [802.16] specifies a fixed to mobile broadband wireless 105 access system. 107 The IEEE 802.16 standard defines a packet CS (Convergence Sublayer) 108 for interfacing with specific packet-based protocols as well as a 109 generic packet CS (GPCS) to provide an upper-layer protocol 110 independent interface. This document describes transmission of IPv4 111 and IPv6 over Ethernet via the Ethernet specific part of the packet 112 CS as well as the GPCS in the IEEE 802.16 based access network. 114 Ethernet is a widely deployed transmission technology. It provides 115 unicast transport, handles broadcast and multicast traffic 116 efficiently, and provides rich services such as Virtual LANs. 117 However, Ethernet has been originally architected and designed for a 118 shared medium while the IEEE 802.16 uses a point-to-multipoint 119 architecture like other cellular radio transmission systems. Hence, 120 Ethernet on top of IEEE 802.16 is realized by bridging between IEEE 121 802.16 radio connections between a BS (Base Station) and its 122 associated SSs (Subscriber Stations). 124 Under the resource constraints of radio transmission systems and the 125 particularities of the IEEE 802.16 for the realization of Ethernet, 126 it makes sense to add IP specific support functions in the Ethernet 127 layer above IEEE 802.16 while maintaining full compatibility with 128 standard IP over Ethernet behavior. 130 2. Requirements 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Terminology 138 The terminology in this document is based on the definitions in IP 139 over 802.16 Problem Statement and Goals [RFC5154]. 141 4. The IEEE 802.16 Link Model 143 4.1. Connection Oriented Air Interface 145 The IEEE 802.16 MAC establishes connections between a BS and its 146 associated SSs for the transfer of user data over the air. Each of 147 these connections realizes an individual Service Flow which is 148 identified by a 16-bit CID number and has a defined QoS profile. 150 Multiple connections can be established between a BS and a SS, each 151 with its particular QoS class and direction. Although the BS and all 152 the SSs are associated with unique 48-bit MAC addresses, packets 153 going over the air are only identified in the IEEE 802.16 MAC header 154 by the CID number of the particular connection. The connections are 155 established by MAC management messages between the BS and the SS 156 during network entry or also later on demand. 158 [Subscriber Side] [Network Side] 160 | | | + 161 | | | + 162 +--+--+ +--+--+ +--+-+-+--+ 163 | MAC | | MAC | | MAC | 164 +-----+ +-----+ +---------+ 165 | PHY | | PHY | | PHY | 166 +-+-+-+ +-+-+-+ +-+-+-+-+-+ 167 + + | | | | + + 168 + + | +-----CID#w------+ | + + 169 + + +-------CID#x--------+ + + 170 + +++++++++++++++++CID#y+++++++++++++++++ + 171 +++++++++++++++++++CID#z+++++++++++++++++++ 172 SS#1 SS#2 BS 174 Figure 1. Basic IEEE 802.16 Link Model 176 4.2. MAC addressing in IEEE 802.16 178 Each SS has a unique 48-bit MAC address and the 48-bit MAC address is 179 used during the initial ranging process for the identification of the 180 SS and may be verified by the succeeding PKM (Privacy Key Management) 181 authentication phase. Out of the successful authentication, the BS 182 establishes and maintains the list of attached SSs based on their MAC 183 addresses purely for MAC management purposes. 185 While MAC addresses are assigned to all the BSs as well as the SSs, 186 the forwarding of packets over the air is only based on the CID value 187 of the particular connection in the IEEE 802.16 MAC header. Not 188 relying on the MAC addresses in the payload for reception of a radio 189 frame allows for the transport of arbitrary source and destination 190 MAC addresses in Ethernet frames between a SS and its BS. This is 191 required for bridging Ethernet frames toward a SS which is attached 192 to a bridge connected to another network. 194 Due to the managed assignment of the service flows and associated CID 195 values to individual SSs, the BS is able to bundle all unicast 196 connections belonging to a particular SS into a single link on the 197 network side as shown in Figure 1 so that it provides a single layer 198 2 link between the SS and its associated wired link on the network 199 side. 201 4.3. Unidirectional Broadcast and Multicast Support 203 Current IEEE 802.16 [802.16] does not support bi-directional native 204 broadcast and multicast for IP packets. While downlink connections 205 can be used for multicast transmission to a group of SSs as well as 206 unicast transmission from the BS to a single SS, uplink connections 207 from the SSs to the BS provide only unicast transmission 208 capabilities. Furthermore, the use of multicast CIDs for realizing 209 downlink multicast transmissions is not necessarily preferable due to 210 the reduced transmission efficiency of multicast CIDs for small 211 multicast groups. Appendix A provides more background information 212 about the issues arising with multicast CIDs in IEEE 802.16 systems. 214 MBS (Multicast and Broadcast Service) as specified in IEEE 802.16 215 also does not cover IP broadcast or multicast data because MBS is 216 invisible to the IP layer. 218 4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet 220 IEEE 802.16 provides two solutions to transfer Ethernet frames over 221 IEEE 802.16 MAC connections. 223 The packet CS is defined for handling packet-based protocols by 224 classifying higher-layer packets depending on the values in the 225 packet header fields and assigning the packets to the related service 226 flow. The packet CS comprises multiple protocol specific parts to 227 enable the transmission of different kind of packets over IEEE 228 802.16. The Ethernet specific part of the packet CS supports the 229 transmission of Ethernet by defining classification rules based on 230 Ethernet header information. 232 The GPCS (Generic Packet Convergence Sublayer) may be used as 233 alternative to transfer Ethernet frames over IEEE 802.16. The GPCS 234 does not define classification rules for each kind of payload but 235 relies on higher layer functionality outside of the scope of IEEE 236 802.16 to provide the assignment of packets to particular service 237 flows. 239 5. Ethernet Network Model for IEEE 802.16 241 According to [RFC4861], a link is defined as a communication facility 242 or medium over which IP devices can communicate at the link layer, 243 i.e. the layer immediately below IP. Ethernet fully satisfies the 244 definition of the link. IEEE 802.16, however, has limitations on its 245 transitive connectivity, i.e. IEEE 802.16 provides point-to-point 246 connections between SSs and the BS but does not enable any direct SS 247 to SS connectivity. Hence, it is required to bridge each of the 248 point-to-point connections between SSs and the BS so that Ethernet is 249 realized over IEEE 802.16 access network. 251 5.1. IEEE 802.16 Ethernet Link Model 253 To realize Ethernet on top of IEEE 802.16 all the point-to-point 254 connections belonging to a SS MUST be connected to a network-side 255 bridging function, as shown in Figure 2. This is equivalent to 256 today's switched Ethernet with twisted pair wires or fibres 257 connecting the hosts to a bridge ("Switch"). 259 The network-side bridging function can be realized either by a single 260 centralized network-side bridge or by multiple interconnected 261 bridges, preferable arranged in a hierarchical order. The single 262 centralized network-side bridge allows best control of the 263 broadcasting and forwarding behavior of the Ethernet over IEEE 264 802.16. Appendix B explains the issues of a distributed bridging 265 architecture, when no assumptions about the location of the access 266 router can be made. 268 The BS MUST forward all the Service Flows belonging to one SS to one 269 port of the network-side bridging function. No more than one SS MUST 270 be connected to one port of the network-side bridging function. The 271 separation method for multiple links on the connection between the BS 272 and the network-side bridging function is out of scope for this 273 document. Either Layer 2 transport or Layer 3 tunneling may be used. 275 If the Ethernet over IEEE 802.16 is extended to multiple end stations 276 behind the SS (i.e. SS#4 in the below figure) then the SS SHOULD 277 support bridging according to [802.1D] and its amendment [802.16k], 278 a.k.a. subscriber-side bridge, between all its subscriber side ports 279 and the IEEE 802.16 air link. 281 ------------------------ IP Link -------------------------- 283 [Subscriber Side] [Network Side] [Subscriber Side] 284 | | | | | | 285 ETH ETH ETH ETH ETH ETH 286 | | | | | | 287 | | +---------+---------+ | +-+---+-+ 288 | | | Bridging Function | | |Bridge | 289 | | +--+-+---------+-+--+ | +---+---+ 290 | | | + + | | | 291 +--+--+ +--+--+ +--+-+--+ +--+-+--+ +--+--+ +--+--+ 292 | MAC | | MAC | | MAC | | MAC | | MAC | | MAC | 293 +-----+ +-----+ +-------+ +-------+ +-----+ +-----+ 294 | PHY | | PHY | | PHY | | PHY | | PHY | | PHY | 295 +-+-+-+ +-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+ +-+-+-+ 296 + | | | | + + | | | | + 297 + | +--CID#u-+ | + + | +-CID#x--+ | + 298 + +----CID#v---+ + + +---CID#y----+ + 299 +++++++++++++++CID#w++++++ ++++++CID#z+++++++++++++++ 301 SS#1 SS#2 BS#1 BS#2 SS#3 SS#4 303 Figure 2. IEEE 802.16 Ethernet Link Model 305 5.2. Ethernet without Native Broadcast and Multicast Support 307 Current IEEE 802.16 does not define broadcast and multicast of 308 Ethernet frames. Hence Ethernet broadcast and multicast frames 309 SHOULD be replicated and then carried via unicast transport 310 connections on IEEE 802.16 access link. The network-side bridging 311 function performs the replication and forwarding for Ethernet 312 broadcast and multicast over the IEEE 802.16 radio links 314 5.3. Network-side Bridging Function 316 The network-side bridging function SHOULD create a new radio side 317 port whenever a new SS attaches to any of the BSs of the network or 318 SHOULD remove a radio side port when an associated SS detaches from 319 the BSs. The method for managing the port on the network-side 320 bridging function may depend on the protocol used for establishing 321 multiple links on the connection between the BS and the network-side 322 bridge. The port managing method is out of scope for this document. 324 The network-side bridging function SHALL be based on [802.1D] and its 325 amendment [802.16k] to interconnect the attached SSs and pass 326 Ethernet frames between the point-to-point connections associated 327 with the attached SSs. However, to enhance the IEEE 802.16 Ethernet 328 link model by avoiding broadcast or multicast packet flooding, 329 additional IP specific functionalities MAY be provided by the 330 network-side bridging function in addition to the mandatory functions 331 according to Section 5.1 of [802.1D]. 333 5.4. Segmenting the Ethernet into VLAN 335 It is possible to restrict the size and coverage of the broadcast 336 domain by segmenting the Ethernet over IEEE 802.16 into VLANs and 337 grouping subsets of hosts into particular VLANs with each VLAN 338 representing an IP link. Therefore, the network-side bridging 339 function MAY be enabled to support VLANs according to [802.1Q] by 340 assigning and handling the VLAN-IDs on the virtual bridge ports. 342 If a SS is directly connected to a subscriber-side bridge supporting 343 VLANs, the port associated with such a SS MAY be enabled as trunk 344 port. On trunk ports, Ethernet frames are forwarded in the [802.1Q] 345 frame format. 347 6. Transmission of IP over Ethernet over IEEE 802.16 Link 349 6.1. Generic IP over Ethernet Network Scenario 351 The generic IP over Ethernet network scenario assumes that all hosts 352 are residing on the same link with trust relationship between all of 353 them. It enables the hosts to directly communicate with each other 354 without detouring. There can be multiple ARs on the link, which may 355 reside both on the subscriber side as well as on the network side as 356 shown in Figure 3. 358 +--+--+ 359 ---|AR|SS| 360 +--+--+* +----+ 361 * +----+ +Host| 362 +----+--+ * | +-------+ /+----+ 363 |Host|SS|* * * * **| BS +------+ \ / +----+ 364 +----+--+ * | +-----+ \ \ / ++Host| 365 +----+--+ * +----+ \ \ +-+--------+ / +----+ 366 |Host|SS|* \ +--+ ++ 367 +----+ +----+--+ +---+Bridging| +----+ 368 --+ AR ++ |Function+---+ AR +--- 369 +----+ \ +--+ | +----+ 370 \ +----+ / +-+--------+ 371 +----+ +------+--+ | +---+ / 372 |Host+-+Bridge|SS|* * * *| BS | / 373 +----+ +------+--+ * | +---+ 374 +----+/ * +----+ 375 |Host+ +----+--+ * 376 +----+ |Host|SS|* 377 +----+--+ 379 Figure 3. Generic IP over Ethernet Network Scenario using IEEE 802.16 381 6.2. Transmission of IP over Ethernet 383 6.2.1. IPv4 over Ethernet Packet Transmission 385 [RFC0894] defines the transmission of IPv4 packets over Ethernet 386 networks. It contains the specification of the encapsulation of the 387 IPv4 packets into Ethernet frames as well as rules for mapping of IP 388 addresses onto Ethernet MAC addresses. Hosts transmitting IPv4 over 389 Ethernet packets over the IEEE 802.16 MUST follow the operations 390 specified in [RFC0894]. 392 6.2.1.1. Address Configuration 394 IPv4 addresses can be configured manually or assigned dynamically 395 from DHCPv4 server [RFC2131]. 397 6.2.1.2. Address Resolution 399 Address Resolution Protocol (ARP) [RFC0826] MUST be used for finding 400 the destination Ethernet MAC address. 402 6.2.2. IPv6 over Ethernet Packet Transmission 404 [RFC2464] defines transmission of IPv6 Packets over Ethernet Networks 405 which includes an encapsulation of IPv6 packets into Ethernet frames 406 and mapping rules for IPv6 address to Ethernet address (i.e. MAC 407 address). Host transmitting IPv6 over Ethernet packets over the IEEE 408 802.16 MUST follow the operations specified in [RFC2464]. 410 6.2.2.1. Router Discovery, Prefix Discovery and Parameter Discovery 412 Router Discovery, Prefix Discovery and Parameter Discovery procedures 413 are achieved by receiving Router Advertisement messages. However, 414 periodic Router Advertisement messages can waste radio resource and 415 disturb SSs in dormant mode in IEEE 802.16. Therefore, the 416 AdvDefaultLifetime and MaxRtrAdvInterval SHOULD be overridden with 417 high values specified in Section 8.3 in [RFC5121]. 419 6.2.2.2. Address Configuration 421 When stateful address autoconfiguration is required, the stateful 422 address configuration according to [RFC3315] MUST be performed. In 423 this case, an AR supports DHCP server or relay function. 425 When stateless address autoconfiguration is required, the stateless 426 address configuration according to [RFC4862] and [RFC4861] MUST be 427 performed. 429 6.2.2.3. Address Resolution 431 Neighbor Discovery Protocol (NDP) [RFC4861] MUST be used for 432 determining the destination Ethernet MAC address. 434 6.2.3. Maximum Transmission Unit 436 [RFC2460] mandates 1280 bytes as a minimum Maximum Transmission Unit 437 (MTU) size for link layer and recommends at least 1500 bytes for IPv6 438 over Ethernet transmission. [RFC0894] also specifies 1500 bytes as a 439 maximum length of IPv4 over Ethernet. Therefore, the default MTU of 440 IPv6 packets and IPv4 packets on Ethernet over IEEE 802.16 link MUST 441 be 1500 bytes. 443 6.2.4. Prefix Assignment 445 The same IPv4 prefix and the same set of IPv6 prefixes SHOULD be 446 assigned to all hosts attached to the Ethernet over IEEE 802.16. 447 Sharing the prefix means locating all hosts on the same subnetwork. 449 7. Operational Enhancements for IP over Ethernet over IEEE 802.16 451 This section presents operational enhancements in order to improve 452 network performance and radio resource efficiency for transmission of 453 IP packets over Ethernet over IEEE 802.16 networks. 455 7.1. IP Multicast and Broadcast Packet Processing 457 All multicast and multicast control messages SHOULD be processed in 458 the network-side bridging function according to [RFC4541]. 459 Broadcasting messages to all radio-side side ports SHOULD be 460 prevented. 462 Further information on prevention of multicasting or broadcasting 463 messages to all radio side ports are given in the following sections. 465 7.1.1. Multicast Transmission Considerations 467 Usually, bridges replicate the IP multicast packets and forward them 468 into all of its available ports except the incoming port. As a 469 result, the IP multicast packets would be transmitted over the air 470 even to hosts which has not joined the corresponding multicast group. 471 To allow bridges to handle IP multicast more efficiently, the IP 472 multicast membership information should be propagated between 473 bridges. 475 In the IEEE 802.16 Ethernet link model in Section 5.1, the network- 476 side bridging function SHOULD process all multicast data and 477 multicast control messages according to [RFC4541] to maintain IP 478 multicast membership states and forward IP multicast data to only 479 ports suitable for the multicast group. 481 7.1.2. Broadcast Transmission Considerations 483 The ordinary bridge floods the IP broadcast packets out of all 484 connected ports except the port on which the packet was received. 485 This behavior is not appropriate with scarce resources and dormant- 486 mode hosts in a wireless network such as an IEEE 802.16 based access 487 network. 489 The network-side bridging function in the IEEE 802.16 Ethernet link 490 model SHOULD flood all IP broadcast packets except ARP, DHCPv4 and 491 IGMP related traffic. 493 IGMP related broadcast packets SHOULD be forwarded according to the 494 [RFC4541]. ARP related broadcast SHOULD be processed as specified in 495 Section 7.3. DHCPv4 related broadcast packets SHOULD be handled as 496 specified in Section 7.2. 498 7.2. DHCPv4 Considerations 500 DHCPv4 clients may send DHCP DISCOVER and DHCP REQUEST messages with 501 the BROADCAST bit set to request the DHCP server to broadcast its 502 DHCP OFFER and DHCP ACK messages. The network-side bridging function 503 SHOULD filter these broadcast DHCP OFFER and DHCP ACK messages and 504 forwards the broadcast messages only to the host defined by the 505 client hardware address in the chaddr information element. 507 Alternatively, the DHCP Relay Agent Information Option (option-82) 508 [RFC3046] MAY be used to avoid DHCP broadcast replies. The option-82 509 consists of two type of sub-options; Circuit ID and Remote ID. DHCP 510 Relay Agent is usually located on the network-side bridging function 511 as Layer 2 DHCP Relay Agent. Port number of the network-side 512 bridging function is possible as Circuit ID and Remote ID may be left 513 unspecified. Note that using option-82 requires option-82 aware DHCP 514 servers. 516 7.3. Proxy ARP 518 Proxy ARP provides the function in which a device on the same link as 519 the hosts answers ARP Requests instead of the remote host. When 520 transmitting IPv4 packets over the IEEE 802.16 Ethernet link , the 521 Proxy ARP mechanism is used by the network-side bridging function to 522 avoid broadcasting ARP Requests over the air. 524 The network-side bridging function SHOULD maintain an ARP cache large 525 enough to accommodate ARP entries for all its serving SSs. The ARP 526 cache SHOULD be updated by any packets including ARP Requests from 527 SSs in the same way the normal layer-2 bridging device is updating 528 its Filtering Database according to [802.1D]. 530 Upon receiving an ARP Request from a SS, the network-side bridging 531 function SHOULD unicast an ARP Reply back to the SS with the Ethernet 532 address of the target host provided that the target address matches 533 an entry in the ARP Cache. However, in case of receiving an ARP 534 request from a host behind a subscriber-side bridge, the network-side 535 bridging function SHOULD discard the request if the target host is 536 also behind the same subscriber-side bridge, i.e., on the same port 537 of the network-side bridge. Otherwise, the ARP Request MAY be 538 flooded. The network-side bridging function SHOULD silently discard 539 any received self-ARP Request. 541 8. Public Access Recommendations 543 In the Public Access scenario, direct communication between nodes is 544 restricted because of security and accounting issues. Figure 4 545 depicts the public access scenario. 547 In the scenario, the AR is connected to a network-side bridge. The 548 AR MAY perform security filtering, policing and accounting of all 549 traffic from hosts, e.g. like a NAS (Network Access Server). 551 If the AR functions as the NAS, all the traffic from SSs SHOULD be 552 forwarded to the AR, not bridged at the network-side bridging 553 function, even in the case of traffic between SSs served by the same 554 AR. The bridge SHOULD forward upstream traffic from hosts toward the 555 AR but SHALL perform normal bridging operation for downstream traffic 556 from the AR and SHALL bridge SEcure Neighbor Discovery (SEND) 557 [RFC3971] messages to allow applicability of security schemes. 559 In IPv4 over Ethernet case, MAC-Forced Forwarding (MAC-FF) [RFC4562] 560 SHOULD be used for the public access network to ensure that traffic 561 from all hosts is always directed to the AR. The MAC-FF is performed 562 in the network-side bridging function, thus the bridge filters 563 broadcast ARP Requests from all the hosts and responds to the ARP 564 Requests with an Ethernet MAC address of the AR. 566 In IPv6 over Ethernet case, unique IPv6 prefix per SS can be assigned 567 because it forces all IPv6 packets from SSs to be transferred to the 568 AR and thus it results in layer 3 separation between SSs. 569 Alternatively, common IPv6 prefixes can be assigned to all SSs served 570 by the same AR in order to exploit the efficient multicast support of 571 Ethernet link in the network side. In the latter case, a Prefix 572 Information Option (PIO) [RFC4861] carrying the common IPv6 prefixes 573 SHOULD be advertised with On-link flag (L-Flag) reset so that it is 574 not assumed that the addresses matching the prefixes are available 575 on-link. 577 The AR should relay packets between SSs within the same AR. 579 +-+--+ 580 |H|SS| +- - - - - - - - - - + 581 +-+--+* +----+ | +------+ 582 +-+--+ * | +-----+ | | 583 |H|SS|* * * * * *| BS +-----+Bridge+-+ 584 +-+--+ * | +-----+ | | +-----+ | 585 * +----+ | +------+ | | B | 586 +-+--+ * | +-+ r | | +-------+ 587 |H|SS|* | i +---+AR(NAS)+-- 588 +---+ +-+--+ | | d | | +-------+ 589 | H ++ +-+ g | 590 +---+ \ +----+ | +------+ | | e | | 591 +---+ +--+--+ | +----+ | | +-----+ 592 | H +--+Br|SS|* * * * | BS | | |Bridge+-+ | 593 +---+ +--+--+ * | +----+ | 594 +---+ / * +----+ | +------+ | 595 | H ++ +-+--+ * 596 +---+ |H|SS|* | Bridging Function | 597 +-+--+ +- - - - - - - - - - + 599 Figure 4. Public Access Network using IEEE 802.16 601 9. IANA Considerations 603 This document has no actions for IANA. 605 10. Security Considerations 607 This document does not introduce any new vulnerabilities to IPv4 and 608 IPv6 specifications or operations. The security of the IEEE 802.16 609 air interface between SSs and BS is the subject of [802.16] and the 610 security issues of Ethernet bridging are the subjects of [802.1D]. 611 The generic IP over Ethernet network using IEEE 802.16 emulates 612 Ethernet link, since existing IPv4 and IPv6 security mechanisms over 613 Ethernet can be still used. While the public access network ensures 614 secure isolation of each of upstream link between hosts and AR, it 615 still adopts SEcure Neighbor Discovery (SEND) [RFC3971] for securing 616 neighbor discovery processes and it does not introduce any new 617 vulnerabilities over those of Ethernet bridging. 619 11. Acknowledgments 621 The authors would like to thank David Johnston, Dave Thaler, Jari 622 Arkko and others for their inputs to this work. 624 12. References 626 12.1. Normative References 628 [802.16] P802.16Rev2D9, "Draft Standard for Local and metropolitan 629 area networks, Part 16: Air Interface for Fixed Broadband 630 Wireless Access Systems (to be updated according to the 631 released IEEE 802.16-2009 standard)", January 2009. 633 [802.16k] IEEE Std 802.16k-2007, "IEEE Standard for Local and 634 metropolitan area networks, Media Access Control (MAC) 635 Bridges, Amendment 5: Bridging of IEEE 802.16", 636 March 2007. 638 [802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and 639 metropolitan area networks, Media Access Control (MAC) 640 Bridges", June 2004. 642 [802.1Q] IEEE Std 802.1Q-2005, "IEEE Standard for Local and 643 metropolitan area networks, Virtual Bridged Local Area 644 Networks", May 2005. 646 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 647 converting network protocol addresses to 48.bit Ethernet 648 address for transmission on Ethernet hardware", STD 37, 649 RFC 826, November 1982. 651 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 652 over Ethernet networks", STD 41, RFC 894, April 1984. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 658 RFC 2131, March 1997. 660 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 661 (IPv6) Specification", RFC 2460, December 1998. 663 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 664 Networks", RFC 2464, December 1998. 666 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 667 and M. Carney, "Dynamic Host Configuration Protocol for 668 IPv6 (DHCPv6)", RFC 3315, July 2003. 670 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 671 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 672 September 2007. 674 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 675 Address Autoconfiguration", RFC 4862, September 2007. 677 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 678 Madanapalli, "Transmission of IPv6 via the IPv6 679 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 680 February 2008. 682 12.2. Informative References 684 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 685 RFC 3046, January 2001. 687 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 688 Neighbor Discovery (SEND)", RFC 3971, March 2005. 690 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 691 "Considerations for Internet Group Management Protocol 692 (IGMP) and Multicast Listener Discovery (MLD) Snooping 693 Switches", RFC 4541, May 2006. 695 [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method 696 for Subscriber Separation on an Ethernet Access Network", 697 RFC 4562, June 2006. 699 [RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE 700 802.16 Problem Statement and Goals", RFC 5154, April 2008. 702 Appendix A. Multicast CID Deployment Considerations 704 Multicast CIDs are highly efficient means to distribute the same 705 information concurrently to multiple SSs under the same BS. However, 706 the deployment of multicast CIDs for multicast or broadcast data 707 services suffers from following drawbacks. 709 A drawback of multicast CIDs for Ethernet over IEEE 802.16 is the 710 unidirectional nature of multicast CIDs. While it is possible to 711 multicast information downstream to a number of SSs in parallel, 712 there are no upstream multicast connections. In upstream direction, 713 unicast CIDs have to be used for sending multicast messages over the 714 air to the BS requiring a special multicast forwarding function for 715 sending the information back to the other SSs on a multicast CID. 716 While similar in nature to a bridging function, there is no 717 appropriate forwarding model available. [802.1D] cannot take 718 advantage of the multicast CIDs because it relies on unicast 719 connections or bidirectional broadcast connections. 721 A further drawback of deploying multicast CIDs for distributing 722 broadcast control messages like ARP requests is the inability to 723 prevent the wake-up of dormant-mode SSs by messages not aimed for 724 them. Whenever a message is sent over a multicast CID, all 725 associated stations have to power up and receive and process the 726 message. While this behavior is desirable for multicast and 727 broadcast traffic, it is harmful for link layer broadcast control 728 messages aimed for a single SS, like an ARP Request. All other SSs 729 are wasting scarce battery power for receiving, decoding and 730 discarding the message. Low power consumption is an extremely 731 important aspect in a wireless communication. 733 Furthermore, it should keep in mind that multicast CIDs are only 734 efficient for a large number of subscribed SSs in a cell. Due to 735 incompatibility with advanced radio layer algorithms based on 736 feedback information from the receiver side, multicast connections 737 require much more radio resource for transferring the same 738 information as unicast connections. 740 Appendix B. Centralized vs. Distributed Bridging 742 This specification introduces a network-side bridging function, which 743 can be realized either by a centralized device or by multiple 744 interconnected bridges in a distributed manner. One common 745 implementation of the distributed model is the scenario where a 746 bridge is directly attached to the BS, such that the interface 747 between BS and bridging function is becoming a software interface 748 within the operation system of the BS/Bridge device. 750 The operational enhancements described in Section 7 of this document 751 are based on the availability of additional information about all the 752 hosts attached to the Ethernet. Flooding all ports of the bridge can 753 be avoided when a-priori information is available to determine the 754 port to which an Ethernet frame has to be delivered. 756 Best performance can be reached by a centralized database containing 757 all information about the hosts attached to the Ethernet. A 758 centralized database can be established either by a centralized 759 bridge device or by a hierarchical bridging structure with dedicated 760 uplink and downlink ports like in the public access case, where the 761 uppermost bridge is able to retrieve and maintain all the 762 information. 764 As the generic case of the IP over Ethernet over IEEE 802.16 link 765 model does not make any assumption of the location of the AR (an AR 766 may eventually be attached to a SS), a centralized bridging system is 767 recommended for the generic case. In the centralized system, every 768 connection over the air of a link should be attached to a single 769 centralized bridge. 771 A distributed bridging model is in particular appropriate for the 772 public access mode, where Ethernet frames, which do not have entries 773 in the bridge behind the BS, are send upstream to a bridge finally 774 having an entry for the destination MAC address. 776 Authors' Addresses 778 Hongseok Jeon 779 Electronics Telecommunications Research Institute 780 161 Gajeong-dong, Yuseong-gu 781 Daejeon, 305-350 782 KOREA 784 Phone: +82-42-860-3892 785 Email: hongseok.jeon@gmail.com 787 Max Riegel 788 Nokia Siemens Networks 789 St-Martin-Str 76 790 Munich, 81541 791 Germany 793 Phone: +49-89-636-75194 794 Email: maximilian.riegel@nsn.com 796 Sangjin Jeong 797 Electronics Telecommunications Research Institute 798 161 Gajeong-dong, Yuseong-gu 799 Daejeon, 305-350 800 KOREA 802 Phone: +82-42-860-1877 803 Email: sjjeong@etri.re.kr