Internet DRAFT - draft-ietf-16ng-ip-over-ethernet-over-802.16

draft-ietf-16ng-ip-over-ethernet-over-802.16






Network Working Group                                            H. Jeon
Internet-Draft                                                      ETRI
Intended status: Standards Track                               M. Riegel
Expires: October 20, 2008                                            NSN
                                                                S. Jeong
                                                                    ETRI
                                                          April 18, 2008


       Transmission of IP over Ethernet over IEEE 802.16 Networks
          draft-ietf-16ng-ip-over-ethernet-over-802.16-06.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 October 20, 2008.

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 October 20, 2008                [Page 1]

Internet-Draft           IPoEth over IEEE 802.16              April 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . .  5
     4.1.  Connection Oriented Air Interface  . . . . . . . . . . . .  5
     4.2.  Feeding User Data into the Appropriate Connections . . . .  6
     4.3.  MAC addressing in IEEE 802.16  . . . . . . . . . . . . . .  6
   5.  Ethernet Network Model for IEEE 802.16 . . . . . . . . . . . .  6
     5.1.  IEEE 802.16 Ethernet Link Model  . . . . . . . . . . . . .  6
     5.2.  Ethernet without Native Broadcast and Multicast Support  .  8
     5.3.  Deployment Scenarios for IP over Ethernet over IEEE
           802.16 . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       5.3.1.  Public Access Scenario . . . . . . . . . . . . . . . .  9
       5.3.2.  Enterprise LAN Scenario  . . . . . . . . . . . . . . .  9
   6.  Network-side Bridge Considerations . . . . . . . . . . . . . . 10
     6.1.  IEEE 802.16 Ethernet Link Model Considerations . . . . . . 11
       6.1.1.  Public Access Scenario Case  . . . . . . . . . . . . . 11
       6.1.2.  Enterprise LAN Scenario Case . . . . . . . . . . . . . 11
     6.2.  Segmenting the Ethernet into VLAN  . . . . . . . . . . . . 11
     6.3.  Multicast and Broadcast Packet Processing  . . . . . . . . 12
       6.3.1.  Multicast Transmission Considerations  . . . . . . . . 12
       6.3.2.  Broadcast Transmission Considerations  . . . . . . . . 13
     6.4.  Proxy ARP  . . . . . . . . . . . . . . . . . . . . . . . . 13
       6.4.1.  Public Access Scenario Case  . . . . . . . . . . . . . 13
       6.4.2.  Enterprise LAN Scenario Case . . . . . . . . . . . . . 13
   7.  Access Router Considerations . . . . . . . . . . . . . . . . . 14
   8.  Prefix Assignment  . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Public Access Scenario Case  . . . . . . . . . . . . . . . 14
     8.2.  Enterprise LAN Scenario Case . . . . . . . . . . . . . . . 14
   9.  Transmission of IP over Ethernet . . . . . . . . . . . . . . . 14
     9.1.  IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 14
       9.1.1.  Address Configuration  . . . . . . . . . . . . . . . . 15
       9.1.2.  Address Resolution . . . . . . . . . . . . . . . . . . 15
     9.2.  IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 15
       9.2.1.  Router Discovery, Prefix Discovery and Parameter
               Discovery  . . . . . . . . . . . . . . . . . . . . . . 15
       9.2.2.  Address Configuration  . . . . . . . . . . . . . . . . 15
       9.2.3.  Address Resolution . . . . . . . . . . . . . . . . . . 16
     9.3.  Maximum Transmission Unit Consideration  . . . . . . . . . 16
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17



Jeon, et al.            Expires October 20, 2008                [Page 2]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     13.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Multicast CID Deployment Considerations . . . . . . . 19
   Appendix B.  Distributed Bridging Considerations . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22












































Jeon, et al.            Expires October 20, 2008                [Page 3]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


