[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                          M-K. Shin
Internet-Draft                                                      ETRI
Expires: August 27, 2006                                       H-J. Jang
                                                             Samsung AIT
                                                       February 23, 2006


             Transmission of IPv6 Packets over IEEE 802.16
                  draft-shin-16ng-ipv6-transmission-00

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 August 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies the frame format for transmission of IPv6
   packets and the method of forming IPv6 link-local addresses and
   statelessly autoconfigured addresses on IEEE 802.16 networks.  It
   also specifies how to send IPv6 unicast and multicast packets over
   IEEE 802.16 networks.





Shin & Jang              Expires August 27, 2006                [Page 1]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Maximum Transmission Unit  . . . . . . . . . . . . . . . . . .  5
   4.  Frame Format . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Stateless Autoconfiguration and Link-Local Addresses . . . . .  8
   6.  Address Mapping  . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Packet Transmission  . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 10
       7.1.1.  Unicast Transmission . . . . . . . . . . . . . . . . . 11
       7.1.2.  Multicast Transmission . . . . . . . . . . . . . . . . 11
     7.2.  Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 11
       7.2.1.  Unicast Transmission . . . . . . . . . . . . . . . . . 12
       7.2.2.  Multicast Transmission . . . . . . . . . . . . . . . . 12
     7.3.  Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 12
       7.3.1.  Unicast Transmission . . . . . . . . . . . . . . . . . 13
       7.3.2.  Multicast Transmission . . . . . . . . . . . . . . . . 13
     7.4.  Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 13
       7.4.1.  Unicast Transmission . . . . . . . . . . . . . . . . . 14
       7.4.2.  Multicast Transmission . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20























Shin & Jang              Expires August 27, 2006                [Page 2]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


1.  Introduction

   Recently, broadband wireless access network is emerging for 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.

   As the deployment of wireless broadband access network progresses,
   users will be connected to IPv6 networks.  This document specifies
   the frame format for transmission of IPv6 packets and the method of
   forming IPv6 link-local addresses and statelessly autoconfigured
   addresses on IEEE 802.16 networks.  It also specifies how to send
   IPv6 unicast and multicast packets over IEEE 802.16 networks.

   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 [RFC 2119].
































Shin & Jang              Expires August 27, 2006                [Page 3]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


2.  Terminology

   SS: Subscriber Station.  A general equipment set providing
   connectivity between subscriber equipment and a BS.

   MS: Mobile Station.  A station in the mobile service intended to be
   used while in motion or during halts at unspecified points.  A mobile
   station (MS) is always a subscriber station (SS).

   BS: Base Station.  A generalized equipment set providing
   connectivity, management and control of MS connections.  A
   unidirectional mapping between BS and MS medium access control (MAC)
   peers for the purpose of transporting a service flow's traffic.
   Connections are identified by a connection identifier (CID).  All
   traffic is carried on a connection.

   PHS : Payload Header Suppression.

   PDU : Protocol Data Unit.  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.

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



























Shin & Jang              Expires August 27, 2006                [Page 4]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


3.  Maximum Transmission Unit

   IEEE 802.16 permits fragmentation and reassembly.  This capabilities
   are compleletely different from IP fragmentation and reassembly
   process.

   Fragmentation is the process by which a MAC SDU is divided into one
   or more MAC PDU.  This process is undertaken to allow efficient use
   of availabe bandwidth relative to the QoS requirements of
   connection's service flow.

   The default MTU size for IPv6 packets over IEEE 802.16 is not defined
   in [IEEE802.16].  Fragmentation frame size can be variable according
   to the bandwidth relative to the QoS requirements of connection's
   service flow.  Also, it may be dependent on type of Convergence
   Sublayers (CS).  For example, the default MTU size for IPv6 packets
   on an Ethernet CS would be 1500 octets.  Mannual configuration of
   each node may be required, if necessary.

































Shin & Jang              Expires August 27, 2006                [Page 5]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


4.  Frame Format

   IEEE 802.16 [IEEE802.16] defines the MAC and PHY layers for OFDM and
   OFDMA-based broadband wireless access.

   IEEE 802.16 PDU (Protocol Data Unit) which is 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.
   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.

   It is importmant to see that there is no source or destination MAC
   address in IEEE 802.16 the MAC header format.  Similar to general
   point-to-point links, the MAC address is not used for link-layer
   transmission.  Hence, mapping unicast or multicast addresses to IEEE
   802.16 MAC addresses is unnecessary.  Also, link-local addressess may
   be not needed for transmission of link-local destination packets.
   Instead, CID is used to identify connections to equivalent peers in
   the MAC of the BS and the MS in IEEE 802.16 networks.

   IEEE 820.16 SDU (Service Data Unit) which is the data format passed
   to the upper edge of the 802.16 MAC.

   IEEE 802.16 Convergence Sublayer (CS) provides the tunneling of
   IP(v6) packets over IEEE 802.16 air-link.  The tunnels are identified
   by the Connection Identifier (CID).  Generally, CS performs the
   following functions in terms of IP packet transmission: 1) Receipt of
   protocol data units (PDUs) from the higher layer, 2) Performing
   classification and CID mapping of the PDUs, 3) Delivering the PDUs to
   the appropriate MAC SAP, 4) Receipt of PDUs from the peer MAC SAP.

   [IEEE802.16] defines several CSs for carrying IP packets.  The
   several CSs are classified into two types of CS: IP CS and Ethernet
   CS.  Frame formats are different accordding to the CS types.

   IPv6 packets can be transmitted in 802.16 frames.  In case of IP CS
   type, the data field contains the IPv6 header and payload, as shown
   in Fig 1.  With Ethernet CS, Ethernet header MUST be included in
   802.16 frame's data field, as shown in Fig 2.









