[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 07 08 09 10 11 12 rfc5692                                     
Network Working Group                                            H. Jeon
Internet-Draft                                                      ETRI
Intended status: Standards Track                               M. Riegel
Expires: May 22, 2009                                                NSN
                                                                S. Jeong
                                                                    ETRI
                                                       November 18, 2008


       Transmission of IP over Ethernet over IEEE 802.16 Networks
        draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-07.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 22, 2009.

Abstract

   This document describes the transmission of IPv4 over Ethernet as
   well as IPv6 over Ethernet in an access network deploying the IEEE
   802.16 cellular radio transmission technology.  The Ethernet on top
   of IEEE 802.16 is realized by bridging connections which the IEEE
   802.16 provides between a base station and its associated subscriber
   stations.  Due to the resource constraints of radio transmission
   systems and the limitations of the IEEE 802.16 MAC functionality for
   the realization of an Ethernet, the transmission of IP over Ethernet
   over IEEE 802.16 may considerably benefit by adding IP specific



Jeon, et al.              Expires May 22, 2009                  [Page 1]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   support functions in the Ethernet over IEEE 802.16 while maintaining
   full compatibility with standard IP over Ethernet behavior.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . .  3
     4.1.  Connection Oriented Air Interface  . . . . . . . . . . . .  3
     4.2.  MAC addressing in IEEE 802.16  . . . . . . . . . . . . . .  4
     4.3.  Unidirectional Broadcast and Multicast Support . . . . . .  5
     4.4.  IEEE 802.16 Convergence Sublayer for IP over Ethernet  . .  5
   5.  Ethernet Network Model for IEEE 802.16 . . . . . . . . . . . .  5
     5.1.  IEEE 802.16 Ethernet Link Model  . . . . . . . . . . . . .  6
     5.2.  Ethernet without Native Broadcast and Multicast Support  .  7
     5.3.  Network-side Bridging Function . . . . . . . . . . . . . .  7
     5.4.  Segmenting the Ethernet into VLAN  . . . . . . . . . . . .  8
   6.  Transmission of IP over Ethernet over IEEE 802.16 Link . . . .  8
     6.1.  Generic IP over Ethernet Network Scenario  . . . . . . . .  8
     6.2.  Transmission of IP over Ethernet . . . . . . . . . . . . .  9
       6.2.1.  IPv4 over Ethernet Packet Transmission . . . . . . . .  9
       6.2.2.  IPv6 over Ethernet Packet Transmission . . . . . . . .  9
       6.2.3.  Maximum Transmission Unit  . . . . . . . . . . . . . . 10
       6.2.4.  Prefix Assignment  . . . . . . . . . . . . . . . . . . 10
   7.  Operational Enhancements for IP over Ethernet over IEEE
       802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  IP Multicast and Broadcast Packet Processing . . . . . . . 11
       7.1.1.  Multicast Transmission Considerations  . . . . . . . . 11
       7.1.2.  Broadcast Transmission Considerations  . . . . . . . . 11
     7.2.  DHCPv4 Considerations  . . . . . . . . . . . . . . . . . . 12
     7.3.  Proxy ARP  . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Public Access Recommendations  . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     12.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Multicast CID Deployment Considerations . . . . . . . 16
   Appendix B.  Centralized vs. Distributed Bridging  . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20







Jeon, et al.              Expires May 22, 2009                  [Page 2]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


1.  Introduction

   IEEE 802.16 [802.16] specifies a fixed to mobile broadband wireless
   access system.

   The IEEE 802.16 standard defines a packet CS (Convergence Sublayer)
   for interfacing with specific packet-based protocols as well as a
   generic packet CS (GPCS) to provide an upper-layer protocol
   independent interface.  This document describes transmission of IPv4
   and IPv6 over Ethernet via the Ethernet specific part of the packet
   CS as well as the GPCS in the IEEE 802.16 based access network.

   Ethernet is a widely deployed transmission technology.  It provides
   unicast transport, handles broadcast and multicast traffic
   efficiently, and provides rich services such as Virtual LANs.
   However, Ethernet has been originally architected and designed for a
   shared medium while the IEEE 802.16 uses a point-to-multipoint
   architecture like other cellular radio transmission systems.  Hence,
   Ethernet on top of IEEE 802.16 is realized by bridging between IEEE
   802.16 radio connections between a BS (Base Station) and its
   associated SSs (Subscriber Stations).

   Under the resource constraints of radio transmission systems and the
   particularities of the IEEE 802.16 for the realization of Ethernet,
   it makes sense to add IP specific support functions in the Ethernet
   layer above IEEE 802.16 while maintaining full compatibility with
   standard IP over Ethernet behavior.


2.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Terminology

   The terminology in this document is based on the definitions in IP
   over 802.16 Problem Statement and Goals [RFC5154].


4.  The IEEE 802.16 Link Model

4.1.  Connection Oriented Air Interface

   The IEEE 802.16 MAC establishes connections between a BS and its
   associated SSs for the transfer of user data over the air.  Each of



Jeon, et al.              Expires May 22, 2009                  [Page 3]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   these connections realizes an individual Service Flow which is
   identified by a 16-bit CID number and has a defined QoS profile.

   Multiple connections can be established between a BS and a SS, each
   with its particular QoS class and direction.  Although the BS and all
   the SSs are associated with unique 48-bit MAC addresses, packets
   going over the air are only identified in the IEEE 802.16 MAC header
   by the CID number of the particular connection.  The connections are
   established by MAC management messages between the BS and the SS
   during network entry or also later on demand.

             [Subscriber  Side]              [Network Side]

             |                |                  |   +
             |                |                  |   +
          +--+--+          +--+--+            +--+-+-+--+
          | MAC |          | MAC |            |   MAC   |
          +-----+          +-----+            +---------+
          | PHY |          | PHY |            |   PHY   |
          +-+-+-+          +-+-+-+            +-+-+-+-+-+
            + +              | |                | | + +
            + +              | +-----CID#w------+ | + +
            + +              +-------CID#x--------+ + +
            + +++++++++++++++++CID#y+++++++++++++++++ +
            +++++++++++++++++++CID#z+++++++++++++++++++
            SS#1             SS#2                 BS

                  Figure 1. Basic IEEE 802.16 Link Model

4.2.  MAC addressing in IEEE 802.16

   Each SS has a unique 48-bit MAC address and the 48-bit MAC address is
   used during the initial ranging process for the identification of the
   SS and may be verified by the succeeding PKM (Privacy Key Management)
   authentication phase.  Out of the successful authentication, the BS
   establishes and maintains the list of attached SSs based on their MAC
   addresses purely for MAC management purposes.

   While MAC addresses are assigned to all the BSs as well as the SSs,
   the forwarding of packets over the air is only based on the CID value
   of the particular connection in the IEEE 802.16 MAC header.  Not
   relying on the MAC addresses in the payload for reception of a radio
   frame allows for the transport of arbitrary source and destination
   MAC addresses in Ethernet frames between a SS and its BS.  This is
   required for bridging Ethernet frames toward a SS which is attached
   to a bridge connected to another network.

   Due to the managed assignment of the service flows and associated CID



Jeon, et al.              Expires May 22, 2009                  [Page 4]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   values to individual SSs, the BS is able to bundle all unicast
   connections belonging to a particular SS into a single link on the
   network side as shown in Figure 1 so that it provides a single layer
   2 link between the SS and its associated wired link on the network
   side.

4.3.  Unidirectional Broadcast and Multicast Support

   Current IEEE 802.16 [802.16] does not support bi-directional native
   broadcast and multicast for IP packets.  While downlink connections
   can be used for multicast transmission to a group of SSs as well as
   unicast transmission from the BS to a single SS, uplink connections
   from the SSs to the BS provide only unicast transmission
   capabilities.  Furthermore, the use of multicast CIDs for realizing
   downlink multicast transmissions is not necessarily preferable due to
   the reduced transmission efficiency of multicast CIDs for small
   multicast groups.  Appendix A provides more background information
   about the issues arising with multicast CIDs in IEEE 802.16 systems.

   MBS (Multicast and Broadcast Service as specified in IEEE 802.16 also
   does not cover IP broadcast or multicast data because MBS is
   invisible to the IP layer.

4.4.  IEEE 802.16 Convergence Sublayer for IP over Ethernet

   IEEE 802.16 provides two solutions to transfer Ethernet frames over
   IEEE 802.16 MAC connections.

   The packet CS is defined for handling packet-based protocols by
   classifying higher-layer packets depending on the values in the
   packet header fields and assigning the packets to the related service
   flow.  The packet CS comprises multiple protocol specific parts to
   enable the transmission of different kind of packets over IEEE
   802.16.  The Ethernet specific part of the packet CS supports the
   transmission of Ethernet by defining classification rules based on
   Ethernet header information.

   The GPCS (Generic Packet Convergence Sublayer) may be used as
   alternative to transfer Ethernet frames over IEEE 802.16.  The GPCS
   does not define classification rules for each kind of payload but
   relies on higher layer functionality outside of the scope of IEEE
   802.16 to provide the assignment of packets to particular service
   flows.


5.  Ethernet Network Model for IEEE 802.16

   According to [RFC4861], a link is defined as a communication facility



Jeon, et al.              Expires May 22, 2009                  [Page 5]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   or medium over which IP devices can communicate at the link layer,
   i.e. the layer immediately below IP.  Ethernet fully satisfies the
   definition of the link.  IEEE 802.16, however, has limitations on its
   transitive connectivity, i.e.  IEEE 802.16 provides point-to-point
   connections between SSs and the BS but does not enable any direct SS
   to SS connectivity.  Hence, it is required to bridge each of the
   point-to-point connections between SSs and the BS so that Ethernet is
   realized over IEEE 802.16 access network.

5.1.  IEEE 802.16 Ethernet Link Model

   To realize Ethernet on top of IEEE 802.16 all the point-to-point
   connections belonging to a SS MUST be connected to a network-side
   bridging function, as shown in Figure 2.  This is equivalent to
   today's switched Ethernet with twisted pair wires or fibres
   connecting the hosts to a bridge ("Switch").

   The network-side bridging function can be realized either by a single
   centralized network-side bridge or by multiple interconnected
   bridges, preferable arranged in a hierarchical order.  The single
   centralized network-side bridge allows best control of the
   broadcasting and forwarding behavior of the Ethernet over IEEE
   802.16.  Appendix B explains the issues of a distributed bridging
   architecture, when no assumptions about the location of the access
   router can be made.

   The BS MUST forward all the Service Flows belonging to one SS to one
   port of the network-side bridging function.  No more than one SS MUST
   be connected to one port of the network-side bridging function.  The
   separation method for multiple links on the connection between the BS
   and the network-side bridging function is out of scope for this
   document.  Either Layer 2 transport or Layer 3 tunneling may be used.

   If the Ethernet over IEEE 802.16 is extended to multiple end stations
   behind the SS (i.e.  SS#4 in the below figure) then the SS SHOULD
   support bridging according to [802.1D] and its amendment [802.16k],
   a.k.a. subscriber-side bridge, between all its subscriber side ports
   and the IEEE 802.16 air link.













Jeon, et al.              Expires May 22, 2009                  [Page 6]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


          ------------------------ IP Link --------------------------

        [Subscriber Side]       [Network Side]        [Subscriber Side]
          |         |                 |                 |       |   |
         ETH       ETH               ETH               ETH     ETH ETH
          |         |                 |                 |       |   |
          |         |       +---------+---------+       |     +-+---+-+
          |         |       | Bridging Function |       |     |Bridge |
          |         |       +--+-+---------+-+--+       |     +---+---+
          |         |          | +         + |          |         |
       +--+--+   +--+--+    +--+-+--+   +--+-+--+    +--+--+   +--+--+
       | MAC |   | MAC |    |  MAC  |   |  MAC  |    | MAC |   | MAC |
       +-----+   +-----+    +-------+   +-------+    +-----+   +-----+
       | PHY |   | PHY |    |  PHY  |   |  PHY  |    | PHY |   | PHY |
       +-+-+-+   +-+-+-+    +-+-+-+-+   +-+-+-+-+    +-+-+-+   +-+-+-+
         +         | |        | | +       + | |        | |         +
         +         | +--CID#u-+ | +       + | +-CID#x--+ |         +
         +         +----CID#v---+ +       + +---CID#y----+         +
         +++++++++++++++CID#w++++++       ++++++CID#z+++++++++++++++

         SS#1      SS#2       BS#1         BS#2       SS#3      SS#4


                 Figure 2. IEEE 802.16 Ethernet Link Model

5.2.  Ethernet without Native Broadcast and Multicast Support

   Current IEEE 802.16 does not define broadcast and multicast of
   Ethernet frames.  Hence Ethernet broadcast and multicast frames
   SHOULD be replicated and then carried via unicast transport
   connections on IEEE 802.16 access link.  The network-side bridging
   function performs the replication and forwarding for Ethernet
   broadcast and multicast over the IEEE 802.16 radio links

5.3.  Network-side Bridging Function

   The network-side bridging function SHOULD create a new radio side
   port whenever a new SS attaches to any of the BSs of the network or
   SHOULD remove a radio side port when an associated SS detaches from
   the BSs.  The method for managing the port on the network-side
   bridging function may depend on the protocol used for establishing
   multiple links on the connection between the BS and the network-side
   bridge.  The port managing method is out of scope for this document.

   The network-side bridging function SHALL be based on [802.1D] and its
   amendment [802.16k] to interconnect the attached SSs and pass
   Ethernet frames between the point-to-point connections associated
   with the attached SSs.  However, to enhance the IEEE 802.16 Ethernet



Jeon, et al.              Expires May 22, 2009                  [Page 7]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   link model by avoiding broadcast or multicast packet flooding,
   additional IP specific functionalities MAY be provided by the
   network-side bridging function in addition to the mandatory functions
   according to Section 5.1 of [802.1D].

5.4.  Segmenting the Ethernet into VLAN

   It is possible to restrict the size and coverage of the broadcast
   domain by segmenting the Ethernet over IEEE 802.16 into VLANs and
   grouping subsets of hosts into particular VLANs with each VLAN
   representing an IP link.  Therefore, the network-side bridging
   function MAY be enabled to support VLANs according to [802.1Q] by
   assigning and handling the VLAN-IDs on the virtual bridge ports.

   If a SS is directly connected to a subscriber-side bridge supporting
   VLANs, the port associated with such a SS MAY be enabled as trunk
   port.  On trunk ports, Ethernet frames are forwarded in the [802.1Q]
   frame format.


6.  Transmission of IP over Ethernet over IEEE 802.16 Link

6.1.  Generic IP over Ethernet Network Scenario

   The generic IP over Ethernet network scenario assumes that all hosts
   are residing on the same link with trust relationship between all of
   them.  It enables the hosts to directly communicate with each other
   without detouring.  There can be multiple ARs on the link, which may
   reside both on the subscriber side as well as on the network side as
   shown in Figure 3.





















Jeon, et al.              Expires May 22, 2009                  [Page 8]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


                   +--+--+
                ---|AR|SS|
                   +--+--+*                                    +----+
                            *   +----+                         +Host|
             +----+--+        * |    +-------+                /+----+
             |Host|SS|* * * * **| BS +------+ \              / +----+
             +----+--+        * |    +-----+ \ \            / ++Host|
                 +----+--+  *   +----+      \ \ +-+--------+ / +----+
                 |Host|SS|*                  \ +--+        ++
         +----+  +----+--+                    +---+Bridging|   +----+
       --+ AR ++                                  |Function+---+ AR +---
         +----+ \                              +--+        |   +----+
                 \                  +----+    / +-+--------+
           +----+ +------+--+       |    +---+ /
           |Host+-+Bridge|SS|* * * *| BS |    /
           +----+ +------+--+    *  |    +---+
           +----+/             *    +----+
           |Host+ +----+--+  *
           +----+ |Host|SS|*
                  +----+--+

   Figure 3. Generic IP over Ethernet Network Scenario using IEEE 802.16

6.2.  Transmission of IP over Ethernet

6.2.1.  IPv4 over Ethernet Packet Transmission

   [RFC0894] defines the transmission of IPv4 packets over Ethernet
   networks.  It contains the specification of the encapsulation of the
   IPv4 packets into Ethernet frames as well as rules for mapping of IP
   addresses onto Ethernet MAC addresses.  Hosts transmitting IPv4 over
   Ethernet packets over the IEEE 802.16 MUST follow the operations
   specified in [RFC0894].

6.2.1.1.  Address Configuration

   IPv4 addresses can be configured manually or assigned dynamically
   from DHCPv4 server [RFC2131].

6.2.1.2.  Address Resolution

   Address Resolution Protocol (ARP) [RFC0826] MUST be used for finding
   the destination Ethernet MAC address.

6.2.2.  IPv6 over Ethernet Packet Transmission

   [RFC2464] defines transmission of IPv6 Packets over Ethernet Networks
   which includes an encapsulation of IPv6 packets into Ethernet frames



Jeon, et al.              Expires May 22, 2009                  [Page 9]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   and mapping rules for IPv6 address to Ethernet address (i.e.  MAC
   address).  Host transmitting IPv6 over Ethernet packets over the IEEE
   802.16 MUST follow the operations specified in [RFC2464].

6.2.2.1.  Router Discovery, Prefix Discovery and Parameter Discovery

   Router Discovery, Prefix Discovery and Parameter Discovery procedures
   are achieved by receiving Router Advertisement messages.  However,
   periodic Router Advertisement messages can waste radio resource and
   disturb SSs in dormant mode in IEEE 802.16.  Therefore, the
   AdvDefaultLifetime and MaxRtrAdvInterval SHOULD be overridden with
   high values specified in Section 8.3 in [RFC5121].

6.2.2.2.  Address Configuration

   When stateful address autoconfiguration is required, the stateful
   address configuration according to [RFC3315] MUST be performed.  In
   this case, an AR supports DHCP server or relay function.

   When stateless address autoconfiguration is required, the stateless
   address configuration according to [RFC4862] and [RFC4861] MUST be
   performed.

6.2.2.3.  Address Resolution

   Neighbor Discovery Protocol (NDP) [RFC4861] MUST be used for
   determining the destination Ethernet MAC address.

6.2.3.  Maximum Transmission Unit

   [RFC2460] mandates 1280 bytes as a minimum Maximum Transmission Unit
   (MTU) size for link layer and recommends at least 1500 bytes for IPv6
   over Ethernet transmission.  [RFC0894] also specifies 1500 bytes as a
   maximum length of IPv4 over Ethernet.  Therefore, the default MTU of
   IPv6 packets and IPv4 packets on Ethernet over IEEE 802.16 link MUST
   be 1500 bytes.

6.2.4.  Prefix Assignment

   The same IPv4 prefix and the same set of IPv6 prefixes SHOULD be
   assigned to all hosts attached to the Ethernet over IEEE 802.16.
   Sharing the prefix means locating all hosts on the same subnetwork.


7.  Operational Enhancements for IP over Ethernet over IEEE 802.16

   This section presents operational enhancements in order to improve
   network performance and radio resource efficiency for transmission of



Jeon, et al.              Expires May 22, 2009                 [Page 10]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   IP packets over Ethernet over IEEE 802.16 networks.

7.1.  IP Multicast and Broadcast Packet Processing

   All multicast and multicast control messages SHOULD be processed in
   the network-side bridging function according to [RFC4541].
   Broadcasting messages to all radio-side side ports SHOULD be
   prevented.

   Further information on prevention of multicasting or broadcasting
   messages to all radio side ports are given in the following sections.

7.1.1.  Multicast Transmission Considerations

   Usually, bridges replicate the IP multicast packets and forward them
   into all of its available ports with the exception of the incoming
   port.  As a result, the IP multicast packets would be transmitted
   over the air even to hosts which do not participate in the
   corresponding multicast group.  To allow bridges to handle IP
   multicast more efficiently, the IP multicast membership should be
   propagated between bridges.

   In the IEEE 802.16 Ethernet link model in Section 5.1, the network-
   side bridging function SHOULD process all multicast data and
   multicast control messages according to [RFC4541] to maintain IP
   multicast membership lists and forward IP multicast data to only
   ports suitable for the multicast group.

7.1.2.  Broadcast Transmission Considerations

   The ordinary bridge floods the IP broadcast packets out of all
   connected ports except the port on which the packet was received.
   This behavior is not appropriate with scarce resources and dormant-
   mode hosts in a wireless network such as an IEEE 802.16 based access
   network.

   The network-side bridging function in the IEEE 802.16 Ethernet link
   model SHOULD flood all IP broadcast packets except ARP, DHCPv4 and
   IGMP related traffic.

   IGMP related broadcast packets SHOULD be forwarded according to the
   [RFC4541].  ARP related broadcast SHOULD be processed as specified in
   Section 7.3.  DHCPv4 related broadcast packets SHOULD be handled as
   specified in Section 7.2.







Jeon, et al.              Expires May 22, 2009                 [Page 11]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


7.2.  DHCPv4 Considerations

   DHCPv4 clients may send DHCP DISCOVER and DHCP REQUEST messages with
   the BROADCAST bit set to request the DHCP server to broadcast its
   DHCP OFFER and DHCP ACK messages.  The network-side bridging function
   SHOULD filter these broadcast DHCP OFFER and DHCP ACK messages and
   forwards the broadcast messages only to the host defined by the
   client hardware address in the chaddr information element.

   Alternatively, the DHCP Relay Agent Information Option (option-82)
   [RFC3046] MAY be used to avoid DHCP broadcast replies.  The option-82
   consists of two type of sub-options; Circuit ID and Remote ID.  DHCP
   Relay Agent is usually located on the network-side bridging function
   as Layer 2 DHCP Relay Agent, like described in [TR101].  Port number
   of the network-side bridging function is possible as Circuit ID and
   Remote ID may be left unspecified.  Note that using option-82
   requires option-82 aware DHCP servers. function SHOULD silently
   discard any received self-ARP Requests.

7.3.  Proxy ARP

   Proxy ARP provides the function in which a device on the same link as
   the hosts answers ARP Requests instead of the remote host.  When
   transmitting IPv4 packets over the IEEE 802.16 Ethernet link , the
   Proxy ARP mechanism is used by the network-side bridging function to
   avoid broadcasting ARP Requests over the air.

   The network-side bridging function SHOULD maintain an ARP cache large
   enough to accommodate ARP entries for all its serving SSs.  The ARP
   cache SHOULD be updated by any packets including ARP Requests from
   SSs in the same way the normal layer-2 bridging device is updating
   its Filtering Database according to [802.1D].

   Upon receiving an ARP Request from a SS, the network-side bridging
   function SHOULD unicast an ARP Reply back to the SS with the Ethernet
   address of the target host provided that the target address matches
   an entry in the ARP Cache.  Otherwise, the ARP Request MAY be
   flooded.  The network-side bridging function SHOULD silently discard
   any received self-ARP Request.


8.  Public Access Recommendations

   In the Public Access scenario, direct communication between nodes is
   restricted because of security and accounting issues.  Figure 4
   depicts the public access scenario.

   In the scenario, the AR is connected to a network-side bridge.  The



Jeon, et al.              Expires May 22, 2009                 [Page 12]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   AR MAY perform security filtering, policing and accounting of all
   traffic from hosts, e.g. like a NAS (Network Access Server).

   If the AR functions as the NAS, all the traffic from SSs SHOULD be
   forwarded to the AR, not bridged at the network-side bridging
   function, even in the case of traffic between SSs served by the same
   AR.  The bridge SHOULD forward upstream traffic from hosts toward the
   AR but SHALL perform normal bridging operation for downstream traffic
   from the AR and SHALL bridge SEcure Neighbor Discovery (SEND)
   [RFC3971] messages to allow applicability of security schemes.

   In IPv4 over Ethernet case, MAC-Forced Forwarding (MAC-FF) [RFC4562]
   SHOULD be used for the public access network to ensure that traffic
   from all hosts is always directed to the AR.  The MAC-FF is performed
   in the network-side bridging function, thus the bridge filters
   broadcast ARP Requests from all the hosts and responds to the ARP
   Requests with an Ethernet MAC address of the AR.

   In IPv6 over Ethernet case, assigning unique IPv6 prefix per SS can
   forces all IPv6 packets from SSs to be transferred to the AR.
   However, this leads the AR to replicate multicast packets on each
   virtually separated IP links to hosts joined to a corresponding
   multicast group.  It cannot exploit the efficient multicast support
   of Ethernet link in the network side.  Therefore, the AR in the
   public access link model SHOULD assign common IPv6 prefixes to all
   SSs served by the AR.  A Prefix Information Option (PIO) [RFC4861]
   carrying the common IPv6 prefixes SHOULD be advertised with On-link
   flag (L-Flag) reset so that it is not assumed that the addresses
   matching the prefixes are available on-link.

   The AR should relay packets between SSs within the same AR.




















Jeon, et al.              Expires May 22, 2009                 [Page 13]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


               +-+--+
               |H|SS|              +- - - - - - - - - - +
               +-+--+*    +----+   | +------+
         +-+--+        *  |    +-----+      |           |
         |H|SS|* * * * * *| BS +-----+Bridge+-+
         +-+--+        *  |    +-----+      | | +-----+ |
                      *   +----+   | +------+ | |  B  |
              +-+--+ *             |          +-+  r  | | +-------+
              |H|SS|*                           |  i  +---+AR(NAS)+--
     +---+    +-+--+               |            |  d  | | +-------+
     | H ++                                   +-+  g  |
     +---+ \               +----+  | +------+ | |  e  | |
     +---+  +--+--+        |    +----+      | | +-----+
     | H +--+Br|SS|* * * * | BS |  | |Bridge+-+         |
     +---+  +--+--+     *  |    +----+      |
     +---+ /           *   +----+  | +------+           |
     | H ++    +-+--+ *
     +---+     |H|SS|*             | Bridging Function  |
               +-+--+              +- - - - - - - - - - +



             Figure 4. Public Access Network using IEEE 802.16


9.  IANA Considerations

   This document has no actions for IANA.


10.  Security Considerations

   This document does not introduce any new vulnerabilities to IPv4 and
   IPv6 specifications or operations.  The security of the IEEE 802.16
   air interface between SSs and BS is the subject of [802.16] and the
   security issues of Ethernet bridging are the subjects of [802.1D].
   The generic IP over Ethernet network using IEEE 802.16 emulates
   Ethernet link, since existing IPv4 and IPv6 security mechanisms over
   Ethernet can be still used.  While the public access network ensures
   secure isolation of each of upstream link between hosts and AR, it
   still adopts SEcure Neighbor Discovery (SEND) [RFC3971] for securing
   neighbor discovery processes and it does not introduce any new
   vulnerabilities over those of Ethernet bridging.


11.  Acknowledgments

   The authors would like to thank David Johnston, Dave Thaler, Jari



Jeon, et al.              Expires May 22, 2009                 [Page 14]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   Arkko and others for their inputs to this work.


12.  References

12.1.  Normative References

   [802.16]   P802.16Rev2D7, "Draft Standard for Local and metropolitan
              area networks, Part 16: Air Interface for Fixed Broadband
              Wireless Access Systems (to be updated according to the
              released IEEE 802.16-2009 standard)", October 2008.

   [802.16k]  IEEE Std 802.16k-2007, "IEEE Standard for Local and
              metropolitan area networks, Media  Access Control (MAC)
              Bridges, Amendment 5: Bridging of IEEE 802.16",
              March 2007.

   [802.1D]   IEEE Std 802.1D-2004, "IEEE Standard for Local and
              metropolitan area networks, Media Access Control (MAC)
              Bridges", June 2004.

   [802.1Q]   IEEE Std 802.1Q-2005, "IEEE Standard for Local and
              metropolitan area networks, Virtual Bridged Local Area
              Networks", May 2005.

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC0894]  Hornig, C., "Standard for the transmission of IP datagrams
              over Ethernet networks", STD 41, RFC 894, April 1984.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.



Jeon, et al.              Expires May 22, 2009                 [Page 15]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5121]  Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
              Madanapalli, "Transmission of IPv6 via the IPv6
              Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
              February 2008.

12.2.  Informative References

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, May 2006.

   [RFC4562]  Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method
              for Subscriber Separation on an Ethernet Access Network",
              RFC 4562, June 2006.

   [RFC5154]  Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE
              802.16 Problem Statement and Goals", RFC 5154, April 2008.

   [TR101]    DSL Forum, "Migration to Ethernet-Based DSL Aggregation",
              April 2006.


Appendix A.  Multicast CID Deployment Considerations

   Multicast CIDs are highly efficient means to distribute the same
   information concurrently to multiple SSs under the same BS.  However,
   the deployment of multicast CIDs for multicast or broadcast data
   services suffers from following drawbacks.

   A drawback of multicast CIDs for Ethernet over IEEE 802.16 is the
   unidirectional nature of multicast CIDs.  While it is possible to
   multicast information downstream to a number of SSs in parallel,
   there are no upstream multicast connections.  In upstream direction,
   unicast CIDs have to be used for sending multicast messages over the



Jeon, et al.              Expires May 22, 2009                 [Page 16]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   air to the BS requiring a special multicast forwarding function for
   sending the information back to the other SSs on a multicast CID.
   While similar in nature to a bridging function, there is no
   appropriate forwarding model available. [802.1D] cannot take
   advantage of the multicast CIDs because it relies on unicast
   connections or bidirectional broadcast connections.

   A further drawback of deploying multicast CIDs for distributing
   broadcast control messages like ARP requests is the inability to
   prevent the wake-up of dormant-mode SSs by messages not aimed for
   them.  Whenever a message is sent over a multicast CID, all
   associated stations have to power up and receive and process the
   message.  While this behavior is desirable for multicast and
   broadcast traffic, it is harmful for link layer broadcast control
   messages aimed for a single SS, like an ARP Request.  All other SSs
   are wasting scarce battery power for receiving, decoding and
   discarding the message.  Low power consumption is an extremely
   important aspect in a wireless communication.

   Furthermore, it should keep in mind that multicast CIDs are only
   efficient for a large number of subscribed SSs in a cell.  Due to
   incompatibility with advanced radio layer algorithms based on
   feedback information from the receiver side, multicast connections
   require much more radio resource for transferring the same
   information as unicast connections.


Appendix B.  Centralized vs. Distributed Bridging

   This specification introduces a network-side bridging function, which
   can be realized either by a centralized device or by multiple
   interconnected bridges in a distributed manner.  One common
   implementation of the distributed model is the scenario where a
   bridge is directly attached to the BS, such that the interface
   between BS and bridging function is becoming a software interface
   within the operation system of the BS/Bridge device.

   The operational enhancements described in Section 7 of this document
   are based on the availability of additional information about all the
   hosts attached to the Ethernet.  Flooding all ports of the bridge can
   be avoided when a-priori information is available to determine the
   port to which an Ethernet frame has to be delivered.

   Best performance can be reached by a centralized database containing
   all information about the hosts attached to the Ethernet.  A
   centralized database can be established either by a centralized
   bridge device or by a hierarchical bridging structure with dedicated
   uplink and downlink ports like in the public access case, where the



Jeon, et al.              Expires May 22, 2009                 [Page 17]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   uppermost bridge is able to retrieve and maintain all the
   information.

   As the generic case of the IP over Ethernet over IEEE 802.16 link
   model does not make any assumption of the location of the AR (an AR
   may eventually be attached to a SS), a centralized bridging system is
   recommended for the generic case.  In the centralized system, every
   connection over the air of a link should be attached to a single
   centralized bridge.  The support functions of Multicast/Broadcast
   bridging according to Section 7.1, handling of DHCP broadcasts
   according to Section 7.2, proxy ARP function according to Section 7.3
   and MAC-Forced Forwarding according to Section 8 are implemented in
   the centralized bridge.

   A distributed bridging model is in particular appropriate for the
   public access mode, where Ethernet frames, which do not have entries
   in the bridge behind the BS, are send upstream to a bridge finally
   having an entry for the destination MAC address.


Authors' Addresses

   Hongseok Jeon
   Electronics Telecommunications Research Institute
   161 Gajeong-dong, Yuseong-gu
   Daejeon,   305-350
   KOREA

   Phone: +82-42-860-3892
   Email: hongseok.jeon@gmail.com


   Max Riegel
   Nokia Siemens Networks
   St-Martin-Str 76
   Munich,   81541
   Germany

   Phone: +49-89-636-75194
   Email: maximilian.riegel@nsn.com











Jeon, et al.              Expires May 22, 2009                 [Page 18]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


   Sangjin Jeong
   Electronics Telecommunications Research Institute
   161 Gajeong-dong, Yuseong-gu
   Daejeon,   305-350
   KOREA

   Phone: +82-42-860-1877
   Email: sjjeong@gmail.com











































Jeon, et al.              Expires May 22, 2009                 [Page 19]


Internet-Draft           IPoEth over IEEE 802.16           November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Jeon, et al.              Expires May 22, 2009                 [Page 20]