Network Working Group                                     J. Jee, Editor
Internet-Draft                                                      ETRI
Intended status: Informational Track                      S. Madanapalli
Expires: April 16, 2007                                        LogicaCMG
                                                               J. Mandin
                                                                  Runcom
                                                           G. Montenegro
                                                               Microsoft
                                                                 S. Park
                                                     Samsung Electronics
                                                               M. Riegel
                                                                 Siemens
                                                        October 13, 2006


               IP over 802.16 Problem Statement and Goals
                    draft-ietf-16ng-ps-goals-00.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 April 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This draft provides overview of 802.16 Network characteristics and



Jee, Editor, et al.      Expires April 16, 2007                 [Page 1]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   Convergence Sublayers, and specifies the problems in running the IETF
   IP (both IPv4 and IPv6) protocols over 802.16 Networks.  This
   document also presents the goals that point at relevant work to be at
   IETF.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . .  4
     4.1.  Transport Connections  . . . . . . . . . . . . . . . . . .  5
     4.2.  802.16 PDU format  . . . . . . . . . . . . . . . . . . . .  5
     4.3.  802.16 Convergence Sublayer  . . . . . . . . . . . . . . .  5
   5.  16ng Problem Statement . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Root Causes  . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  IP over 802.16 with IP CS: Problems  . . . . . . . . . . .  7
       5.2.1.  IPv4 over IP CS  . . . . . . . . . . . . . . . . . . .  7
       5.2.2.  IPv6 over IP CS  . . . . . . . . . . . . . . . . . . .  8
     5.3.  IP over 802.16 with Ethernet CS: Problems  . . . . . . . .  9
       5.3.1.  IPv4 over Ethernet CS  . . . . . . . . . . . . . . . . 10
       5.3.2.  IPv6 over Ethernet CS  . . . . . . . . . . . . . . . . 10
   6.  Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 16



















Jee, Editor, et al.      Expires April 16, 2007                 [Page 2]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


1.  Introduction

   Broadband Wireless Access networks address the inadequacies of low
   bandwidth wireless communication for user requirements such as high
   quality data/voice service, fast mobility, wide coverage, etc.  The
   IEEE 802.16 Working Group on Broadband Wireless Access Standards
   develops standards and recommended practices to support the
   development and deployment of broadband Wireless Metropolitan Area
   Networks [IEEE802.16].  Additionally, IEEE 802.16e is an amendment
   that adds support for mobility over the base IEEE 802.16
   specification [IEEE802.16e].

   Recently, the WiMAX Forum, and, in particular, its NWG (Network
   Working Group) is defining the IEEE 802.16(e) network architecture
   (e.g., IPv4, IPv6, Mobility, Interworking with different networks,
   AAA, etc).  The NWG is thus taking on work at layers above those
   defined by the IEEE 802 standards (typically limited to the physical
   and link layers only).  Similarly, WiBro (Wireless Broadband), a
   Korean effort which focuses on the 2.3 GHz spectrum band, is also
   based on the IEEE 802.16e specification [IEEE802.16e].

   IEEE 802.16(e) is different from existing wireless access
   technologies such as IEEE 802.11 or 3G. For example: immediately
   subsequent to network entry, an 802.16 SS (Subscriber Station) has no
   capability whatsoever for data (as opposed to management)
   connectivity.  The criteria by which the BS (Base Station) sets up
   the 802.16 MAC connections for data transport is not part of the
   802.16 standard and depends on the type of data services being
   offered (ie. the set up of transport connections will be different
   for IPv4 and IPv6 services).  Additionally - as 802.16 is a point-to-
   multipoint network - an 802.16 subscriber station is not capable of
   broadcasting (e.g., for neighbor discovery or dynamic address
   binding) or direct communication to the other nodes in the network.

   This lacking of facility for native multicasting for IP packet
   transfer results in inappropriateness to apply the basic IP operation
   like IPv4 Address Resolution Protocol or IPv6 Neighbor Discovery
   Protocol.  Accordingly, while 802.16 defines the encapsulation of an
   IP datagram in an IEEE 802.16 MAC payload, complete description of IP
   operation is not present.  Thus, IP operation over IEEE 802.16 can
   benefit from IETF input and specification.  Two styles of convergence
   sublayers of IEEE 802.16 are considered, IP CS and Ethernet CS.  This
   document will describe the problems identified in adopting IP over
   IEEE 802.16 networks under considering these two types of convergence
   sublayers.  Also several goals that point at relevant work to be done
   at IETF are presented subsequently.