Shin & Jang              Expires August 27, 2006                [Page 6]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


                         0                   1
                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |H|E|   Type    |R|C|EKS|R|LEN  |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |    LEN LSB    |    CID MSB    |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |    CID LSB    |    HCS        |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |             IPv6              |
                        +-                             -+
                        |            header             |
                        +-                             -+
                        |             and               |
                        +-                             -+
                        /            payload ...        /
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                     Fig. 1


                         0                   1
                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |H|E|   Type    |R|C|EKS|R|LEN  |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |    LEN LSB    |    CID MSB    |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |    CID LSB    |    HCS        |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |           Ethernet            |
                        +-                             -+
                        /            header             /
                        /                               /
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |             IPv6              |
                        +-                             -+
                        |            header             |
                        +-                             -+
                        |             and               |
                        +-                             -+
                        /            payload ...        /
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                     Fig. 2






Shin & Jang              Expires August 27, 2006                [Page 7]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


5.  Stateless Autoconfiguration and Link-Local Addresses

   Like other IEEE 802 interfaces, the Interface Identifier for an IEEE
   802.16 interface is based on the EUI-64 identifier derived from the
   interface's built-in 48-bit IEEE 802 address.

   The Interface Identifier is then formed from the EUI-64 by
   complementing the "Universal/Local" (U/L) bit, which is the next-to-
   lowest order bit of the first octet of the EUI-64.

   For example, the Interface Identifier for an IEEE 802.16 interface
   whose built-in address is, in hexadecimal, "34-56-78-9A-BC-DE" would
   be "36-56-78-FF-FE-9A-BC-DE".

   A different MAC address set manually or by software should not be
   used to derive the Interface Identifier.  If such a MAC address must
   be used, its global uniqueness property should be reflected in the
   value of the U/L bit.

   An IPv6 address prefix used for stateless autoconfiguration of an
   IEEE 820.16 interface must have a length of 64 bits.

   The IPv6 link-local address for an IEEE 802.16 interface is formed by
   appending the Interface Identifier, as defined above, to the prefix
   FE80::/64.


      10 bits            54 bits                  64 bits
    +----------+-----------------------+----------------------------+
    |1111111010|         (zeros)       |    Interface Identifier    |
    +----------+-----------------------+----------------------------+

                           Fig. 3


















Shin & Jang              Expires August 27, 2006                [Page 8]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


