idnits 2.17.1 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-11.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 9, 2009) is 5343 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 (~~), 2 warnings (==), 1 comment (--). 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: March 13, 2010 NSN 6 S. Jeong 7 ETRI 8 September 9, 2009 10 Transmission of IP over Ethernet over IEEE 802.16 Networks 11 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-11.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. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on March 13, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes the transmission of IPv4 over Ethernet as 60 well as IPv6 over Ethernet in an access network deploying the IEEE 61 802.16 cellular radio transmission technology. The Ethernet on top 62 of IEEE 802.16 is realized by bridging connections which the IEEE 63 802.16 provides between a base station and its associated subscriber 64 stations. Due to the resource constraints of radio transmission 65 systems and the limitations of the IEEE 802.16 Media Access Control 66 (MAC) functionality for the realization of an Ethernet, the 67 transmission of IP over Ethernet over IEEE 802.16 may considerably 68 benefit by adding IP specific support functions in the Ethernet over 69 IEEE 802.16 while maintaining full compatibility with standard IP 70 over Ethernet behavior. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . . 4 78 4.1. Connection Oriented Air Interface . . . . . . . . . . . . 4 79 4.2. MAC addressing in IEEE 802.16 . . . . . . . . . . . . . . 5 80 4.3. Unidirectional Broadcast and Multicast Support . . . . . . 6 81 4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet . . 6 82 5. Ethernet Network Model for IEEE 802.16 . . . . . . . . . . . . 7 83 5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 7 84 5.2. Ethernet without Native Broadcast and Multicast Support . 8 85 5.3. Network-side Bridging Function . . . . . . . . . . . . . . 8 86 5.4. Segmenting the Ethernet into VLANs . . . . . . . . . . . . 9 87 6. Transmission of IP over Ethernet over IEEE 802.16 Link . . . . 9 88 6.1. Generic IP over Ethernet Network Scenario . . . . . . . . 9 89 6.2. Transmission of IP over Ethernet . . . . . . . . . . . . . 10 90 6.2.1. IPv4 over Ethernet Packet Transmission . . . . . . . . 10 91 6.2.2. IPv6 over Ethernet Packet Transmission . . . . . . . . 11 92 6.2.3. Maximum Transmission Unit . . . . . . . . . . . . . . 11 93 6.2.4. Prefix Assignment . . . . . . . . . . . . . . . . . . 11 94 7. Operational Enhancements for IP over Ethernet over IEEE 95 802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 7.1. IP Multicast and Broadcast Packet Processing . . . . . . . 12 97 7.1.1. Multicast Transmission Considerations . . . . . . . . 12 98 7.1.2. Broadcast Transmission Considerations . . . . . . . . 12 99 7.2. DHCP Considerations . . . . . . . . . . . . . . . . . . . 13 100 7.3. Address Resolution Considerations . . . . . . . . . . . . 13 101 8. Public Access Recommendations . . . . . . . . . . . . . . . . 14 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 104 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 106 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 107 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 108 Appendix A. Multicast CID Deployment Considerations . . . . . . . 18 109 Appendix B. Centralized vs. Distributed Bridging . . . . . . . . 19 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 112 1. Introduction 114 IEEE 802.16 [802.16] specifies a fixed to mobile broadband wireless 115 access system. 117 The IEEE 802.16 standard defines a packet CS (Convergence Sublayer) 118 for interfacing with specific packet-based protocols as well as a 119 generic packet CS (GPCS) to provide an upper-layer protocol 120 independent interface. This document describes transmission of IPv4 121 and IPv6 over Ethernet via the Ethernet specific part of the packet 122 CS as well as the GPCS in the IEEE 802.16 based access network. 124 Ethernet is a widely deployed transmission technology. It provides 125 unicast transport, handles broadcast and multicast traffic 126 efficiently, and provides rich services such as Virtual LANs. 127 However, Ethernet has been originally architected and designed for a 128 shared medium while the IEEE 802.16 uses a point-to-multipoint 129 architecture like other cellular radio transmission systems. Hence, 130 Ethernet on top of IEEE 802.16 is realized by bridging between IEEE 131 802.16 radio connections between a BS (Base Station) and its 132 associated SSs (Subscriber Stations). 134 Under the resource constraints of radio transmission systems and the 135 particularities of the IEEE 802.16 for the realization of Ethernet, 136 it makes sense to add IP specific support functions in the Ethernet 137 layer above IEEE 802.16 while maintaining full compatibility with 138 standard IP over Ethernet behavior. 140 2. Requirements 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Terminology 148 The terminology in this document is based on the definitions in IP 149 over 802.16 Problem Statement and Goals [RFC5154]. 151 4. The IEEE 802.16 Link Model 153 4.1. Connection Oriented Air Interface 155 The IEEE 802.16 MAC establishes connections between a BS and its 156 associated SSs for the transfer of user data over the air. Each of 157 these connections realizes an individual Service Flow which is 158 identified by a 16-bit Connection Identifier (CID) number and has a 159 defined Quality of Service (QoS) profile. 161 Multiple connections can be established between a BS and a SS, each 162 with its particular QoS class and direction. Although the BS and all 163 the SSs are associated with unique 48-bit MAC addresses, packets 164 going over the air are only identified in the IEEE 802.16 MAC header 165 by the CID number of the particular connection. The connections are 166 established by MAC management messages between the BS and the SS 167 during network entry or also later on demand. 169 [Subscriber Side] [Network Side] 171 | | | + 172 | | | + 173 +--+--+ +--+--+ +--+-+-+--+ 174 | MAC | | MAC | | MAC | 175 +-----+ +-----+ +---------+ 176 | PHY | | PHY | | PHY | 177 +-+-+-+ +-+-+-+ +-+-+-+-+-+ 178 + + | | | | + + 179 + + | +-----CID#w------+ | + + 180 + + +-------CID#x--------+ + + 181 + +++++++++++++++++CID#y+++++++++++++++++ + 182 +++++++++++++++++++CID#z+++++++++++++++++++ 183 SS#1 SS#2 BS 185 Figure 1. Basic IEEE 802.16 Link Model 187 4.2. MAC addressing in IEEE 802.16 189 Each SS has a unique 48-bit MAC address and the 48-bit MAC address is 190 used during the initial ranging process for the identification of the 191 SS and may be verified by the succeeding PKM (Privacy Key Management) 192 authentication phase. Out of the successful authentication, the BS 193 establishes and maintains the list of attached SSs based on their MAC 194 addresses purely for MAC management purposes. 196 While MAC addresses are assigned to all the BSs as well as the SSs, 197 the forwarding of packets over the air is only based on the CID value 198 of the particular connection in the IEEE 802.16 MAC header. Not 199 relying on the MAC addresses in the payload for reception of a radio 200 frame allows for the transport of arbitrary source and destination 201 MAC addresses in Ethernet frames between a SS and its BS. This is 202 required for bridging Ethernet frames toward a SS which is attached 203 to a bridge connected to another network. 205 Due to the managed assignment of the service flows and associated CID 206 values to individual SSs, the BS is able to bundle all unicast 207 connections belonging to a particular SS into a single link on the 208 network side as shown in Figure 1 so that it provides a single layer 209 2 link between the SS and its associated wired link on the network 210 side. 212 4.3. Unidirectional Broadcast and Multicast Support 214 Current IEEE 802.16 [802.16] does not support bi-directional native 215 broadcast and multicast for IP packets. While downlink connections 216 can be used for multicast transmission to a group of SSs as well as 217 unicast transmission from the BS to a single SS, uplink connections 218 from the SSs to the BS provide only unicast transmission 219 capabilities. Furthermore, the use of multicast CIDs for realizing 220 downlink multicast transmissions is not necessarily preferable due to 221 the reduced transmission efficiency of multicast CIDs for small 222 multicast groups. Appendix A provides more background information 223 about the issues arising with multicast CIDs in IEEE 802.16 systems. 225 MBS (Multicast and Broadcast Service) as specified in IEEE 802.16 226 also does not cover IP broadcast or multicast data because MBS is 227 invisible to the IP layer. 229 4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet 231 IEEE 802.16 provides two solutions to transfer Ethernet frames over 232 IEEE 802.16 MAC connections. 234 The packet CS is defined for handling packet-based protocols by 235 classifying higher-layer packets depending on the values in the 236 packet header fields and assigning the packets to the related service 237 flow. The packet CS comprises multiple protocol specific parts to 238 enable the transmission of different kind of packets over IEEE 239 802.16. The Ethernet specific part of the packet CS supports the 240 transmission of Ethernet by defining classification rules based on 241 Ethernet header information. 243 The GPCS (Generic Packet Convergence Sublayer) may be used as 244 alternative to transfer Ethernet frames over IEEE 802.16. The GPCS 245 does not define classification rules for each kind of payload but 246 relies on higher layer functionality outside of the scope of IEEE 247 802.16 to provide the assignment of packets to particular service 248 flows. 250 5. Ethernet Network Model for IEEE 802.16 252 According to [RFC4861], a link is defined as a communication facility 253 or medium over which IP devices can communicate at the link layer, 254 i.e. the layer immediately below IP. Ethernet fully satisfies the 255 definition of the link. IEEE 802.16, however, has limitations on its 256 transitive connectivity, i.e. IEEE 802.16 provides point-to-point 257 connections between SSs and the BS but does not enable any direct SS 258 to SS connectivity. Hence, it is required to bridge each of the 259 point-to-point connections between SSs and the BS so that Ethernet is 260 realized over IEEE 802.16 access network. 262 5.1. IEEE 802.16 Ethernet Link Model 264 To realize Ethernet on top of IEEE 802.16 all the point-to-point 265 connections belonging to a SS MUST be connected to a network-side 266 bridging function, as shown in Figure 2. This is equivalent to 267 today's switched Ethernet with twisted pair wires or fibres 268 connecting the hosts to a bridge ("Switch"). 270 The network-side bridging function can be realized either by a single 271 centralized network-side bridge or by multiple interconnected 272 bridges, preferable arranged in a hierarchical order. The single 273 centralized network-side bridge allows best control of the 274 broadcasting and forwarding behavior of the Ethernet over IEEE 275 802.16. Appendix B explains the issues of a distributed bridging 276 architecture, when no assumptions about the location of the access 277 router can be made. 279 The BS MUST forward all the Service Flows belonging to one SS to one 280 port of the network-side bridging function. No more than one SS MUST 281 be connected to one port of the network-side bridging function. The 282 separation method for multiple links on the connection between the BS 283 and the network-side bridging function is out of scope for this 284 document. Either Layer 2 transport or Layer 3 tunneling may be used. 286 If the Ethernet over IEEE 802.16 is extended to multiple end stations 287 behind the SS (i.e. SS#4 in the below figure) then the SS SHOULD 288 support bridging according to [802.1D] and its amendment [802.16k], 289 a.k.a. subscriber-side bridge, between all its subscriber side ports 290 and the IEEE 802.16 air link. 292 ------------------------ IP Link -------------------------- 294 [Subscriber Side] [Network Side] [Subscriber Side] 295 | | | | | | 296 ETH ETH ETH ETH ETH ETH 297 | | | | | | 298 | | +---------+---------+ | +-+---+-+ 299 | | | Bridging Function | | |Bridge | 300 | | +--+-+---------+-+--+ | +---+---+ 301 | | | + + | | | 302 +--+--+ +--+--+ +--+-+--+ +--+-+--+ +--+--+ +--+--+ 303 | MAC | | MAC | | MAC | | MAC | | MAC | | MAC | 304 +-----+ +-----+ +-------+ +-------+ +-----+ +-----+ 305 | PHY | | PHY | | PHY | | PHY | | PHY | | PHY | 306 +-+-+-+ +-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+ +-+-+-+ 307 + | | | | + + | | | | + 308 + | +--CID#u-+ | + + | +-CID#x--+ | + 309 + +----CID#v---+ + + +---CID#y----+ + 310 +++++++++++++++CID#w++++++ ++++++CID#z+++++++++++++++ 312 SS#1 SS#2 BS#1 BS#2 SS#3 SS#4 314 Figure 2. IEEE 802.16 Ethernet Link Model 316 5.2. Ethernet without Native Broadcast and Multicast Support 318 Current IEEE 802.16 does not define broadcast and multicast of 319 Ethernet frames. Hence Ethernet broadcast and multicast frames 320 SHOULD be replicated and then carried via unicast transport 321 connections on IEEE 802.16 access link. The network-side bridging 322 function performs the replication and forwarding for Ethernet 323 broadcast and multicast over the IEEE 802.16 radio links 325 5.3. Network-side Bridging Function 327 The network-side bridging function SHOULD create a new radio side 328 port whenever a new SS attaches to any of the BSs of the network or 329 SHOULD remove a radio side port when an associated SS detaches from 330 the BSs. The method for managing the port on the network-side 331 bridging function may depend on the protocol used for establishing 332 multiple links on the connection between the BS and the network-side 333 bridge. The port managing method is out of scope for this document. 335 The network-side bridging function SHALL be based on [802.1D] and its 336 amendment [802.16k] to interconnect the attached SSs and pass 337 Ethernet frames between the point-to-point connections associated 338 with the attached SSs. However, to enhance the IEEE 802.16 Ethernet 339 link model by avoiding broadcast or multicast packet flooding, 340 additional IP specific functionalities MAY be provided by the 341 network-side bridging function in addition to the mandatory functions 342 according to Section 5.1 of [802.1D]. 344 5.4. Segmenting the Ethernet into VLANs 346 It is possible to restrict the size and coverage of the broadcast 347 domain by segmenting the Ethernet over IEEE 802.16 into VLANs and 348 grouping subsets of hosts into particular VLANs with each VLAN 349 representing an IP link. Therefore, the network-side bridging 350 function MAY be enabled to support VLANs according to [802.1Q] by 351 assigning and handling the VLAN-IDs on the virtual bridge ports. 353 If a SS is directly connected to a subscriber-side bridge supporting 354 VLANs, the port associated with such a SS MAY be enabled as trunk 355 port. On trunk ports, Ethernet frames are forwarded in the [802.1Q] 356 frame format. 358 6. Transmission of IP over Ethernet over IEEE 802.16 Link 360 6.1. Generic IP over Ethernet Network Scenario 362 The generic IP over Ethernet network scenario assumes that all hosts 363 are residing on the same link with trust relationship between all of 364 them. It enables the hosts to directly communicate with each other 365 without detouring. There can be multiple Access Routers (ARs) on the 366 link, which may reside both on the subscriber side as well as on the 367 network side as shown in Figure 3. 369 +--+--+ 370 ---|AR|SS| 371 +--+--+* +----+ 372 * +----+ +Host| 373 +----+--+ * | +-------+ /+----+ 374 |Host|SS|* * * * **| BS +------+ \ / +----+ 375 +----+--+ * | +-----+ \ \ / ++Host| 376 +----+--+ * +----+ \ \ +-+--------+ / +----+ 377 |Host|SS|* \ +--+ ++ 378 +----+ +----+--+ +---+Bridging| +----+ 379 --+ AR ++ |Function+---+ AR +--- 380 +----+ \ +--+ | +----+ 381 \ +----+ / +-+--------+ 382 +----+ +------+--+ | +---+ / 383 |Host+-+Bridge|SS|* * * *| BS | / 384 +----+ +------+--+ * | +---+ 385 +----+/ * +----+ 386 |Host+ +----+--+ * 387 +----+ |Host|SS|* 388 +----+--+ 390 Figure 3. Generic IP over Ethernet Network Scenario using IEEE 802.16 392 6.2. Transmission of IP over Ethernet 394 6.2.1. IPv4 over Ethernet Packet Transmission 396 [RFC0894] defines the transmission of IPv4 packets over Ethernet 397 networks. It contains the specification of the encapsulation of the 398 IPv4 packets into Ethernet frames as well as rules for mapping of IP 399 addresses onto Ethernet MAC addresses. Hosts transmitting IPv4 over 400 Ethernet packets over the IEEE 802.16 MUST follow the operations 401 specified in [RFC0894]. 403 6.2.1.1. Address Configuration 405 IPv4 addresses can be configured manually or assigned dynamically 406 from Dynamic Host Configuration Protocol for IPv4 (DHCPv4) server 407 [RFC2131]. 409 6.2.1.2. Address Resolution 411 Address Resolution Protocol (ARP) [RFC0826] MUST be used for finding 412 the destination Ethernet MAC address. 414 6.2.2. IPv6 over Ethernet Packet Transmission 416 [RFC2464] defines transmission of IPv6 Packets over Ethernet Networks 417 which includes an encapsulation of IPv6 packets into Ethernet frames 418 and mapping rules for IPv6 address to Ethernet address (i.e. MAC 419 address). Host transmitting IPv6 over Ethernet packets over the IEEE 420 802.16 MUST follow the operations specified in [RFC2464]. 422 6.2.2.1. Router Discovery, Prefix Discovery and Parameter Discovery 424 Router Discovery, Prefix Discovery and Parameter Discovery procedures 425 are achieved by receiving Router Advertisement messages. However, 426 periodic Router Advertisement messages can waste radio resource and 427 disturb SSs in dormant mode in IEEE 802.16. Therefore, the 428 AdvDefaultLifetime and MaxRtrAdvInterval SHOULD be overridden with 429 high values specified in Section 8.3 in [RFC5121]. 431 6.2.2.2. Address Configuration 433 When stateful address autoconfiguration is required, the stateful 434 address configuration according to [RFC3315] MUST be performed. In 435 this case, an AR supports Dynamic Host Configuration Protocol for 436 IPv6 (DHCPv6) server or relay function. 438 When stateless address autoconfiguration is required, the stateless 439 address configuration according to [RFC4862] and [RFC4861] MUST be 440 performed. 442 6.2.2.3. Address Resolution 444 Neighbor Discovery Protocol (NDP) [RFC4861] MUST be used for 445 determining the destination Ethernet MAC address. 447 6.2.3. Maximum Transmission Unit 449 [RFC2460] mandates 1280 bytes as a minimum Maximum Transmission Unit 450 (MTU) size for link layer and recommends at least 1500 bytes for IPv6 451 over Ethernet transmission. [RFC0894] also specifies 1500 bytes as a 452 maximum length of IPv4 over Ethernet. Therefore, the default MTU of 453 IPv6 packets and IPv4 packets on Ethernet over IEEE 802.16 link MUST 454 be 1500 bytes. 456 6.2.4. Prefix Assignment 458 As the Ethernet over IEEE 802.16 may only build a part of a larger 459 Ethernet of arbitrary structure, any kind of prefix assignment which 460 is feasible for Ethernet is applicable for Ethernet over IEEE 802.16 461 as well. The same IPv4 prefix and the same set of IPv6 prefixes MAY 462 be assigned to all hosts attached to the Ethernet over IEEE 802.16 to 463 make best usage of Ethernet behavior. Sharing the prefix means 464 locating all hosts on the same subnetwork. 466 7. Operational Enhancements for IP over Ethernet over IEEE 802.16 468 This section presents operational enhancements in order to improve 469 network performance and radio resource efficiency for transmission of 470 IP packets over Ethernet over IEEE 802.16 networks. 472 7.1. IP Multicast and Broadcast Packet Processing 474 All multicast and multicast control messages SHOULD be processed in 475 the network-side bridging function according to [RFC4541]. 476 Broadcasting messages to all radio-side side ports SHOULD be 477 prevented. 479 Further information on prevention of multicasting or broadcasting 480 messages to all radio side ports are given in the following sections. 482 7.1.1. Multicast Transmission Considerations 484 Usually, bridges replicate the IP multicast packets and forward them 485 into all of its available ports except the incoming port. As a 486 result, the IP multicast packets would be transmitted over the air 487 even to hosts which has not joined the corresponding multicast group. 488 To allow bridges to handle IP multicast more efficiently, the IP 489 multicast membership information should be propagated between 490 bridges. 492 In the IEEE 802.16 Ethernet link model in Section 5.1, the network- 493 side bridging function SHOULD process all multicast data and 494 multicast control messages according to [RFC4541] to maintain IP 495 multicast membership states and forward IP multicast data to only 496 ports suitable for the multicast group. 498 7.1.2. Broadcast Transmission Considerations 500 The ordinary bridge floods the IP broadcast packets out of all 501 connected ports except the port on which the packet was received. 502 This behavior is not appropriate with scarce resources and dormant- 503 mode hosts in a wireless network such as an IEEE 802.16 based access 504 network. 506 The network-side bridging function in the IEEE 802.16 Ethernet link 507 model SHOULD flood all IP broadcast packets except ARP, DHCPv4 and 508 Internet Group Management Protocol (IGMP) related traffic. 510 IGMP related broadcast packets SHOULD be forwarded according to the 511 [RFC4541]. ARP related broadcast SHOULD be processed as specified in 512 Section 7.3. DHCPv4 related broadcast packets SHOULD be handled as 513 specified in Section 7.2. 515 7.2. DHCP Considerations 517 In the IPv4 over Ethernet case, DHCPv4 clients may send DHCPDISCOVER 518 and DHCPREQUEST messages with the BROADCAST bit set to request the 519 DHCPv4 server to broadcast its DHCPOFFER and DHCPACK messages. The 520 network-side bridging function SHOULD filter these broadcast 521 DHCPOFFER and DHCPACK messages and forwards the broadcast messages 522 only to the host defined by the client hardware address in the chaddr 523 information element. 525 Alternatively, the DHCP Relay Agent Information Option (option-82) 526 [RFC3046] MAY be used to avoid DHCPv4 broadcast replies. The 527 option-82 consists of two type of sub-options; Circuit ID and Remote 528 ID. DHCPv4 Relay Agent is usually located on the network-side 529 bridging function as Layer 2 DHCPv4 Relay Agent. Port number of the 530 network-side bridging function is possible as Circuit ID and Remote 531 ID may be left unspecified. Note that using option-82 requires 532 option-82 aware DHCPv4 servers. 534 In the IPv6 over Ethernet case, DHCPv6 clients use their link-local 535 addresses and the All_DHCP_Relay_Agents_and_Servers multicast address 536 to discover and communicate with DHCPv6 servers or relay agents on 537 their link. Hence, DHCPv6 related packets are unicasted or 538 multicasted. The network-side bridging function SHOULD handle the 539 DHCPv6 related unicast packets based on [802.1D] and SHOULD transmit 540 the DHCPv6 related multicast packets as specified in Section 7.1.1. 542 7.3. Address Resolution Considerations 544 In the IPv4 over Ethernet case, ARP Requests are usually broadcasted 545 to all hosts on the same link in order to resolve an Ethernet MAC 546 address, which would disturb all hosts on the same link. Proxy ARP 547 provides the function in which a device on the same link as the hosts 548 answers ARP Requests instead of the remote host. When transmitting 549 IPv4 packets over the IEEE 802.16 Ethernet link , the Proxy ARP 550 mechanism is used by the network-side bridging function to avoid 551 broadcasting ARP Requests over the air. 553 The network-side bridging function SHOULD maintain an ARP cache large 554 enough to accommodate ARP entries for all its serving SSs. The ARP 555 cache SHOULD be updated by any packets including ARP Requests from 556 SSs in the same way the normal layer-2 bridging device is updating 557 its Filtering Database according to [802.1D]. 559 Upon receiving an ARP Request from a SS, the network-side bridging 560 function SHOULD unicast an ARP Reply back to the SS with the Ethernet 561 address of the target host provided that the target address matches 562 an entry in the ARP Cache. However, in case of receiving an ARP 563 request from a host behind a subscriber-side bridge, the network-side 564 bridging function SHOULD discard the request if the target host is 565 also behind the same subscriber-side bridge, i.e., on the same port 566 of the network-side bridge. Otherwise, the ARP Request MAY be 567 flooded. The network-side bridging function SHOULD silently discard 568 any received self-ARP Request. 570 In the IPv6 over Ethernet case, Neighbor Solicitation messages are 571 multicasted to the solicited-node multicast address for the address 572 resolution including a duplicate address detection. The solicited- 573 node multicast address facilitates the efficient querying of hosts 574 without disturbing all hosts on the same link. The network-side 575 bridging function SHOULD transmit the Neighbor Solicitation messages 576 specified in Section 7.1.1. 578 8. Public Access Recommendations 580 In the Public Access scenario, direct communication between nodes is 581 restricted because of security and accounting issues. Figure 4 582 depicts the public access scenario. 584 In the scenario, the AR is connected to a network-side bridge. The 585 AR MAY perform security filtering, policing and accounting of all 586 traffic from hosts, e.g. like a NAS (Network Access Server). 588 If the AR functions as the NAS, all the traffic from SSs SHOULD be 589 forwarded to the AR, not bridged at the network-side bridging 590 function, even in the case of traffic between SSs served by the same 591 AR. The bridge SHOULD forward upstream traffic from hosts toward the 592 AR but SHALL perform normal bridging operation for downstream traffic 593 from the AR and SHALL bridge SEcure Neighbor Discovery (SEND) 594 [RFC3971] messages to allow applicability of security schemes. 596 In IPv4 over Ethernet case, MAC-Forced Forwarding (MAC-FF) [RFC4562] 597 SHOULD be used for the public access network to ensure that traffic 598 from all hosts is always directed to the AR. The MAC-FF is performed 599 in the network-side bridging function, thus the bridge filters 600 broadcast ARP Requests from all the hosts and responds to the ARP 601 Requests with an Ethernet MAC address of the AR. 603 In IPv6 over Ethernet case, unique IPv6 prefix per SS can be assigned 604 because it forces all IPv6 packets from SSs to be transferred to the 605 AR and thus it results in layer 3 separation between SSs. 607 Alternatively, common IPv6 prefixes can be assigned to all SSs served 608 by the same AR in order to exploit the efficient multicast support of 609 Ethernet link in the network side. In the latter case, a Prefix 610 Information Option (PIO) [RFC4861] carrying the common IPv6 prefixes 611 SHOULD be advertised with On-link flag (L-Flag) reset so that it is 612 not assumed that the addresses matching the prefixes are available 613 on-link. 615 The AR should relay packets between SSs within the same AR. 617 +-+--+ 618 |H|SS| +- - - - - - - - - - + 619 +-+--+* +----+ | +------+ 620 +-+--+ * | +-----+ | | 621 |H|SS|* * * * * *| BS +-----+Bridge+-+ 622 +-+--+ * | +-----+ | | +-----+ | 623 * +----+ | +------+ | | B | 624 +-+--+ * | +-+ r | | +-------+ 625 |H|SS|* | i +---+AR(NAS)+-- 626 +---+ +-+--+ | | d | | +-------+ 627 | H ++ +-+ g | 628 +---+ \ +----+ | +------+ | | e | | 629 +---+ +--+--+ | +----+ | | +-----+ 630 | H +--+Br|SS|* * * * | BS | | |Bridge+-+ | 631 +---+ +--+--+ * | +----+ | 632 +---+ / * +----+ | +------+ | 633 | H ++ +-+--+ * 634 +---+ |H|SS|* | Bridging Function | 635 +-+--+ +- - - - - - - - - - + 637 Figure 4. Public Access Network using IEEE 802.16 639 9. IANA Considerations 641 This document has no actions for IANA. 643 10. Security Considerations 645 This recommendation does not introduce new vulnerabilities to IPv4 646 and IPv6 specifications or operations. The security of the IEEE 647 802.16 air interface between SSs and BS is the subject of [802.16], 648 which provides the capabilities of admission control and ciphering of 649 the traffic carried over the air interface. A Traffic Encryption Key 650 (TEK) is generated by the SS and BS on completion of successful 651 mutual authentication and is used to secure the air interface. 653 The IEEE 802.16 Ethernet link model described in Section 5.1 654 represents a bridged (switched) Ethernet architecture with point-to- 655 point links between the SS and its bridge port. Even though the 656 bridged Ethernet model prevents uncontrolled messaging between SSs on 657 the same link, it is still vulnerable, e.g. by malicious 658 reconfiguration of the address table of the bridge in the learning 659 process. This recommendation does not cause new security issues 660 beyond those, which are known for the bridged Ethernet architecture. 661 E.g. link security mechanisms according to [802.1AE] can be used on 662 top of this recommendation to resolve the security issues of the 663 bridged Ethernet. 665 As the generic IP over Ethernet network using IEEE 802.16 emulates a 666 standard Ethernet link, existing IPv4 and IPv6 security mechanisms 667 over Ethernet can still be used. The public access network using 668 IEEE 802.16 ensures secure isolation of each of the upstream links 669 between hosts and AR by adopting SEcure Neighbor Discovery (SEND) 670 [RFC3971] for securing neighbor discovery processes. 672 11. Acknowledgments 674 The authors would like to thank David Johnston, Dave Thaler, Jari 675 Arkko and others for their inputs to this work. 677 12. References 679 12.1. Normative References 681 [802.16] IEEE Std 802.16-2009, "IEEE Standard for Local and 682 metropolitan area networks, Part 16: Air Interface for 683 Fixed Broadband Wireless Access Systems", May 2009. 685 [802.16k] IEEE Std 802.16k-2007, "IEEE Standard for Local and 686 metropolitan area networks, Media Access Control (MAC) 687 Bridges, Amendment 5: Bridging of IEEE 802.16", 688 March 2007. 690 [802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and 691 metropolitan area networks, Media Access Control (MAC) 692 Bridges", June 2004. 694 [802.1Q] IEEE Std 802.1Q-2005, "IEEE Standard for Local and 695 metropolitan area networks, Virtual Bridged Local Area 696 Networks", May 2005. 698 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 699 converting network protocol addresses to 48.bit Ethernet 700 address for transmission on Ethernet hardware", STD 37, 701 RFC 826, November 1982. 703 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 704 over Ethernet networks", STD 41, RFC 894, April 1984. 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, March 1997. 709 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 710 RFC 2131, March 1997. 712 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 713 (IPv6) Specification", RFC 2460, December 1998. 715 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 716 Networks", RFC 2464, December 1998. 718 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 719 and M. Carney, "Dynamic Host Configuration Protocol for 720 IPv6 (DHCPv6)", RFC 3315, July 2003. 722 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 723 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 724 September 2007. 726 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 727 Address Autoconfiguration", RFC 4862, September 2007. 729 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 730 Madanapalli, "Transmission of IPv6 via the IPv6 731 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 732 February 2008. 734 12.2. Informative References 736 [802.1AE] IEEE Std 802.1AE-2006, "IEEE Standard for Local and 737 metropolitan area networks Media Access Control (MAC) 738 Security", August 2006. 740 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 741 RFC 3046, January 2001. 743 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 744 Neighbor Discovery (SEND)", RFC 3971, March 2005. 746 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 747 "Considerations for Internet Group Management Protocol 748 (IGMP) and Multicast Listener Discovery (MLD) Snooping 749 Switches", RFC 4541, May 2006. 751 [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method 752 for Subscriber Separation on an Ethernet Access Network", 753 RFC 4562, June 2006. 755 [RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE 756 802.16 Problem Statement and Goals", RFC 5154, April 2008. 758 Appendix A. Multicast CID Deployment Considerations 760 Multicast CIDs are highly efficient means to distribute the same 761 information concurrently to multiple SSs under the same BS. However, 762 the deployment of multicast CIDs for multicast or broadcast data 763 services suffers from following drawbacks. 765 A drawback of multicast CIDs for Ethernet over IEEE 802.16 is the 766 unidirectional nature of multicast CIDs. While it is possible to 767 multicast information downstream to a number of SSs in parallel, 768 there are no upstream multicast connections. In upstream direction, 769 unicast CIDs have to be used for sending multicast messages over the 770 air to the BS requiring a special multicast forwarding function for 771 sending the information back to the other SSs on a multicast CID. 772 While similar in nature to a bridging function, there is no 773 appropriate forwarding model available. [802.1D] cannot take 774 advantage of the multicast CIDs because it relies on unicast 775 connections or bidirectional broadcast connections. 777 A further drawback of deploying multicast CIDs for distributing 778 broadcast control messages like ARP requests is the inability to 779 prevent the wake-up of dormant-mode SSs by messages not aimed for 780 them. Whenever a message is sent over a multicast CID, all 781 associated stations have to power up and receive and process the 782 message. While this behavior is desirable for multicast and 783 broadcast traffic, it is harmful for link layer broadcast control 784 messages aimed for a single SS, like an ARP Request. All other SSs 785 are wasting scarce battery power for receiving, decoding and 786 discarding the message. Low power consumption is an extremely 787 important aspect in a wireless communication. 789 Furthermore, it should keep in mind that multicast CIDs are only 790 efficient for a large number of subscribed SSs in a cell. Due to 791 incompatibility with advanced radio layer algorithms based on 792 feedback information from the receiver side, multicast connections 793 require much more radio resource for transferring the same 794 information as unicast connections. 796 Appendix B. Centralized vs. Distributed Bridging 798 This specification introduces a network-side bridging function, which 799 can be realized either by a centralized device or by multiple 800 interconnected bridges in a distributed manner. One common 801 implementation of the distributed model is the scenario where a 802 bridge is directly attached to the BS, such that the interface 803 between BS and bridging function is becoming a software interface 804 within the operation system of the BS/Bridge device. 806 The operational enhancements described in Section 7 of this document 807 are based on the availability of additional information about all the 808 hosts attached to the Ethernet. Flooding all ports of the bridge can 809 be avoided when a-priori information is available to determine the 810 port to which an Ethernet frame has to be delivered. 812 Best performance can be reached by a centralized database containing 813 all information about the hosts attached to the Ethernet. A 814 centralized database can be established either by a centralized 815 bridge device or by a hierarchical bridging structure with dedicated 816 uplink and downlink ports like in the public access case, where the 817 uppermost bridge is able to retrieve and maintain all the 818 information. 820 As the generic case of the IP over Ethernet over IEEE 802.16 link 821 model does not make any assumption of the location of the AR (an AR 822 may eventually be attached to a SS), a centralized bridging system is 823 recommended for the generic case. In the centralized system, every 824 connection over the air of a link should be attached to a single 825 centralized bridge. 827 A distributed bridging model is in particular appropriate for the 828 public access mode, where Ethernet frames, which do not have entries 829 in the bridge behind the BS, are send upstream to a bridge finally 830 having an entry for the destination MAC address. 832 Authors' Addresses 834 Hongseok Jeon 835 Electronics Telecommunications Research Institute 836 161 Gajeong-dong, Yuseong-gu 837 Daejeon, 305-350 838 KOREA 840 Phone: +82-42-860-3892 841 Email: hongseok.jeon@gmail.com 843 Max Riegel 844 Nokia Siemens Networks 845 St-Martin-Str 76 846 Munich, 81541 847 Germany 849 Phone: +49-89-636-75194 850 Email: maximilian.riegel@nsn.com 852 Sangjin Jeong 853 Electronics Telecommunications Research Institute 854 161 Gajeong-dong, Yuseong-gu 855 Daejeon, 305-350 856 KOREA 858 Phone: +82-42-860-1877 859 Email: sjjeong@etri.re.kr