Jee, Editor, et al.      Expires April 16, 2007                 [Page 3]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


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

   Subscriber Station (SS): A generalized equipment set providing
   connectivity between subscriber equipment and a base station (BS)

   Base Station (BS): A generalized equipment sets providing
   connectivity, management, and control of the subscriber station (SS).

   IP Gateway: An entity which performs IP routing function to provide
   IP connectivity for SSes.

   Protocol Data Unit (PDU): This refers to the data format passed from
   the lower edge of the 802.16 MAC to the 802.16 PHY, which typically
   contains SDU data after fragmentation, encryption, etc.

   Service Data Unit (SDU): This refers to the data format passed to the
   upper edge of the 802.16 MAC

   IP Subnet: Topological area that uses the same IP address prefix
   where that prefix is not further subdivided except into individual
   addresses as specifed from
   [I-D.thaler-intarea-multilink-subnet-issues].

   Link: Topological area bounded by routers which decrement the IPv4
   TTL or IPv6 Hop Limit when forwarding the packet as specifed from
   [I-D.thaler-intarea-multilink-subnet-issues].

   Transport Connection: IEEE 802.16's MAC connection between a SS and
   BS with a specific QoS attributes.  Each transport connection is
   identified by an unique identifier called connection identifier.


4.  Overview of the IEEE 802.16-2004 MAC layer

   The topology of the IEEE 802.16-2004 [IEEE802.16] network is point-
   to-multipoint (PMP): a Base Station (BS) communicates with a number
   of Subscriber Stations (SSes).  Each node in the network possesses a
   48-bit MAC address (though in the Base Station this 48-bit unique
   identifier is called "BSId").  Each node possesses RSA-based
   authorization mechanism using x.509 certificate attesting to its MAC
   address/BSId.  The [IEEE802.16e] enhanced RSA-based authorization and



Jee, Editor, et al.      Expires April 16, 2007                 [Page 4]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   developed EAP-based authentication defined in [RFC3748] accordingly.
   So EAP-based authentication is recommended for mobile user.  The BS
   and SS learn each others' MAC Address/BSId during the SS's entry into
   the network.

4.1.  Transport Connections

   User data traffic (in both the BS-bound and SS-bound directions) is
   carried on unidirectional "transport connections".  Each transport
   connection has a particular set of associated parameters indicating
   characteristics such as cryptographic suite and quality-of-service.

   After successful entry of a SS to the 802.16 network, no data traffic
   is possible - as there are as yet no transport connections between
   the BS and SS.  Transport connections are established by a 3-message
   signaling sequence within the MAC layer (usually initiated by the
   BS).

   A downlink-direction transport connection is regarded as "multicast"
   if it has been made available (via MAC signaling) to more than one
   SS.  Uplink-direction connections are always unicast.

4.2.  802.16 PDU format

   An 802.16 PDU (ie. the format that is transmitted over the airlink)
   consists of a 6-byte MAC header, various optional subheaders, and a
   data payload.

   The 802.16 6-byte MAC header carries the Connection Identifer (CID)
   of the connection with which the PDU is associated.  We should
   observe that there is no source or destination address present in the
   raw 802.16 MAC header.

4.3.  802.16 Convergence Sublayer

   The 802.16 convergence sublayer (CS) is the component of the MAC that
   is responsible for assigning transmit-direction SDUs (originating
   from a higher layer application - eg. an IP stack at the BS or SS) to
   a specific outbound transport connection.  The convergence sublayer
   maintains an ordered "classifier table".  Each entry in the
   classifier table includes a classifier and a target CID.  A
   classifier, in turn, consists of a conjunction of one or more
   subclassifiers - where each subclassifier specifies a packet field
   (eg. the destination MAC address in an Ethernet frame, or the TOS
   field of an IP datagram contained in an Ethernet frame) together with
   a particular value or range of values for the field.  To perform
   classification on an outbound SDU, the convergence sublayer proceeds
   from the first entry of the classifier table to the last, and