6.  Address Mapping

   In general, the procedure for mapping IPv6 unicast addresses into
   IEEE 802.16 link-layer addresses is directly not applied as described
   in [RFC1972], since IEEE 802.16 MAC header does not contain any
   source or destination 802 MAC addresses.

   In case of IP CS type, mapping unicast or multicast addresses to IEEE
   802.16 MAC addresses is unnecessary.

   Instead, in order to identify connections to equivalent peers in the
   MAC of the BS/router and the MS, CID is used.  In certain cases,
   multicast CID may be provided for in the downlink.  It can be useful
   to tranmit efficiently link-local multicast destination packets (e.g,
   Router Advertisements) from BS/router to MSs.

   So, CID or multicast CID may be mapped to IPv6 unicast or multicast
   addresses with TCP/UDP ports.  This mapping is dependent on how to
   implement it.

   However, in case of Ethernet CS type, source and Ethernet addresses
   are required to form the frame for Ethernet CS.  In such case,
   address mapping is the same as [RFC1972].




























Shin & Jang              Expires August 27, 2006                [Page 9]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


7.  Packet Transmission

   IEEE 802.16 is different from existing wireless access technologies
   such as IEEE 802.11, and, while 802.16 defines the encapsulation of
   an IP datagram in an IEEE 802.16 MAC payload, complete description of
   IPv6 operation is not present and can benefit from IETF input and
   specification.

   Classification is the process by which a MAC SDU is mapped onto a
   particular connection for transmission between MAC peers.  This
   mapping process associates a MAC SDU with a connection based on some
   criteria such as protocol-specific packet information, which is
   called as classification parameters according to [Section 5.2 802.16-
   2004].  For IP CS, the packet may be classified by IP source/
   destination addresses, etc.  For Ethernet CS (IP over Ethernet CS),
   the packet may be classified by Ethernet source/destination addresses
   and IP source/destination addresses, source/destination port numbers,
   etc.  This is dependent on how to implement it.

   Base Station (BS) generates the flow based on the classification (IP
   CS or Ethernet CS).  It also decides where to send the packet, since
   IEEE 802.16 connection always ends at BS while IPv6 connection
   terminates at a default router.  This operation and limitation may be
   dependent on subnet model.

   While deploying IPv6 in the approach described in earlier sections,
   there are four possible typical scenarios as discussed below
   [I-D.shin-v6ops-802.16-deployment-scenarios].

7.1.  Scenario A

   Scenario A represents IEEE 802.16 access network deployment where a
   BS is integrated with a router, composing one box in view of
   implementation.  In this scenario, a subnet consists of only single
   BS/router and single MS.

       +-----+
       | MS1 |<-------------+
       +-----+              v
       +-----+            +-------+         +--------+
       | MS2 |<---------->|BS/AR1 |---------| Edge   |    ISP
       +-----+            +-------+         | Router +==>Network
                                            +--------+
       +-----+            +-------+           |
       | Ms3 |<---------->|BS/AR2 |-----------+
       +-----+            +-------+
                                     <---> IP termination
               Fig. 4  Scenario A



Shin & Jang              Expires August 27, 2006               [Page 10]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


7.1.1.  Unicast Transmission

   o Outbound unicast packet from MS is always forwarded on a particular
   transport connection in the uplink direction to the BS/AR.

   o When BS/AR receives the packet destined to same subnet (as MS) from
   MS, it does not relay the packet anymore.

   o Otherwise, BS/AR forwards the packet to the edge router, which
   forwards the packet accordingly based on its routing table such as
   IGP.

7.1.2.  Multicast Transmission

   Link-local and Non-link-local Multicast packet could be classified
   based on destination Ethernet address in Ethernet header (Ethernet
   CS) or IPv6 destination address in IP header.  (IP or Ethernet CS)

   o Outbound multicast packet from the MS is always forwarded on a
   particular transport connection in the uplink direction to the BS/AR.

   o When BS/AR receives the multicast packet with link-local scope from
   MS, it does not forward the packet anymore.

   o When BS/AR receives the multicast packet with non-link-local scope
   from MS, it looks up the IPv6 ulticasting routing table and forwards
   the packets to the edge router according to the result.

7.2.  Scenario B

   Scenario B represents IEEE 802.16 access network deployment where a
   BS is integrated with a router, composing one box in view of
   implementation, and a subnet consists of only single BS/AR and
   multiple MSs.


       +-----+
       | MS1 |<------+
       +-----+       |
       +-----+       |    +-------+         +--------+
       | MS2 |<------+--->|BS/AR1 |---------| Edge   |    ISP
       +-----+            +-------+         | Router +==>Network
                                            +--------+
       +-----+            +-------+           |
       | Ms3 |<---------->|BS/AR2 |-----------+
       +-----+            +-------+
                                     <---> IP termination
                 Fig. 5  Scenario B



