Network Working Group HS. Jeon
Internet-Draft ETRI
Intended status: Standards Track M. Riegel
Expires: September 5, 2007 Siemens
SJ. Jeong
ETRI
March 4, 2007
Transmission of IP over Ethernet over IEEE 802.16 Networks
draft-ietf-16ng-ip-over-ethernet-over-802.16-01.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 September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the transmission of IPv4 as well as IPv6 over
Ethernet in a network deploying the IEEE 802.16 cellular radio
transmission technology. The Ethernet on top of IEEE 802.16 is
realized by bridging between the point-to-point radio links, which
are provided by IEEE 802.16 between the base station and its
Jeon, et al. Expires September 5, 2007 [Page 1]
Internet-Draft IPoEth over IEEE 802.16 March 2007
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 an Ethernet over IEEE 802.16 may considerably benefit by
adding IP specific support functions in the Ethernet over IEEE 802.16
while maintaining full compatibility with standard IP over Ethernet
behavior.
Jeon, et al. Expires September 5, 2007 [Page 2]
Internet-Draft IPoEth over IEEE 802.16 March 2007
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. The IEEE 802.16 Network Model for Ethernet . . . . . . . . . . 6
5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 6
5.2. Ethernet without Native Broadcast and Multicast Support . 7
5.3. Segmenting the Ethernet into VLAN . . . . . . . . . . . . 8
5.4. Deployment Scenarios for IP over Ethernet over IEEE
802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Public Access Scenario . . . . . . . . . . . . . . . . 8
5.4.2. Enterprise LAN Scenario . . . . . . . . . . . . . . . 9
6. Bridge Considerations . . . . . . . . . . . . . . . . . . . . 10
6.1. Multicast and Broadcast Packet Processing . . . . . . . . 10
6.1.1. Multicast Transmission Considerations . . . . . . . . 10
6.1.2. Broadcast Transmission Considerations . . . . . . . . 11
6.2. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Public Access Scenario Case . . . . . . . . . . . . . 12
6.2.2. Enterprise LAN Scenario Case . . . . . . . . . . . . . 12
7. Access Router Considerations . . . . . . . . . . . . . . . . . 12
8. Prefix Assignment . . . . . . . . . . . . . . . . . . . . . . 12
8.1. IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 12
8.2. IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 13
9. Transmission of IP over Ethernet . . . . . . . . . . . . . . . 13
9.1. IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 13
9.1.1. Address Configuration . . . . . . . . . . . . . . . . 13
9.1.2. Address Resolution . . . . . . . . . . . . . . . . . . 13
9.2. IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 14
9.2.1. Router Discovery, Prefix Discovery and Parameter
Discovery . . . . . . . . . . . . . . . . . . . . . . 14
9.2.2. Address Configuration . . . . . . . . . . . . . . . . 14
9.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 14
9.3. Maximum Transmission Unit Consideration . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Jeon, et al. Expires September 5, 2007 [Page 3]
Internet-Draft IPoEth over IEEE 802.16 March 2007
1. Introduction
IEEE 802.16 [IEEE802.16] defines a point-to-multipoint radio
transmission system connecting a Base Station (BS) with multiple
Subscriber Stations (SSs). IEEE 802.16e [IEEE802.16e] amends the
base specification with PHY and MAC functions for supporting mobile
terminals while adopting the same data link principles also for
mobile networking systems.
This document describes the transmission of IPv4 as well as IPv6 over
Ethernet in a network deploying the IEEE 802.16 cellular radio
transmission technology. The Ethernet on top of IEEE 802.16 is
realized by bridging between the point-to-point radio links, which
are provided by IEEE 802.16 between the base station and its
associated subscriber stations.
Due to the resource constraints of radio transmission systems and the
particularities of the IEEE 802.16 MAC for the realization of
Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may
considerably benefit by adding IP specific support functions in the
Ethernet over IEEE 802.16 while maintaining full compatibility with
standard IP over Ethernet behavior.
2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
Access Router (AR): An entity that performs an IP routing function
to provide IP connectivity for Subscriber Stations.
Base Station (BS): A generalized equipment sets providing
connectivity, management, and control of the subscriber station.
Connection Identifier (CID): A 16 bit value that identifies a
connection to equivalent peers in the MAC of the base station and
subscriber station.
Subscriber Station (SS): A generalized equipment set providing
connectivity between subscriber equipment and a base station.
Within this document the term SS also represents the Mobile
Subscriber Station introduced in IEEE 802.16e
Jeon, et al. Expires September 5, 2007 [Page 4]
Internet-Draft IPoEth over IEEE 802.16 March 2007
Service-specific Convergence Sublayer (CS): Sublayer in the IEEE
802.16 MAC layer which classifies external network data and
associates them to the proper MAC service flow identifier and
connection identifier.
4. The IEEE 802.16 Link Model
4.1. Connection Oriented Air Interface
The IEEE 802.16 MAC establishes multiple 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. Despite of the BS and
all the SS are identified by unique 48bit MAC addresses, packets
going over the air are only carrying 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. Unique cryptographic keys are generated during the
initial authentication phase between the BS and each of the
associated SSs to protect the data transmission over the air.
While uplink connections from the SSs to the BS provide only unicast
transmission capabilities from, downlink connections can be used for
unicast transmission from the BS to a single SS as well as for
multicast transmissions to a group of SSs.
| | | | | |
+--+--+ +--+--+ +--+--+ +--+-+-+--+
| MAC | | MAC | | MAC | | MAC |
+-----+ +-----+ +-----+ +---------+
| PHY | | PHY | | PHY | | PHY |
+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+
| | | | | | | | | |
| +-------|-+-------|-+----CID#w----+ | | |
| | +------CID#x------+ | |
| +----------------CID#y--------+ |
+--------------------------CID#z----------+
SS#1 SS#2 SS#3 BS
Figure 1. Basic IEEE 802.16 Link Model
Jeon, et al. Expires September 5, 2007 [Page 5]
Internet-Draft IPoEth over IEEE 802.16 March 2007
4.2. Feeding User Data into the Appropriate Connections
Assignment of higher layer packets to particular service flows and
related CIDs is performed by the convergence sublayer within the IEEE
802.16 MAC. It classifies the packets depending on the values of a
defined subset of the payload packet header fields and assigns the
packets to the appropriate service flow.
To enable the transmission of different kind of payloads over IEEE
802.16, multiple convergence sublayers are defined, each specific for
one kind of payload packet type, like Ethernet, IPv4, IPv6 or even
for encapsulated payload, like IPv4 over Ethernet or IPv6 over
Ethernet.
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 is verified by the
succeeding PKMv2 authentication phase. Out of it, the BS establishes
a list of MAC addresses of all SSs connected to the BS purely for MAC
management purposes.
While MAC addresses exist for all the SSs as well as the BS the
transfer of packets over the air is performed based only on the CID
value. It enables the transport of arbitrary source and destination
MAC addresses in Ethernet frames between a SS and its BS. This can
be leveraged when there are additional MAC addresses to the SS MAC
address in the case that the SS acts as an Ethernet bridge for a
network behind the SS.
Due to the defined mapping of the CIDs to the MAC address of the
associated SS, the BS is able to bundle all connections belonging to
a particular SS to a single connection on the network side to realize
a plain layer 2 forwarding behaviour in the BS.
5. The IEEE 802.16 Network Model for Ethernet
5.1. IEEE 802.16 Ethernet Link Model
According to [RFC2461], an IP Link is defined as a communication
facility or medium over which nodes can communicate at the link
layer, i.e. the layer immediately below IP. IEEE 802.16 provides
point-to-point connections between SSs and the BS without enabling
any direct SS to SS connectivity.
Ethernet is realized over IEEE 802.16 by implementing bridging
between all SSs with the IEEE 802.16 radio transmission system
Jeon, et al. Expires September 5, 2007 [Page 6]
Internet-Draft IPoEth over IEEE 802.16 March 2007
providing the point-to-point connections between the hosts and the
bridge behind the BS. This is equivalent to today's switched
Ethernet with twisted pair wires connecting the hosts to a bridge
("Switch") but in a IEEE 802.16 network the 'twisted pair wires' are
usually implemented by per SS connections between the BS and a
bridging function. The bridge must be able to create a new port
whenever a new SS attaches to any of the BSs of the network or to
remove a port when an associated SS detaches from the network.
The BS forwards all the service flow belonging to one SS to one radio
side port of a bridge behind the BSs. Not more than one SS should be
connected to a port of the bridge.
If the SS functions as a bridge for multiple hosts behind the SS
(i.e. SS#4 in the below figure) then it should support bridging
according to [IEEE802.1D] supporting efforts of [IEEE802.16k] between
all its LAN ports and the air link.
------------------------ IP Link --------------------------
| | | | | |
ETH ETH ETH ETH ETH ETH
| | | | | |
| | +---------+---------+ | +-+---+-+
| | | 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 [IEEE802.16][IEEE802.16e] does not define any
transport connection for IP broadcast and multicast data. Also,
Multicast and Broadcast Service (MBS, stated in 6.3.23 of
[IEEE802.16e]) cannot be used for the IP broadcast or multicast data
because MBS is invisible to IP layer. Hence IP broadcast and
Jeon, et al. Expires September 5, 2007 [Page 7]
Internet-Draft IPoEth over IEEE 802.16 March 2007
multicast packets should be replicated and then carried via unicast
transport connections as IEEE 802.16 access link. Bridge does the
replication.
5.3. 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 bridge behind the BSs must be enabled to support VLANs
according to [IEEE802.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 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 [IEEE802.1Q] frame format.
5.4. Deployment Scenarios for IP over Ethernet over IEEE 802.16
Figure 3 and 4 show the deployment scenarios in case of IP over
Ethernet over IEEE 802.16. In both figures, an AR is connected to a
bridge, which is connected to all BSs. The bridge becomes an
aggregation point for all the connections from SSs. Multiple ARs can
exist on a link, and an IP Link may consist of multiple hosts either
being co-located with a SS or behind a SS connected a bridge. The
network behind a SS can support various access network technologies,
e.g. 802.3, 802.11 or 802.15.
5.4.1. Public Access Scenario
Figure 3 depicts a public access scenario. In the general public
access case, direct communication between nodes is restricted because
of security and accounting issues and the AR is connected to a
network side port of the bridge behind the BSs.
In this scenario, the bridge forwards all packets received from any
radio side port to all network side ports being in the forwarding
state. Peer-to-peer communication is not supported by the bridge and
all packets originated from a SS should be delivered to an AR. The
AR performs a security filtering, policing and accounting of all
traffic from hosts, like a NAS (Network Access Server).
Jeon, et al. Expires September 5, 2007 [Page 8]
Internet-Draft IPoEth over IEEE 802.16 March 2007
+--+
|SS|
+--+*
*
* +----+
+--+ * | +-------+
|SS|* * * * **| BS +------+ \
+--+ * | +-----+ \ \ +---+
+--+ * +----+ \ \ +-+ B |
|SS|* \ +--+ R |
+--+ +---+ I | +----+
+----+ | D +---+ AR +--Internet
|Host+ +--+ G | +----+
+----+\ +----+ / +-+ E |
+----+ +------+--+ | +---+ / +---+
|Host+-+BRIDGE|SS|* * * *| BS | /
+----+ +------+--+ * | +---+
+----+/ * +----+
|Host+ +--+ *
+----+ |SS|*
+--+
Figure 3. Public Access Scenario
While the bridge forces all traffic from hosts to reach the AR, it
still performs Learning Process and maintains Filtering Database as
specified in [IEEE802.1D] and then forwards IP unicast packets from
the AR based on the Filtering Database. However, IP broadcast and
multicast packets are treated with special rules for Broadcast Data
Forwarding and Multicast Data Forwarding as stated in Section 6.1.
5.4.2. Enterprise LAN Scenario
The enterprise LAN scenario assumes trust relationship between all
hosts and thus enables hosts to directly communicate each other
without detouring. Multiple AR may be connected to a link, and ARs
may reside on both sides of the network, on the network side of the
bridge behind the BSs as well as behind a SS connected to a bridge.
Figure 4 depicts the enterprise LAN scenario network model.
IP unicast packets from either SSs or AR are forwarded by
[IEEE802.1D] based bridging, and IP broadcast and multicast packets
are processed on the bridge according to the Broadcast Data
Forwarding Rules and Multicast Data Forwarding Rules presented in
Section 6.1.
Jeon, et al. Expires September 5, 2007 [Page 9]
Internet-Draft IPoEth over IEEE 802.16 March 2007
+--+
|SS|
+--+*
* +----+
* +----+ +Host|
+--+ * | +-------+ /+----+
|SS|* * * * **| BS +------+ \ / +----+
+--+ * | +-----+ \ \ +---+/ ++Host|
+--+ * +----+ \ \ +-+ B + / +----+
|SS|* \ +--+ R ++
+----+ +--+ +---+ I | +----+
--+ AR ++ | D +---+ AR +---
+----+ \ +--+ G | +----+
\ +----+ / +-+ E |
+----+ +------+--+ | +---+ / +---+
|Host+-+BRIDGE|SS|* * * *| BS | /
+----+ +------+--+ * | +---+
+----+/ * +----+
|Host+ +--+ *
+----+ |SS|*
+--+
Figure 4. Enterprise LAN Scenario
6. Bridge Considerations
This section discusses operations of the bridge behind the BSs
6.1. Multicast and Broadcast Packet Processing
All multicast and multicast control messages shall be processed in
the bridge according to [RFC4541]. Broadcasting messages to all
radio side ports of the bridge SHOULD be prevented.
Further details on prevention of broadcasting messages to all radio
side ports are given in the following sections.
6.1.1. Multicast Transmission Considerations
Bridge copies the IP multicast packets, like IP broadcast, and
forwards into all its available ports, but an incoming port. As a
result, the IP multicast packets can be transmitted to SSs which do
not participate in the corresponding multicast group. This is why IP
multicast membership should be propagated between bridges
[RFC4541] describes Internet Group Management Protocol (IGMP) and
Jeon, et al. Expires September 5, 2007 [Page 10]
Internet-Draft IPoEth over IEEE 802.16 March 2007
Multicast Listener Discovery (MLD) snooping switches. The IGMP/MLD
snooping switches examine IGMP/MLD report messages and creates a
multicast address entry in its forwarding table. Followings
summarize two main processes of IGMP/MLD snooping switches (i.e.
bridge).
IGMP and MLD Forwarding Rules: A snooping switch that creates a new
multicast address entry in its forwarding table with received
report messages forwards the report messages only to those ports
where multicast routers are attached. The multicast entry can be
removed by receiving corresponding IGMP Leave Group/MLD Done
messages or timeout mechanism.
Multicast Data Forwarding Rules: Packets with a destination IP
address outside 224.0.0.0/24 in IPv4 or for IPv6 multicast address
with scope 2 or greater except FF02::1 (link-local scope all-nodes
multicast address) are forwarded according to the previously
created forwarding table and also forwarded on multicast router
ports. An unregistered IP multicast packets that does not match
any of entries in the forwarding table should be forwarded on
ports where multicast routers are attached.
6.1.2. Broadcast Transmission Considerations
Bridge floods the IP broadcast packets out of all connected ports
except that on which the packets was received. This behaviour in not
appropriate with scarce resources and dormant-mode hosts in a
wireless network such as IEEE 802.16 based access network. This
document defines following forwarding rules on bridges for filtering
the IP broadcast data. Note that packets destined for permanently
assigned multicast addresses such as 224.0.0.0/24 in IPv4 or FF02::1
in IPv6 are regarded as broadcast data.
Broadcast Data Forwarding Rules: The bridge discards all IP
broadcast packets except ARP, DHCP (DHCPv4 and DHCPv6), IGMP, and
MLD related traffic. The ARP, DHCP, IGMP and MLD related packets
received on radio side are forwarded only towards access router,
not another radio sides. On the other hand, the allowed IP
broadcast packets received on the network side are forwarded on
all ports except their incoming port.
6.2. Proxy ARP
Proxy ARP provides a process where a device connecting between hosts
answers ARP Requests instead of a remote host. In this document, the
Proxy ARP is used to force traffic from hosts to access router and
avoid broadcasting ARP Requests over the air depending on the
particular deployment scenario. A bridge behind the BSs performs the
Jeon, et al. Expires September 5, 2007 [Page 11]
Internet-Draft IPoEth over IEEE 802.16 March 2007
Proxy ARP process.
6.2.1. Public Access Scenario Case
A bridge behind the BSs filters broadcast ARP Requests and responds
to all the ARP Requests from radio side port with access router's
Ethernet address so that all IPv4 packets from SSs are forwarded to
the access router in the public access scenario. Learning the IP and
Ethernet address of the access router on bridge follows Section 3.1
in [RFC4562].
6.2.2. Enterprise LAN Scenario Case
The bridge behind the BSs maintains an ARP Cache. The ARP Cache has
a sufficient size to accommodate ARP entries for all its serving SSs
and is updated by any packets including ARP Requests from SSs like
its Filtering Database.
Upon receiving the ARP Requests from SSs, the bridge unicasts ARP
Replies back to SSs with Ethernet address of target host provided
that the target address matches an entry in the ARP Cache.
Otherwise, the bridge floods the ARP Requests. The bridge 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 situation, the access router may
forward packets via same interface on which the access router
received the packets. This results in Redirect message from the
access router [RFC0792][RFC2461]. Access router in the public access
scenario disables above the Redirect function on the interface to
which SSs attach.
8. Prefix Assignment
8.1. IPv4 over Ethernet
All SSs under the same AR share a single subnet prefix. Sharing the
prefix means locating all SSs on the same subnet and 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].
Jeon, et al. Expires September 5, 2007 [Page 12]
Internet-Draft IPoEth over IEEE 802.16 March 2007
8.2. IPv6 over Ethernet
In the enterprise LAN scenario, a single subnet prefix has an
advantage over multiple subnet prefixes in simplifying management.
However, assignment of unique prefix per SS can be considered in the
public access scenario because it forces all packets from SSs to be
transferred to an access router.
Access router assigns IPv6 prefixes with Prefix Information option as
specified in [RFC2461].
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. This document follows the
operations specified in [RFC0894].
9.1.1. Address Configuration
IPv4 addresses are 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 bridge filters 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 located on bridges as Layer 2 DHCP Relay Agent in
[TR101]. Bridge port number is possible as Circuit ID and Remote ID
may be left unspecified. Note that using option-82 has a requirement
that DHCP servers should be aware of the option-82.
9.1.2. Address Resolution
SSs use Address Resolution Protocol (ARP) [RFC0826] for finding a
destination's Ethernet MAC address.
Jeon, et al. Expires September 5, 2007 [Page 13]
Internet-Draft IPoEth over IEEE 802.16 March 2007
9.2. IPv6 over Ethernet
[RFC2464] defines transmission of IPv6 Packets over Ethernet
Networks. Encapsulation of IPv6 packets into Ethernet frames and
mapping rules for IPv6 address to Ethernet address (i.e. MAC
address) 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
document, SSs perform above the discovery process by solicited Router
Advertisement messages because periodic Router Advertisement messages
are discarded on the bridges 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,
an AR supports DHCPv6 server or relay function.
9.2.2.2. Stateless Address Autoconfiguration
The global IPv6 addresses are derived based on prefix and EUI-64-
derived interface identifier and then confirmed through Duplicate
Address Detection (DAD) as specified in [RFC2462].
9.2.3. Address Resolution
SS sends Neighbor Solicitation destined for solicited-node address
corresponding to the target address in order to determine MAC address
of a neighbor and then resolves the MAC address by receiving Neighbor
Advertisement as specified in [RFC2461].
9.3. Maximum Transmission Unit Consideration
[RFC2460] requires that link layer support a minimum Maximum
Transmission Unit (MTU) size of 1280 bytes and recommends the MTU of
at least 1500 bytes be configured for IPv6 over Ethernet
transmission. [RFC0894] also specifies 1500 bytes as a maximum
length of IPv4 over Ethernet. Therefore, IEEE 802.16 frame should
carry a payload size of 1518 bytes including the Ethernet header size
of 18 bytes or 1522 bytes including additional VLAN tag size of 4
bytes if present.
Jeon, et al. Expires September 5, 2007 [Page 14]
Internet-Draft IPoEth over IEEE 802.16 March 2007
The Length field in IEEE 802.16 MAC header has a size of 11 bits and
indicates length in bytes of the MAC PDU including CRC and MAC
header. Hence PDU size is up to 2048 bytes and the maximum size of
payload is 2038 bytes by subtracting size of CRC and MAC header from
2048 bytes. The maximum size of payload is sufficient to carry IPv4
over Ethernet or IPv6 over Ethernet and thus the MTU of IPv4 and IPv6
is the same as specified in [RFC0894] and [RFC2460] respectively.
10. 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.
11. Acknowledgments
We would like to express special thanks to David Johnston and Dave
Thaler for their inputs to this work.
12. References
[I-D.ietf-16ng-ps-goals]
Jee, J., "IP over 802.16 Problem Statement and Goals",
draft-ietf-16ng-ps-goals-01 (work in progress),
February 2007.
[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, "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", December 2005.
[IEEE802.16k]
IEEE 802.16's Network Management Task Group: 802.16k Pro
ject, "http://www.ieee802.org/netman/16k.html".
[IEEE802.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 September 5, 2007 [Page 15]
Internet-Draft IPoEth over IEEE 802.16 March 2007
[IEEE802.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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[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.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method
for Subscriber Separation on an Ethernet Access Network",
RFC 4562, June 2006.
Jeon, et al. Expires September 5, 2007 [Page 16]
Internet-Draft IPoEth over IEEE 802.16 March 2007
[TR101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation",
April 2006.
Authors' Addresses
HongSeok Jeon
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-3892
Email: jeonhs@etri.re.kr
Max Riegel
Siemens
St-Martin-Str 76
Munich, 81541
Germany
Phone: +49-89-636-75194
Email: maximilian.riegel@siemens.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 September 5, 2007 [Page 17]
Internet-Draft IPoEth over IEEE 802.16 March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jeon, et al. Expires September 5, 2007 [Page 18]