Jee, Editor, et al.      Expires April 16, 2007                 [Page 5]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   evaluates the fields of the SDU for a match with the table entry's
   classifier When a match is found, the convergence sublayer associates
   the SDU with the target CID (for eventual transmission), and the
   remainder of the 802.16 MAC and PHY processing can take place.

   802.16 define numerous convergence sublayer types.  The "type" of the
   convergence sublayer determines the fields that may appear in
   classifiers eg.

   o "802.3/Ethernet CS" permits classifiers that examine fields in
   802.3-style headers

   o "IPv4 CS" permits classifiers that examine fields of IPv4 (and
   encapsulated TCP/ UDP headers)

   o "IPv6 CS" permits classifiers that examine fields of IPv6 (and
   encapsulated TCP/ UDP headers)

   Other CS types include ATM, IPv4-over-ethernet CS and IPv6-over-
   ethernet CS.  An implementation of 802.16 can support multiple CS
   types.

   We can observe that the CS type actually defines the type of data
   interface (eg.  IPv4/IPv6 or 802.3 ) that is presented by 802.16 to
   the higher layer application.


5.  16ng Problem Statement

5.1.  Root Causes

   This section describes common problem statements regardless of
   convergence sublayer.

   The following are the root causes that prevent running IP protocols
   (both IPv4 and IPv6) over 802.16 networks smoothly.  The consequences
   of these characteristics are listed in Section 5.2 and 5.3.

   - Point-to-Multipoint architecture:

   The 802.16 is a point-to-multipoint network without bi-directional
   native multicast support.  This prevents IP nodes from multicasting.
   In 802.16 specification, when the 802.16 MAC receives a unicast/
   multicast/broadcast packet from upper Layers, it just looks at the
   various fields (classifiers) in the headers and maps to the outgoing
   CID (This can also be a multicast CID in case of downlink).

   When 802.16 MAC receives a PDU from the PHY, it simply passes it to



Jee, Editor, et al.      Expires April 16, 2007                 [Page 6]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   the layer above the MAC (eg.  Ethernet or IP).  It is the upper
   layer's responsibility to deliver the packet to the correct
   destination which nonetheless is limited by the existence of downlink
   multicast/broadcast connections for multicast/broadcast frames.
   Because IP layer services (e.g.  IPv4 ARP, DHCPv4, IPv6 NDP, DHCPv6
   etc.) rely on link-layer multicast--or services with similar
   semantics at the link-layer--, alternative mechanisms must be
   specified.

   - Limitation of Ethernet capability layer of 802.16:

   The Ethernet capability layer of 802.16 (called the convergence
   sublayer) specifies only how Ethernet frames are to be encapsulated
   over 802.16 wireless connections.  This demonstrates that Ethernet CS
   does not itself emulate Ethernet like functionality, and multicast/
   broadcast frames can not be processed at the 802.16 MAC layer only.
   These frames must be sent to an Ethernet/bridge layer, which in turn
   may send PDUs back to 802.16 downlink, to send out these multicast/
   broadcast frames there should be a downlink multicast/broadcast
   connection to which all SSes are listening.

   - Communication among SSes on the same IP Subnet:

   It is unclear in 802.16 networks how SSes under a certain IP gateway
   communicate each other under the assumption that they are in same IP
   Subnet.  In IPv6 case, [I-D.ietf-ipv6-2461bis] defines a link as a
   communication facility or medium over which nodes can communicate at
   the link layer, i.e., the layer immediately below IP.  Examples are
   Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM
   networks as well as internet (or higher) layer "tunnels", such as
   tunnels over IPv4 or IPv6 itself.  Therefore, IPv6 nodes on the same
   link can communicate directly without depending on the IP routing
   facility.  By the way, the 802.16 network has a connection oriented
   feature, where a connection always ends at the BS.  There is no
   support from 802.16 MAC/PHY for the direct communication among SSes
   under the same IP Subnet.  The issues and analysis regarding how to
   configure an IP Subnet over IEEE 802.16 networks are specified in
   more detail through the [I-D.ietf-16ng-ipv6-link-model-analysis].