Shin & Jang              Expires August 27, 2006               [Page 11]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


7.2.1.  Unicast Transmission

   o Outbound unicast packet from the MS is always forwarded on a
   particular transport connection in the uplink direction to the BS/AR.

   o When BS/AR receives the packet destined to same subnet from MS but
   not to itself, it forwards to downlink after uplink CID is replaced
   with the corresponding downlink CID (which may be associated with the
   specified Ethernet addresses in Ethernet CS or IP addresses in
   Ethernet/IP CS).

   o When BS/AR receives the packet destined to other subnet from MS, it
   forwards the packet to the edge router, which forwards the packet
   accordingly based on its routing table such as IGP.

7.2.2.  Multicast Transmission

   o Outbound unicast packet from the MS is always forwarded on a
   particular transport connection in the uplink direction to the BS/AR.

   o When BS/AR receives the multicast packet with link-local scope from
   MS, it sends back the packet to the downlink by using CID for
   multicast.

   o When BS/AR receives the multicast packet with non-link-local scope
   from MS, BS/AR looks up the IPv6 multicasting routing table and
   forwards the packets to the edge router according to the result.

7.3.  Scenario C

   Scenario C represents IEEE 802.16 access network deployment where a
   BS is separated from a router, and a subnet consists of only single
   BS and single router and multiple MSs.


       +-----+
       | MS1 |<------+
       +-----+       |
       +-----+       |    +-----+     +-----+    +--------+
       | MSs |<------+----| BS1 |---->| AR  |----| Edge   |    ISP
       +-----+            +-----+     +-----+    | Router +==>Network
                                         ^       +--------+
       +-----+            +-----+        |
       | Mss |<-----------| BS2 |--------+
       +-----+            +-----+
                                      <---> IP termination
                 Fig. 6  Scenario C




Shin & Jang              Expires August 27, 2006               [Page 12]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


7.3.1.  Unicast Transmission

   o Outbound unicast packet from the MS is always forwarded on a
   particular transport connection in the uplink direction to the BS.

   o When BS receives the packet destined to same subnet from MS but not
   to AR, the uplink CID is replaced with the corresponding downlink CID
   (which may be associated with the specified Ethernet addresses in
   Ethernet CS or IP addresses in Ethernet/IP CS), then forwarded to
   downlink.

   o Otherwise, BS decapsulates the 802.16 header and forwards the
   packet to AR. .  In case of Ethernet CS, it will be delivered to the
   AR naturally since the destination address in Ethernet header is the
   AR's address.  In case of IP CS, the BS is responsible to deliver it
   with the proper Ethernet header.  AR performs routing and then
   forwards it to other BS or edge router according to the routing
   result.

7.3.2.  Multicast Transmission

   o Outbound unicast packets from the MS are always forwarded on a
   particular transport connection in the uplink direction to the BS.

   o When BS/AR receives the multicast packet with link-local scope from
   MS, it sends back the packet to the downlink by using CID for
   multicast.  It also sends the packet to an AR after decapsulating
   802.16 header.

   o When BS/AR receives the multicast packet with non-link-local scope
   from MS, the packet is sent back to the downlink by using CID for
   multicast.  It is also sent to the AR based after decapsulating
   802.16 header.  In case of Ethernet CS, it will be delivered to the
   AR naturally since the destination address in Ethernet header is the
   multicast address.  In case of IP CS, the BS is responsible to
   deliver it with the proper Ethernet header.  AR looks up the IPv6
   multicasting routing table and then forwards the packets to other BSs
   or edge router according to the result.

7.4.  Scenario D

   Scenario D represents IEEE 802.16 network deployment where a BS is
   separated from a router, and a subnet consists of multiple BS and
   multiple MSs.







Shin & Jang              Expires August 27, 2006               [Page 13]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


       +-----+                        +-----+    +-----+    ISP 1
       | MS1 |<-----+              +->| AR1 |----| ER1 |===>Network
       +-----+      |              |  +-----+    +-----+
       +-----+      |     +-----+  |
       | MS2 |<-----+-----| BS1 |--|
       +-----+            +-----+  |  +-----+    +-----+    ISP 2
                                   +->| AR2 |----| ER2 |===>Network
       +-----+            +-----+  |  +-----+    +-----+
       | Ms3 |<-----------| BS2 |--+
       +-----+            +-----+
                                          <---> IP termination
                        Fig. 7  Scenario D