1.  Introduction

   IEEE 802.16 [802.16] specifies a fixed broadband wireless access
   system.  IEEE 802.16e [802.16e] amends the base specification for
   supporting mobile stations while adopting the same data link
   principles.

   The IEEE 802.16 standards define a packet CS (Convergence Sublayer)
   for interfacing with all packet-based protocols.  IEEE 802.16g
   [802.16g], also, specifies a generic packet CS to provide an upper-
   layer protocol independent interface.  This document describes
   transmission of IPv4 over Ethernet as well as IPv6 over Ethernet via
   the CSs 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 the cellular radio transmission system.  Hence,
   Ethernet on top of IEEE 802.16 is realized by bridging connections
   which IEEE 802.16 provides between a BS (Base Station) and its
   associated SSs (Subscriber Stations).

   With 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.  Those IP specific support
   functions are preferably realized in a centralized device containing
   a bridge for aggregation of traffic from all the BSs to provide a
   more straightforward management solution and allow for effectively
   commoditized BSs, which may be deployed in the IEEE 802.16 based
   access network in a large volume.


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].




Jeon, et al.            Expires October 20, 2008                [Page 4]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


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
   these connections realize 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.

   While uplink connections from the SSs to the BS provide only unicast
   transmission capabilities, 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.  The use of multicast CIDs
   for realizing multicast transmissions, however, is not addressed in
   this document due to the reduced transmission efficiency of multicast
   CIDs for small multicast groups, the missing support by [802.1D] for
   uni-directional broadcast channels as well as additional security
   threats of broadcast channels in a power-conservative wireless
   system.

   Appendix A provides more background information about the issues
   arising with multicast CIDs in IEEE 802.16 systems.

             [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



Jeon, et al.            Expires October 20, 2008                [Page 5]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


4.2.  Feeding User Data into the Appropriate Connections

   The IEEE 802.16 defines a packet CS for interfacing with all packet-
   based protocols.  It classifies high-layer packets depending on the
   values in the defined set of the packet header fields and assigns the
   packets to an appropriate Service Flow.

   There are multiple packet CSs to enable the transmission of different
   kind of packets over IEEE 802.16.  The IEEE 802.16 has an Ethernet
   CS, as one of the Packet CS, made specially for transport for the
   Ethernet frames.

   IEEE 802.16g [802.16g] defines a GPCS (Generic Packet Convergence
   Sublayer), which may be used to transfer Ethernet frames over IEEE
   802.16 as well.

4.3.  MAC addressing in IEEE 802.16

   The 48-bit unique MAC address of a SS is used during the initial
   ranging process for the identification of a SS and may be verified by
   the succeeding PKM 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 SSs as well as the BS,
   the forwarding of packets over the air is performed only on base of
   the CID value.  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 beneficial when Ethernet frames with arbitrary
   MAC addresses have to be forwarded to a SS in the case that the SS is
   interconnected to another network.

   Due to the managed assignment of the service flows and associated CID
   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 plain layer 2
   forwarding behavior between the radio link toward the subscriber side
   and its associated wired link on the network side.


5.  Ethernet Network Model for IEEE 802.16

5.1.  IEEE 802.16 Ethernet Link Model

   According to [RFC4861], a link is defined as a communication facility
   or medium over which IP devices can communicate at the link layer,
   i.e. the layer immediately below IP.  Ethernet fully satisfies the



Jeon, et al.            Expires October 20, 2008                [Page 6]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   definition of the link.  IEEE 802.16, however, has limitations on its
   transitive connectivity.  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 interconnect each of
   point-to-point connections between SSs and the BS so that Ethernet is
   realized over IEEE 802.16 access network.

   This document defines an IEEE 802.16 Ethernet link model to provide
   above the interconnection functionality.  The IEEE 802.16 Ethernet
   link model MUST interconnect each point-to-point connections assigned
   to SSs at a centralized point, a.k.a. network-side bridge, as shown
   in Figure 2.  This is equivalent to today's switched Ethernet with
   twisted pair wires connecting the hosts to a bridge ("Switch").  The
   single and centralized network-side bridge allows best control of the
   broadcasting forwarding behavior and prevents potential security
   threats coming up with cascaded bridges.  Appendix B explains the
   drawbacks and the potential security threats of an architecture where
   a bridge interconnects BSs integrated with bridging function.

   The BS MUST forward all the Service Flows belonging to one SS to one
   port of the network-side bridge.  No more than one SS MUST be
   connected to one port of the network-side bridge.  Separation method
   for multiple links on the connection between the BS and the network-
   side bridge is out of scope for this document.  One implementation is
   to deploy flow identifiers (e.g.  VLAN-IDs or GRE KEYS) on the wired
   path.  Section 6 discusses the network-side bridge in detail.

   If the SS is connected to another network consisting of multiple
   hosts 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 October 20, 2008                [Page 7]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


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

     [Subscriber Side]       [Network Side]        [Subscriber Side]
       |         |                 |                 |       |   |
      ETH       ETH               ETH               ETH     ETH ETH
       |         |                 |                 |       |   |
       |         |       +---------+---------+       |     +-+---+-+
       |         |       |     Net-Bridge    |       |     |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 [802.16][802.16e] does not define broadcast and
   multicast of IP packets.  Also, MBS (Multicast and Broadcast Service
   as specified in Section 6.3.23 of [802.16e]) does not cover IP
   broadcast or multicast data because MBS is invisible to the IP layer.
   Hence IP broadcast and multicast packets SHOULD be replicated and
   then carried via unicast transport connections as IEEE 802.16 access
   link.  The network-side bridge performs the replication and
   forwarding as specified in Section 6.3.

5.3.  Deployment Scenarios for IP over Ethernet over IEEE 802.16

   This section discusses two possible deployment scenarios based on the
   IEEE 802.16 Ethernet link model: Public Access scenario and
   Enterprise LAN scenario.

   In both scenarios, an AR is connected to a network-side bridge, which
   acts as an aggregation point for all the connections from SSs.
   Multiple ARs can exist on a link and the link may consist of multiple
   hosts, either being co-located with a SS or behind a SS integrated
   with a subscriber-side bridge.  The network behind a SS can support
   various access network technologies, e.g. 802.3, 802.11 or 802.15.




Jeon, et al.            Expires October 20, 2008                [Page 8]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   There is a big difference between the scenarios in terms of the
   service provider policies.  The difference is also reflected in
   Section 6.1, Section 6.4, and Section 8.

5.3.1.  Public Access Scenario

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

   In the scenario, the AR is connected to a network-side bridge.  The
   AR MAY perform security filtering, policing and accounting of all
   traffic from hosts, e.g. like a NAS (Network Access Server).


                 +--+
                 |SS|
                 +--+*
                       *
                         *   +----+
               +--+        * |    +-------+
               |SS|* * * * **| BS +------+ \
               +--+        * |    +-----+ \ \  +---+
                   +--+  *   +----+      \ \ +-+  B|
                   |SS|*                  \ +--+N r|
                   +--+                    +---+e i|   +----+
        +----+                                 |t d+---+ AR +--Internet
        |Host+                              +--+  g|   +----+
        +----+\                  +----+    / +-+  e|
        +----+ +------+--+       |    +---+ /  +---+
        |Host+-+Bridge|SS|* * * *| BS |    /
        +----+ +------+--+    *  |    +---+
        +----+/             *    +----+
        |Host+      +--+  *
        +----+      |SS|*
                    +--+


                     Figure 3. Public Access Scenario

5.3.2.  Enterprise LAN Scenario

   The enterprise LAN scenario assumes trust relationship between all
   hosts and thus enables hosts to directly communicate with each other
   without detouring.  There can be multiple ARs, which may reside on
   both the subscriber side and network side as shown in Figure 4.





Jeon, et al.            Expires October 20, 2008                [Page 9]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


                      +--+
                      |SS|
                      +--+*                               +----+
                            *   +----+                    +Host|
                  +--+        * |    +-------+           /+----+
                  |SS|* * * * **| BS +------+ \         / +----+
                  +--+        * |    +-----+ \ \  +---+/ ++Host|
                      +--+  *   +----+      \ \ +-+  B+ / +----+
                      |SS|*                  \ +--+N r++
         +----+       +--+                    +---+e i|   +----+
       --+ AR ++                                  |t d+---+ AR +---
         +----+ \                              +--+  g|   +----+
                 \                  +----+    / +-+  e|
           +----+ +------+--+       |    +---+ /  +---+
           |Host+-+Bridge|SS|* * * *| BS |    /
           +----+ +------+--+    *  |    +---+
           +----+/             *    +----+
           |Host+      +--+  *
           +----+      |SS|*
                       +--+


                     Figure 4. Enterprise LAN Scenario


6.  Network-side Bridge Considerations

   Network-side bridge is based on [802.1D] to interconnect point-to-
   point connections assigned to each SSs and pass Ethernet frames
   between the point-to-point connections.  However, applying the IEEE
   802.16 Ethernet link model and avoiding broadcast or multicast packet
   flooding require additional IP specific functionalities on the
   network-side bridge in addition to the mandatory functions according
   to Section 5.1 of [802.1D].  Following sections discuss the
   additional functions of the network-side bridge based on Figure 5.


                      [Lower Side]                [Upper Side]
    +--+          +--+             +------------+
    |SS+----------+  +-------------*            |             +----+
    +--+          |BS|             |Network-side*-------------+ AR |
    +--+          |  |             |Bridge      |             +----+
    |SS+==========+  +=============*            |
    +--+          +--+             +------------+


                       Figure 5. Network-side Bridge




Jeon, et al.            Expires October 20, 2008               [Page 10]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


6.1.  IEEE 802.16 Ethernet Link Model Considerations

   In the IEEE 802.16 Ethernet link model, the network-side bridge
   SHOULD create a new lower side port whenever a new SS attaches to any
   of the BSs of the network or SHOULD remove a lower side port when an
   associated SS detaches from the BSs.  The method for managing the
   port on the network-side bridge may depend on approaches to build
   multiple links on the connection between the BS and the network-side
   bridge.  The port managing method is out of scope for this document.

6.1.1.  Public Access Scenario Case

   The network-side bridge SHOULD forward all packets received from any
   lower side ports to all upper side ports being in the forwarding
   state.  Direct communication between SSs SHOULD NOT be supported by
   the network-side bridge and all packets sent from a SS to the BS
   SHOULD be delivered to an AR.

   While the network-side bridge forces all traffic from hosts to reach
   the AR, it still performs Learning Process and maintains Filtering
   Database as specified in [802.1D] and then forwards IP unicast
   packets from the AR based on the Filtering Database.  However, IP
   broadcast and multicast packets SHOULD be treated with special rules
   as stated in Section 6.3.

6.1.2.  Enterprise LAN Scenario Case

   IP unicast packets from either SSs or AR MUST be forwarded by
   [802.1D] based bridging.  IP broadcast and multicast packets SHOULD
   be processed in the bridge according to the rules presented in
   Section 6.3.

6.2.  Segmenting the Ethernet into VLAN

   It is possible to restrict the size and coverage of an IP link by
   segmenting the Ethernet and grouping subsets of hosts into VLANs.
   Therefore, the network-side bridge MAY be enabled to support VLANs
   according to [802.1Q] by assigning and handling the VLAN-IDs of the
   virtual bridge ports.

   If a SS itself contains a VLAN enabled bridge or 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.







Jeon, et al.            Expires October 20, 2008               [Page 11]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


6.3.  Multicast and Broadcast Packet Processing

   All multicast and multicast control messages SHOULD be processed in
   the network-side bridge according to [RFC4605].  Broadcasting
   messages to all lower side ports of the network-side bridge SHOULD be
   prevented.

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

6.3.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, like IP broadcast packets.  As a result, the IP multicast
   packets would be transmitted even to SSs 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.

   IGMP/MLD proxying in [RFC4605] is a simple mechanism for multicast
   packets forwarding based on the Internet Group Management Protocol
   (IGMP) or Multicast Listener Discovery (MLD) membership information,
   which works only in a basic tree topology.  An IGMP/MLD proxy device
   does learning and proxying group membership information, and then
   forwards the IP multicast packets based on the membership
   information.  Typically, the proxy device is located at an
   aggregation point, which has a single upstream interface and multiple
   downstream interfaces.

   The IEEE 802.16 Ethernet link model in Section 5.1 has a basic tree
   topology and [RFC4541] provides an application guide how bridge,
   non-IP device, to examine and learn group membership.  Hence,
   [RFC4605] can be applied to the IEEE 802.16 Ethernet link model to
   reduce the multicast packet flooding.

   The network-side bridge in the IEEE 802.16 Ethernet link model SHOULD
   play a role in proxying IGMP/MLD messages as specified in [RFC4605].
   The network-side bridge SHOULD perform the host portion of IGMP/MLD
   process on its upper side port and the router portion of IGMP/MLD
   process on its all lower side ports.  Note that the network-side
   bridge SHOULD perform IGMP/MLD Querier on only lower side ports,
   which are already subscribed with received IGMP/MLD membership report
   messages.  This is due to the reduction of flooding of IGMP/MLD Query
   messages.  The network-side bridge SHOULD maintain subscription
   information on each lower side port with received IGMP/MLD membership
   report messages and forward multicast packets from a upper side port
   to lower side ports based on the subscription information.  In case



Jeon, et al.            Expires October 20, 2008               [Page 12]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   of multicast packets from lower side ports, the network-side bridge
   SHOULD forward the packets to an upper side port as well as lower
   side ports, except the incoming lower side port, based on the
   subscription information.

6.3.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 bridge in the IEEE 802.16 Ethernet link model SHOULD
   discard all IP broadcast packets except ARP, DHCP (DHCPv4 and
   DHCPv6), IGMP, and MLD related traffic.  The ARP, DHCP, IGMP and MLD
   related packets SHOULD be forwarded with special rules specified in
   this specification.  Note that packets destined for permanently
   assigned multicast addresses such as 224.0.0/24 in IPv4 or FF02::1 in
   IPv6 are also regarded as broadcast data.

6.4.  Proxy ARP

   Proxy ARP provides a process where a device on the link between hosts
   answers ARP Requests instead of the remote host.  In this
   specification, the Proxy ARP mechanism is used to force all traffic
   from hosts to the access router or to avoid broadcasting ARP Requests
   over the air depending on the particular deployment scenario.  The
   Proxy ARP process is usually co-located with the network-side bridge.

6.4.1.  Public Access Scenario Case

   The network-side bridge SHOULD filter broadcast ARP Requests and
   SHOULD respond to all the ARP Requests from lower side port with the
   access router's Ethernet MAC address so that all IPv4 packets from
   SSs are forwarded to the access router.

6.4.2.  Enterprise LAN Scenario Case

   The network-side bridge 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 network-side bridge is updating its Filtering
   Database according to [802.1D].

   Upon receiving the ARP Requests from SSs, the network-side bridge
   SHOULD unicast ARP Replies back to SSs with Ethernet address of
   target host provided that the target address matches an entry in the



Jeon, et al.            Expires October 20, 2008               [Page 13]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   ARP Cache.  Otherwise, the network-side bridge MAY flood the ARP
   Requests.  The network-side bridge SHOULD silently discard any
   received self-ARP Requests.


7.  Access Router Considerations

   In the public access scenario, all packets between SSs will always be
   relayed via access router.  In this scenario, the access router
   SHOULD forward packets via the same interface on which the access
   router received the packets, if the source and destination addresses
   are reachable on the same interface.  This would result in a Redirect
   message from the access router [RFC0792][RFC4861].  The Redirect
   message MUST be suppressed.


8.  Prefix Assignment

8.1.  Public Access Scenario Case

   Unique IPv6 prefix per SS SHOULD be assigned because it results in
   layer 3 separation between SSs and it forces all packets from SSs to
   be transferred to an AR.  The AR SHOULD assign the IPv6 prefixes with
   Prefix Information option as specified in [RFC4861].

   One IPv4 prefix SHOULD be assigned to all SSs in a way that it
   benefits from high address assignment efficiency when concerning
   scarce IPv4 address space.  The prefix can be manually configured or
   automatically with subnet mask option in DHCPv4 [RFC2132].

8.2.  Enterprise LAN Scenario Case

   The AR SHOULD assign all SSs one IPv4 prefix in IPv4 over Ethernet
   and one or more IPv6 prefixes in IPv6 over Ethernet so that all SSs
   under the same AR share the subnet prefix.  Sharing the prefix means
   locating all SSs on the same subnetwork.


9.  Transmission of IP over Ethernet

9.1.  IPv4 over Ethernet

   [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.  IP over Ethernet over IEEE
   802.16 MUST follow the operations specified in [RFC0894].




Jeon, et al.            Expires October 20, 2008               [Page 14]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


9.1.1.  Address Configuration

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

   DHCP 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 bridge 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 bridge as Layer 2
   DHCP Relay Agent, like described in [TR101].  Port number of the
   network-side bridge is possible as Circuit ID and Remote ID may be
   left unspecified.  Note that using option-82 requires option-82 aware
   DHCP servers.

9.1.2.  Address Resolution

   SSs MUST use Address Resolution Protocol (ARP) [RFC0826] for finding
   an Ethernet MAC address of destination.

9.2.  IPv6 over Ethernet

   [RFC2464] defines transmission of IPv6 Packets over Ethernet
   Networks.  In this document, encapsulation of IPv6 packets into
   Ethernet frames and mapping rules for IPv6 address to Ethernet
   address (i.e.  MAC address) MUST follow [RFC2464].

9.2.1.  Router Discovery, Prefix Discovery and Parameter Discovery

   Router Discovery, Prefix Discovery and Parameter Discovery procedures
   are achieved by receiving Router Advertisement messages.  In this
   specification, SSs perform above the discovery process by solicited
   Router Advertisement messages because periodic Router Advertisement
   messages are discarded on the network-side bridge following the
   Broadcast Data Forwarding Rules in Section 6.1.2.

9.2.2.  Address Configuration

9.2.2.1.  Stateful Address Autoconfiguration

   When the'M' flag in the received RA is set, a SS SHOULD perform
   stateful address configuration according to [RFC3315].  In this case,



Jeon, et al.            Expires October 20, 2008               [Page 15]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   an AR supports DHCPv6 server or relay function.

9.2.2.2.  Stateless Address Autoconfiguration

   SS SHOULD derive its global IPv6 addresses based on prefix and EUI-
   64-derived interface identifier and then confirm them through
   Duplicate Address Detection (DAD) as specified in [RFC4862] and
   [RFC4861].

9.2.3.  Address Resolution

   SS SHOULD send Neighbor Solicitation destined for solicited-node
   address corresponding to the target address in order to determine the
   MAC address of a neighbor and then resolve the MAC address by
   receiving Neighbor Advertisement as specified in [RFC4861].

9.3.  Maximum Transmission Unit Consideration

   [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
   SHOULD be 1500 bytes.

   In the deployment scenarios of IP over Ethernet over IEEE 802.16, it
   is likely that the link between BS and network-side bridge is
   implemented by GRE or VLANs because the WiMAX Forum has chosen GRE
   for the mobile WiMAX architecture and VLANs work well with Ethernet
   technologies.

   In the case of GRE-based implementation, it does not introduce
   additional considerations for MTU size.  GRE is able to carry any
   size of packet as IP is able to fragment and reassemble packets
   exceeding the MTU of the underlying transport.

   However, when VLANs are deployed on the link between a BS and a
   network-side bridge, there may be restrictions on the supported
   packet size.  Adding VLAN tags to Ethernet frames increases the
   length of the original Ethernet frame by 4 bytes each VLAN tag, which
   may cause the Ethernet frame to be discarded in the link between the
   bridge and an AR.  Therefore, the network operator should consider
   the size of stacked VLAN tags when deploying VLANs and setting the
   MTU of the link.







Jeon, et al.            Expires October 20, 2008               [Page 16]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


10.  IANA Considerations

   This document has no actions for IANA.


11.  Security Considerations

   This document does not introduce new vulnerability to operations of
   IPv4 over Ethernet and IPv6 over Ethernet.  [RFC3971] can be adopted
   for securing neighbor discovery processes.


12.  Acknowledgments

   The authors would like to thank David Johnston, Dave Thaler, and
   others for their inputs to this work.


13.  References

13.1.  Normative References

   [802.16]   IEEE Std 802.16-2004, "IEEE Standard for Local and
              metropolitan area networks, Part 16: Air Interface for
              Fixed Broadband Wireless Access Systems", June 2004.

   [802.16e]  IEEE Std 802.16e-2005, "IEEE Standard for Local and
              metropolitan area networks, Part 16: Air Interface for
              Fixed and Mobile Broadband Wireless Access Systems,
              Amendment 2: Physical and Medium  Access Control Layers
              for Combined Fixed and Mobile Operation in Licensed
              Bands", December 2005.

   [802.16g]  IEEE Std 802.16g-2007, "IEEE Standard for Local and
              metropolitan area networks, Part 16: Air Interface for
              Fixed and Mobile Broadband Wireless Access Systems,
              Amendment 3: Management Plane  Procedures and Services",
              September 2007.

   [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.




Jeon, et al.            Expires October 20, 2008               [Page 17]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   [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.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, 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.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [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.

13.2.  Informative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.




Jeon, et al.            Expires October 20, 2008               [Page 18]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   [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.

   [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 in parallel to multiple SSs under the same BS.  However,
   the deployment of multicast CIDs for multicast or broadcast data
   services suffers from several 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
   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 system and it is



Jeon, et al.            Expires October 20, 2008               [Page 19]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


   necessary to protect SSs from denial of service attacks by wasting
   battery power due to malicious ARP requests.

   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 a unicast connections


Appendix B.  Distributed Bridging Considerations

   A large Ethernet link can be realized by cascading smaller bridges.
   This behavior would allow the network-side bridge function to be
   realized by a bridge connecting bridges integrated with the BSs.
   While this works for the plain Ethernet behavior, it introduces some
   drawbacks and even potential security threats for the transmission of
   IP over Ethernet over IEEE 802.16.

   The Proxy ARP function described in Section 6.4 prevents that ARP
   broadcast messages have to be forwarded to each of the associated
   SSs, when the ARP proxy is aware of the existence of the queried IP
   address at one of the bridge ports.  If the queried IP address is not
   known to the ARP proxy, the bridge has to flood all its ports with
   the ARP request.

   Distributing the bridging function into the BSs would imply that the
   Proxy ARP function is split into multiple Proxy ARP functions each
   knowing only about the subset of the IP addresses, which are directly
   connected by the BS.  IP addresses belonging to the same link but
   being connected to other BSs would not be known to the Proxy ARP
   functions and would cause ARP requests for these IP addresses to be
   broadcast to all SSs.  This causes a waste of radio resources for
   transmitting ARP requests and potentially more critical even, it
   would waste scarce battery power in the SSs.

   A malicious user would be able to deploy this behavior for denial of
   service attacks by exhausting the batteries of SSs by sending
   malicious ARP Requests.











Jeon, et al.            Expires October 20, 2008               [Page 20]

Internet-Draft           IPoEth over IEEE 802.16              April 2008


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


   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 October 20, 2008               [Page 21]

Internet-Draft           IPoEth over IEEE 802.16              April 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 October 20, 2008               [Page 22]