5.2.  IP over 802.16 with IP CS: Problems

5.2.1.  IPv4 over IP CS

   - DHCPv4 IP Address management and assignment:

   For the IPv4 address management and assignment, IEEE 802.16 network
   refers primarily to allocation of Dynamic Host Configuration Protocol
   [RFC2131], static method is configured by manual though.  DHCPv4 is a



Jee, Editor, et al.      Expires April 16, 2007                 [Page 7]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   broadcasting-based IP allocation protocol.  When initializing its IP
   configuration, the SS broadcasts a DHCPDISCOVER message on its local
   physical subnet.  After receiving multiple DHCPOFFER messages, the SS
   broadcasts a DHCPREQUEST message with several options specifying
   desired configuration values.  However, current DHCPv4 operations are
   tricky because of IEEE 802.16 non-broadcasting characteristics.
   Especially, DHCPv4 operation is tightly related to ARP facilities
   (e.g., checking on the uniqueness of allocated network address,
   etc.).  For management and configuration requirements of SS, an IETF-
   based IP address allocation solutions should be specified in
   compliance with IEEE 802.16(e) networks.  In DHCPv6 [RFC3315] case,
   it is modeled on DHCPv4, so, the problems described above still
   remain.  For MIP-based mobile terminals, MIPv4 [RFC3344] based IP
   addressing is used instead of DHCPv4.  However, it still requires
   multicast/broadcast facilities for supporting ICMP Router
   Advertisement [RFC1256].

   - ARP resolution and ARP cache:

   Address Resolution is the process by which nodes determine the link-
   layer address of a destination node on the same subnet given only the
   destination's IP address and it is a mandatory function of TCP/IP.
   In IPCS case, however, there is no need for address resolution
   because MAC message is made by IP Gateway) instead of SS and hence
   ARP cache as 802.16 MAC address is never used as part of the 802.16
   Frame.  Blocking ARP needs to be implemented by SS itself in an
   implementation manner.  There is no way of how to use ARP facilities
   on SS.

5.2.2.  IPv6 over IP CS

   - Router Discovery:

   Because there is no MAC Address used in case of IPCS, it is unclear
   whether source link layer address need to be carried in the RS
   (Router Solicitation).  As 802.16 MAC Address is not used for
   delivering the frames the RS may need to have source IP address
   specified, so that the RA (Router Advertisement) can be sent back.
   This may require the completion of Link Local Address configuration
   before sending an RS.

   For sending periodic Router Advertisements in 802.16 Networks, BS
   either needs to send the RA in unicast manner for each SS explicitly
   or send the RA in multicast connection.

   - Prefix Assignment:

   If the same IP prefix is shared with multiple SSes then the link



Jee, Editor, et al.      Expires April 16, 2007                 [Page 8]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   consists of multiple SSes.  In this model a SS assumes that there
   exist on-link neighbors and tries to resolve the L2 address for the
   on-link prefixes.  However, direct communication using Link Layer
   Address between two SSs may not be possible.  This poses a problem
   for sharing a prefix with multiple SSes.

   - Address Resolution and Neighbor Cache:

   Address Resolution is the process by which nodes determine the link-
   layer address of an on-link destination (e.g., a neighbor) given only
   the destination's IP address.  In case of IP CS, there is no need for
   Address Resolution and hence Neighbor Cache as 802.16 MAC address is
   never used as part of the 802.16 Frame.

   - Next-Hop:

   In case of IPCS, the Next-hop may always be an IP Gateway.

   - Neighbor Unreachability Detection (NUD):

   In case of IP CS, a SS may always see the IP Gateway as the next hop,
   the NUD is required only for the IP Gateway(s).  Also the requirement
   of NUD may depend on the existence of a connection to the BS for that
   particular destination.  If there exists multiple IP Gateways (so the
   default routers), it is unknown if the NUD is required if an IP
   Gateway is not serving any 802.16 MAC connection.

   - Address Autoconfiguration:

   How Address Autoconfiguration can be achieved in 802.16 networks is
   dependent on following: 1) Whether the SSes attached to the same BS
   are neighbors (IP link Model), 2) Whether the prefix is being shared
   with other SSes.  If a unique prefix is assigned to each SS similar
   to 3G approach, then the subnet consists of only one SS and hence
   duplicate address detection (DAD) is trivial.  If the same prefix is
   shared with multiple SSes then the subnet consists of multiple SSes
   and DAD is required.  DAD in 802.16 requires explicit multicast
   support from the Networks as there is no native multicast support.
   Thus, the explicit mechanism to perform the DAD procedure in the
   802.16 network needs to be specified.