7.4.1.  Unicast Transmission

   o Outbound unicast packet from the MS is always forwarded on a
   particular transport connection in the uplink direction to the BS.

   o If BS receives the packet destined to same subnet and to MS under
   the serving BS, the uplink CID is replaced with the corresponding
   downlink CID (which may be associated with the specified Ethernet
   addresses in Ethernet CS or IP addresses in Ethernet/IP CS),

   o Otherwise, BS decapsulates the 802.16 header and forwards the
   packet onto the wired network.  In case of Ethernet CS, if the packet
   is destined to one of ARs, it will be delivered to the AR naturally
   since the destination address in Ethernet header is the AR's address.
   If the packet is destined to MS under other BS, the target BS under
   which the MS exists should catch this packet instead by acting as a
   proxy of the MS and send it to MS by using corresponding downlink
   CID.  In case of IP CS, if the packet is destined to one of ARs, the
   BS is responsible to deliver it with the proper Ethernet header.  If
   the packet is destined to MS under other BS, the target BS should
   catch this packet instead by acting as a proxy of the MS and send it
   to MS by using corresponding downlink CID.

7.4.2.  Multicast Transmission

   o Outbound unicast packets from the MS are always forwarded on a
   particular transport connection in the uplink direction to the BS.

   o When BS receives the multicast packet with link-local scope from
   MS, it sends back the packet to the downlink by using CID for
   multicast.  It also sends the packet onto the wired network after
   decapsulating 802.16 header.  ARs will get this, and other BSs will
   receive this and send it by using CID for multicast.

   o When BS receives the multicast packet with non-link-local scope



Shin & Jang              Expires August 27, 2006               [Page 14]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


   from MS, it sends back the packet to the downlink by using CID for
   multicast.  It also sends the packet onto the wired network after
   decapsulating the 802.16 header.  Other BSs will receive this and
   send it by using CID for multicast.  The multicast router receiving
   this will look up the IPv6 multicasting routing table and then
   forwards the packets to edge router according to the result.













































Shin & Jang              Expires August 27, 2006               [Page 15]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


8.  IANA Considerations

   This document requests no action by IANA.
















































Shin & Jang              Expires August 27, 2006               [Page 16]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


9.  Security Considerations

   TBD
















































Shin & Jang              Expires August 27, 2006               [Page 17]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


10.  References

10.1.  Normative References

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

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

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

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC1972]  Crawford, M., "A Method for the Transmission of IPv6
              Packets over Ethernet Networks", RFC 1972, August 1996.

10.2.  Informative References

   [I-D.shin-ipv6-ieee802.16]
              Shin, M., "Scenarios and Considerations of IPv6 in IEEE
              802.16 Networks", draft-shin-ipv6-ieee802.16-01 (work in
              progress), October 2005.

   [I-D.mandin-ip-over-80216-ethcs]
              Mandin, J., "Transport of IP over 802.16",
              draft-mandin-ip-over-80216-ethcs-00 (work in progress),
              October 2005.

   [IEEE802.16]
              "IEEE 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 802.16e/D10 Draft, IEEE Standard for Local and
              metropolitan area networks, Part 16: Air Interface for
              Fixed and Mobile Broadband Wireless Access Systems
              Amendment for  Physical and Medium Access Control Layers
              for Combined Fixed and Mobile Operation in Licensed
              Bands", August 2005.







Shin & Jang              Expires August 27, 2006               [Page 18]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


Authors' Addresses

   Myung-Ki Shin
   ETRI
   161 Gajeong-dong Yuseng-gu
   Daejeon, 305-350
   Korea

   Phone: +82 42 860 4847
   Email: myungki.shin@gmail.com


   Hee-Jin Jang
   Samsung AIT
   P.O. Box 111
   Suwon 440-600
   Korea

   Email: heejin.jang@samsung.com
































Shin & Jang              Expires August 27, 2006               [Page 19]


Internet-Draft  IPv6 Packet Transmission over IEEE 802.16  February 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Shin & Jang              Expires August 27, 2006               [Page 20]