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