5.3.  IP over 802.16 with Ethernet CS: Problems

   We assume that the IP gateway supports Ethernet interface and the IP
   Gateway sees the Ethernet frame sent by the SS unchanged.






Jee, Editor, et al.      Expires April 16, 2007                 [Page 9]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


5.3.1.  IPv4 over Ethernet CS

   DHCPv4 IP Address management and assignment:

   In the Ethernet CS case, the SS act as a layer 2 device and IP
   assignment will be carried through for hosts behind the SS.  In this
   case, the SS simply forwards the DHCPv4 messages between the DHCPv4
   client and DHCPv4 server.  However, as pointed out in above, Ethernet
   CS is an optional function over IEEE 802.16 networks, so it can not
   be applied for all SSes and limitation of DHCPv4 still remains.

   - ARP resolution and ARP cache:

   Address Resolution is the process by which nodes determine the link-
   layer address of a destination node on the same subnet given only the
   destination's IP address and it is a mandatory function of TCP/IP.
   In Ethernet CS case, if ARP is blocked by SS like IPCS, there is no
   way to obtain the MAC address of IP Gateway without ARP process
   because SS have to generate its ARP request message by itself.  There
   is no way of how to use ARP facilities on SS.

5.3.2.  IPv6 over Ethernet CS

   - Router Discovery:

   For sending periodic Router Advertisements in 802.16 Networks, BS
   either needs to send the RA in unicast manner for each SS explicitly
   or send the RA through the multicast connection if available.

   - Prefix Assignment:

   Similar to IP CS case.

   - Address Resolution and Neighbor Cache:

   In case of Ethernet CS, if the prefix is shared with L-bit set, the
   Address Resolution may be required, which in turn requires multicast
   support from 802.16 MAC.  If the prefixes are advertised with L bit
   reset, then Address Resolution and Neighbor Cache for other SSes may
   not be required.  In this case, Neighbor Cache is maintained only for
   IP Gateway.

   - Next-Hop:

   When Ethernet CS is used and the accompanying Ethernet capability
   emulation is implemented, the next-hop for the destination IP with
   the same global prefix with the sender or link local address type
   would be the destination itself not the IP Gateway.



Jee, Editor, et al.      Expires April 16, 2007                [Page 10]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   - Neighbor Unreachability Detection (NUD):

   Same as IP CS case.

   - Address Autoconfiguration:

   Same as IP CS case.


6.  Gap Analysis

   This section analyzes gaps between 802.16 networks and possible
   alternative approaches.

   3GPP recommendation [RFC3314]:

   From the 3GPP recommendation, separate prefixes are allocated to each
   SSes resulting in the different IP Subnets for each SSes.  The IP
   Gateway on the IEEE 802.16 networks might be comparable to the GGSN
   of 3GPP network.  However, using PPP directly is not feasible in
   802.16 networks because there is no PPP Convergence Sublayer that
   permits classification to transport connections based on fields in a
   PPP header.

   LAN model [RFC0894]:

   It seems that it may be possible to follow the LAN model where BS and
   IP Gateway reside on the same box.  However, the BS implementation to
   emulate a LAN feature would be different from the previous Wireless
   LAN bridge.  In 802.16, BS does not directly see the destination
   Ethernet address of the uplink packets to deliver the layer 2 frame
   toward the downlink direction.  Moreover, mostly AP in the wireless
   LAN translates the 802.11 frame to 802.3 frame by the help of the
   existence of same LLC.  However, there is no LLC in the 802.16
   protocol stack thus, it is problematic to convert 802.16 frame to
   802.3 frame directly.


