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