7.  Goals

   We need to first identify which "IP Subnet" model is a feasible one
   depending on each CS is used.  According to the identified "IP
   Subnet" model for each CS, we would specify the following work items.

   * IPv6 transmission for 802.16 network in case where IPv6 CS is used.

   * IP transmission for 802.16 network in case where Ethernet CS is
   used.



Jee, Editor, et al.      Expires April 16, 2007                [Page 11]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   * IPv4 transmission for 802.16 network in case where IPv4 CS is used.

   * The standard interface between BS and IP Gateway if necessary.

   The following are the goals in no particular order that point at
   relevant work to be done in IETF.

   Goal #1.  Define the feasible IP Subnet models depending on the CS
   used.

   Goal #2.  Provide the way to reduce the scarce air resources when
   utilizing the basic IP facility like IPv4 ARP and IPv6 NDP over
   802.16 networks.

   Goal #3.  Reduce the power consumption caused by waking up of dormant
   terminals.

   Goal #4.  Resolve the multilink subnet issues when using IP CS for
   Ethernet-like subnet model.

   Goal #5.  Work on Ethernet CS should provide interoperability with
   existing devices that employ Ethernet.

   Goal #6.  Provide the applicability of the previous security works
   like SEND [RFC3971].

   Goal #7.  Do not introduce any new security threats.


8.  Security Considerations

   As described in the section 4, several authentication and
   authorization mechanisms are defined by [IEEE802.16] and
   [IEEE802.16e].  In [IEEE802.16e] case, PKMv2 EAP-based authentication
   is recommended for the secure connection between SS and BS/IP
   Gateway.


9.  Acknowledgment

   We would like to express special thanks to IETF Mobility Working
   Group members of KWISF (Korea Wireless Internet Standardization
   Forum) for their initial efforts and remarkably to HeeYoung Jung for
   his motivation in proceeding this work.

   We also would like to express special thanks to the previous authors
   of the previous problem statement document, Myung-Ki Shin, Eun-Kyoung
   Paik and Jaesun Cha.



Jee, Editor, et al.      Expires April 16, 2007                [Page 12]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   We also would like to express thanks to Jicheol Lee, Sung Il Kim, Se
   Jun Park, Sang Eon Kim, Han-Lim Kim and Jung-Mo Moon for their inputs
   to this work.


10.  References

10.1.  Normative References

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

   [RFC1256]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
              September 1991.

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

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards",
              RFC 3314, September 2002.

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

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

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




Jee, Editor, et al.      Expires April 16, 2007                [Page 13]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


10.2.  Informative References

   [I-D.ietf-16ng-ipv6-link-model-analysis]
              Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
              based Networks",
              draft-ietf-16ng-ipv6-link-model-analysis-00 (work in
              progress), October 2006.

   [I-D.ietf-ipv6-2461bis]
              Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
              draft-ietf-ipv6-2461bis-08 (work in progress),
              September 2006.

   [I-D.thaler-intarea-multilink-subnet-issues]
              Thaler, D., "Issues With Protocols Proposing Multilink
              Subnets", draft-thaler-intarea-multilink-subnet-issues-00
              (work in progress), March 2006.

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

   [IEEE802.16e]
              IEEE P802.16e-2005, "Draft IEEE Standard for Local and
              metropolitan area networks, Amendment for Physical and
              Medium Access  Control Layers for Combined Fixed and
              Mobile Operation in Licensed Bands", 2005.


Authors' Addresses

   Junghoon Jee
   ETRI

   Email: jhjee@etri.re.kr


   Syam Madanapalli
   LogicaCMG

   Email: smadanapalli@gmail.com









Jee, Editor, et al.      Expires April 16, 2007                [Page 14]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


   Jeff Mandin
   Runcom

   Email: jeff@streetwaves-networks.com


   gabriel_montenegro_2000@yahoo.com
   Microsoft

   Email: gabriel_montenegro_2000@yahoo.com


   Soohong Daniel Park
   Samsung Electronics

   Email: soohong.park@samsung.com


   Maximilian Riegel
   Siemens

   Email: maximilian.riegel@siemens.com
































Jee, Editor, et al.      Expires April 16, 2007                [Page 15]


Internet-Draft         IP over 802.16 PS and Goals          October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Jee, Editor, et al.      Expires April 16, 2007                [Page 16]