One document matched: draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
Network Working Group H. Jeon
Internet-Draft ETRI
Intended status: Standards Track M. Riegel
Expires: June 4, 2007 Siemens
S. Jeong
ETRI
Dec 2006
Transmission of IP over Ethernet over IEEE 802.16 Networks
draft-ietf-16ng-ip-over-ethernet-over-802.16-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 June 4, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
This document describes the behavior of the Ethernet emulation on top
of IEEE 802.16 to efficiently support the transmission of IPv4 as
well as IPv6 packets over IEEE 802.16 radio links. Due to resource
constraints of radio transmission systems and the limitations of the
IEEE 802.16 MAC layer for the emulation of Ethernet, the transmission
Jeon, et al. Expires June 4, 2007 [Page 1]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
of IP over an emulated LAN on top of IEEE 802.16 may considerably
benefit by adding IP specific support functions within the Ethernet
emulation on top of IEEE 802.16.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . . 4
4.1. Connection Oriented Air Interface . . . . . . . . . . . . 4
4.2. Convergence Sublayers . . . . . . . . . . . . . . . . . . 4
4.3. Multicast and Broadcast Support in IEEE 802.16 . . . . . . 5
4.4. Discovery of MAC addresses . . . . . . . . . . . . . . . . 5
5. The IEEE 802.16 Network Model for Ethernet . . . . . . . . . . 5
5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 5
5.2. Ethernet without Native Broadcast and Multicast Support . 6
5.3. Default Processing of Ethernet Frames . . . . . . . . . . 6
6. Deployment Scenarios for IP over Ethernet over IEEE 802.16 . . 7
6.1. Public Access Scenario . . . . . . . . . . . . . . . . . . 7
6.2. VLAN Scenario . . . . . . . . . . . . . . . . . . . . . . 8
7. Filtering and Forwarding . . . . . . . . . . . . . . . . . . . 8
7.1. IP Broadcast and Multicast Support . . . . . . . . . . . . 8
7.2. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 8
7.3. Identification Cache Table . . . . . . . . . . . . . . . . 9
7.4. Address Resolution Protocol Proxy Function . . . . . . . . 10
7.5. Neighbor Discovery Relay Function . . . . . . . . . . . . 10
7.6. Access Router Behavior . . . . . . . . . . . . . . . . . . 11
8. Transmission of IP over Ethernet . . . . . . . . . . . . . . . 11
8.1. IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 12
8.1.1. Address Resolution . . . . . . . . . . . . . . . . . . 12
8.2. IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 12
8.2.1. Router Discovery, Prefix Discovery and Parameter
Discovery . . . . . . . . . . . . . . . . . . . . . . 12
8.2.2. Address Configuration . . . . . . . . . . . . . . . . 13
8.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 13
8.3. Maximum Transmission Unit Consideration . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Jeon, et al. Expires June 4, 2007 [Page 2]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
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 by adopting the same data link principles also for mobile
networking systems.
This document provides a detailed description of the Ethernet
emulation on top of IEEE 802.16 with additional functionalities for
efficient support of IPv4 packets as well as IPv6 packets.
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
Description of following some terms is taken directly from
[IEEE802.16] and [IEEE802.16e].
Base Station (BS): A generalized equipment set providing
connectivity, management, and control of the 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
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.
Connection Identifier (CID): A 16 bit value that identifies a
connection to equivalent peers in the MAC of the base station and
subscriber station.
Source Node: Host which initiates an IPv6 Neighbor Discovery message
using its own unique MAC address. A Source Node may be co-located
with a SS or may be behind a SS, when the SS acts as a bridge.
Jeon, et al. Expires June 4, 2007 [Page 3]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
Target Node: Host which is addressed by the target field in an IPv6
Neighbor Discovery message. The Target Node has its own unique
MAC address and may be co-located with a SS or may be behind a SS,
when the SS acts as a bridge
4. The IEEE 802.16 Link Model
4.1. Connection Oriented Air Interface
The IEEE 802.16 MAC provides connections between a BS and its
associated SSs. Each of these connections is identified by a 16 bit
CID number and has defined QoS capabilities. Multiple connections
can be established between a BS and a SS, each with its particular
QoS class and direction.
| | | |
+--+--+ +--+--+ +--+--+ +--+-+-+--+
| 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
While uplink connections provide only unicast transmission
capabilities from a particular SS to the BS, downlink connections can
be used for multicast transmissions to a group of SSs as well as for
unicast transmission from the BS to a particular SS.
4.2. Convergence Sublayers
The assignment of higher layer packets to particular service flows
and the related CIDs is performed within the IEEE 802.16 convergence
sublayer by classifying the packets according to particular header
fields. To enable the transmission of different kind of payloads
over IEEE 802.16, multiple types of classification types are defined,
each specific for one kind of upper layer protocol, like Ethernet,
IPv4, IPv6 or even for encapsulated payload, like IPv4 over Ethernet
or IPv6 over Ethernet.
Optionally the convergence sublayer performs a packet header
Jeon, et al. Expires June 4, 2007 [Page 4]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
suppression reducing static parts of the header to a single byte
value. With the application of the packet header suppression
function there is mostly no difference in header overhead over the
air for Ethernet encapsulated IP packets in comparison to plain IP
packets.
4.3. Multicast and Broadcast Support in IEEE 802.16
Downlink connections can be shared among multiple SSs, enabling
multicast channels with multiple SSs receiving the same information
from the BS. Multicast is not enabled in the uplink but must be
realized by an entity on top the IEEE 802.16 MAC sending packets
received on a unicast uplink downstream on a multicast channel.
4.4. Discovery of MAC addresses
The 48-bit unique MAC address of a SS is used during the initial
ranging process for the identification of a SS and verified by the
succeeding PKMv2 authentication phase. As a result, the BS
establishes a list of MAC addresses of all SSs connected to the BS.
Note that there may be additional MAC addresses behind SSs when SSs
act as bridge connecting networks behind the SSs. The additional MAC
addresses may be also discovered when there is a controlled link
state for the hosts behind the SS and the SS performs authentication
of the link, e.g. by running IEEE 802.1X on the SS.
BS can construct link local address of each SS from adding prefix
"FE80::/64" to last 24 bits of MAC address corresponding to the each
SS and also derive solicited-node MAC address of each SS from prefix
"33-33-FF" and last 24 bits of each SS's MAC address.
5. The IEEE 802.16 Network Model for Ethernet
5.1. IEEE 802.16 Ethernet Link Model
According to [I-D.ietf-ipv6-2461bis], 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 on
top of IEEE 802.16 by implementing bridging between all SSs with IEEE
802.16 providing the links between the hosts and the bridge behind
the BS like the twisted pair wires used in today's switched Ethernet.
Jeon, et al. Expires June 4, 2007 [Page 5]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
------------------------ IP Link ------------------------
| | | | |
ETH ETH ETH ETH ETH
| | | | |
| | +---------+---------+ | |
| | | 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 IP over Ethernet Link Model
It is possible to control the size and coverage of IP links by
segmenting the Ethernet and grouping particular links into VLANs.
Such segmentation is mostly done between BSs, but it is also possible
to extend the segmentation over IEEE802.16 links when multiple hosts
are attached to a bridge at the SS.
5.2. Ethernet without Native Broadcast and Multicast Support
Ethernet is emulated on top of IEEE 802.16 without making use of MBS
as defined in 6.3.23 of [IEEE802.16e] to allow full control over the
reaction of SSs to broadcast messages. Instead of using MBS,
broadcast and multicast messages are transferred in a unicast manner.
5.3. Default Processing of Ethernet Frames
The BS SHALL forward all the radio connections belonging to one SS to
a port of a bridge between all ports on the radio side and the
interfaces towards the network side. If the SS functions as a bridge
then it SHALL support a bridging between all its LAN ports and the
airlink.
When performing Learning Process specified in [IEEE802.1D], the
bridge or the SS that performs bridging function shall learn all
source MAC addresses originating from a port. This enables the
bridge or the SS to construct Dynamic Filtering Entries if the same
Jeon, et al. Expires June 4, 2007 [Page 6]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
MAC addresses are not already listed as Static Filtering Entries.
The information in the Dynamic Filtering Entry shall be automatically
unlearned after BRIDGETIMEOUT seconds have expired without any
traffic from that MAC address. The dynamic information on all
learned MAC to port associations and static information in Static
Filtering Entries constitute the Filtering Database. Bridge decides
to which ports of the bridge a frame should be forwarded by querying
the Filtering Database.
When performing bridging, any packets destined for one of the
addresses in the Filtering Database SHALL be forwarded directly to
that port, if appropriate for the particular scenario, and all
packets received from a port, for which the packet's destination MAC
address is also an entry for that port in the Filtering Database,
SHALL be silently discarded.
6. Deployment Scenarios for IP over Ethernet over IEEE 802.16
Figure 3 and 4 show possible deployment scenarios in case of IP over
Ethernet over IEEE 802.16. In both figures, the AR is connected to a
bridge, which is connected to all BSs. The bridge supports Static
Filtering Entries and Standard Learned Bridging, as specified in
Section 5.3. Multiple ARs can exist on a link, and a subnet (IP
Link) consists of multiple hosts usually being co-located with a SS
acting as bridge. The network behind a SS can support various access
network technologies, e.g. 802.3, 802.11 or 802.15.
6.1. Public Access Scenario
Figure 3 depicts an IEEE 802.16 network deployment scenario without
direct host-to-host communication. In the general public access
case, direct communication between nodes is restricted because of
security and accounting issues. In this scenario, the bridge SHALL
forward all packets received from any radio side port to a network
side port. Peer-to-peer communication is not supported by the bridge
and all packets originated from a SS should be delivered to an AR.
+-----+ +-----+ +-------+
| SS |----| BS1 |------| | +------+
+-----+ +-----+ | |-------| AR |
|Bridge | +------+
+-----+ +-----+ +-----+ | |
|Hosts|--| SS |----| BS2 |------| |
+-----+ +-----+ +-----+ +-------+
Jeon, et al. Expires June 4, 2007 [Page 7]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
Figure 3. Network Model without direct host-to-host communication
6.2. VLAN Scenario
Figure 4 shows the VLAN scenario. Particular SSs grouped into a VLAN
can directly communicate with each other when this model is enabled
for the VLAN. Otherwise, direct communication is prohibited and the
VLAN shows the same behavior as the public access scenario. The
bridge has been extended to support VLAN capability and configurable
direct host-to-host communication.
+-----+ +-----+ +-------+
| SS |----| BS1 |------| | +------+
+-----+ +-----+ |Bridge |-------| AR |
|(VLAN) | +------+
+-----+ +-----+ +-----+ | |
|Hosts|--| SS |----| BS2 |------| |
+-----+ +-----+ +-----+ +-------+
Figure 4. Network Model with direct host-to-host communication
7. Filtering and Forwarding
7.1. IP Broadcast and Multicast Support
IP broadcast and multicast data are replicated and then transferred
in a unicast manner without using native MBS support as explained in
Section 5.2.
Unicast 802.16 transport connections are extended to a bridge by any
tunneling mechanism such as GRE tunnel between BSs and the bridge.
As a result, point-to-point connections have been established between
a bridge and each SSs.
IP Broadcast and multicast data shall be carried to the intended SSs
via the tunnels and unicast 802.16 transport connections.
7.2. Packet Filtering
The bridge SHALL have the ability to enable or disable any filtering
functionality defined herein. If a packet is filtered it SHALL be
silently discarded. The filtering functionality is based on the
information in the Identification Cache Table (ICT) defined in
Section 7.3.
Jeon, et al. Expires June 4, 2007 [Page 8]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
The bridge SHALL support filtering of all packets received from a
network side port to a destination MAC address or Multicast IP
address not existing in the ICT or expired address.
The bridge SHALL support filtering of all packets received from a
network side port to a broadcast or all-nodes multicast MAC address.
If filtering is enabled the bridge SHALL permit all Address
Resolution Protocol messages to pass to the ARP Proxy Agent and all
Neighbor Discovery messages to pass to the Neighbor Discovery (ND)
Relay Agent for additional processing as specified in following
section.
7.3. Identification Cache Table
The bridge establishes and maintains information about each SS by the
mean of an Identification Cache Table (ICT), which is an extension of
the Filtering Database. Note that the bridge in this document
supports IGMP/MLD Snooping [RFC4541].
For IPv4 over Ethernet, ICT contains MAC address and Port Map, which
constitute a filtering entry in Filtering Database, tunnel ID,
lifetime, and one or more unicast and multicast IPv4 addresses. The
unicast IPv4 addresses can be learned by examining the source address
of packets or DHCP Response message. The multicast IPv4 address can
be added and removed by snooping IGMP Membership Report and Leave
Group messages from SS.
For IPv6 over Ethernet, ICT includes one or more unicast IPv6
addresses with associated Valid Flags and multicast IPv6 address in
addition to MAC address, Port Map, tunnel ID, and lifetime in ICT for
IPv4 over Ethernet. In case of stateful address configuration, the
unicast IPv6 addresses can be learned by examining the source address
of packets or DHCP message. In stateless address autoconfiguration,
the unicast IPv6 address is learned by extracting the Target field in
the Neighbor Solicitation (NS) message for Duplicate Address
Detection (DAD), if the tentative IPv6 address does not exist yet as
a valid IPv6 address in the ICT. In this case, the Valid Flag is set
to indicate the tentative IPv6 address has become valid. Otherwise,
the IPv6 address in the Target field in a DAD NS message is stored as
IPv6 address with Valid Flag is not set to identify the Source Node
when the bridge relays the Neighbor Advertisement message from Target
Node. The multicast IPv6 address can be added and removed by
snooping MLD Report and Done messages from SS.
The tunnel ID identifies tunnels between bridge and BSs which
construct the point-to-point connection between bridge and SS with
IEEE 802.16 unicast connection. GRE key can be one of the tunnel ID.
Jeon, et al. Expires June 4, 2007 [Page 9]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
The lifetime is similar to Ageing Time in [IEEE802.1D]. It has
elapsed since the corresponding entry was added and it is refreshed
by continuous traffic from the MAC address. The default value of the
lifetime is set by management.
The ARP Proxy Agent and the ND Relay Agent functions are based on
information contained in the ICT. Figure 5 and Figure 6 show the ICT
for IPv4 over Ethernet and IPv6 over Ethernet.
+---------+--------+-------+------+-------+---------+
| MAC | Port |Tunnel | Life |Unicast|Multicast|
| address | MAP | ID | time |address| address |
+---------+--------+-------+------+-------+---------+
| | | | | | |
+---------+--------+-------+------+-------+---------+
Figure 5. ICT on Bridge in case of IPv4 over Ethernet
+-------+------+------+-----+---------+-----+----------+
| MAC | Port |Tunnel|Life | Unicast |Valid| Multicast|
|address| MAP | ID |time | address |Flag | address |
+-------+------+------+-----+---------+-----+----------+
| | | | | | | |
+-------+------+------+-----+---------+-----+----------+
Figure 6. ICT on Bridge in case of IPv6 over Ethernet
7.4. Address Resolution Protocol Proxy Function
In the case of IPv4 over Ethernet, ARP requests can be responded by
the ARP Proxy Agent of the bridge. (refer to Section 8.1.1 for more
detail)
However, a proxy function in IPv6 over Ethernet is subjected to
restriction because of security issues. Support of SeND [RFC3971]
has been adopted in the IPv6 over Ethernet case.
7.5. Neighbor Discovery Relay Function
In the case of IPv6 over Ethernet, the AR sends periodically Router
Advertisement and the Router Advertisement messages can be relayed by
the ND Relay Agent of the bridge. The ND Relay Agent unicasts the
Router Advertisement via all the already established a point-to-point
Jeon, et al. Expires June 4, 2007 [Page 10]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
connections between bridge and SSs.
When the bridge receives Neighbor Solicitation for DAD, the ND Relay
Agent of the bridge performs the same operation as the Relay DAD.
The ND Relay Agent looks up in the ICT to detect whether a tentative
address in the Neighbor Solicitation message is in use or not. If
the tentative address is not in use, the ND Relay Agent discards the
Neighbor Solicitation. Otherwise, the Neighbor Solicitation message
is relayed only to the addressed Target Node.
When the bridge receives the DAD Neighbor Advertisement message from
the Target Node, the ND Relay Agent of the bridge identifies the
corresponding Source Node by the ICT and then unicasts the DAD
Neighbor Advertisement message via the established point-to-point
connection to the corresponding Source Node.
7.6. Access Router Behavior
The assignment of a common prefix to all SSs means locating them "on-
link" in terms of IP packet transfer. According to
[I-D.ietf-ipv6-2461bis], an IP node performs a longest prefix match
against the prefix list in order to decide whether the destination of
the IP packet is on-link or not. Therefore, SSs sharing a prefix can
be said to be on-link IP nodes.
In the Public Access scenario, all unicast packets originated from a
SS should be delivered to an AR even though the SS sends packets to
on-link SSs. Therefore, it is necessary for the AR to relay the on-
link packets.
The AR SHALL have packet-relay functionality. The AR relays packets
destined for IP broadcast address and link-local scoped multicast
addresses to incoming interface again. When relaying, AR does not
decrease the value of TTL or Hop Limit.
When the AR relays packets destined for on-link host, the packet may
be forwarded onto the incoming interface. It should be prevented
that the AR transmits a Redirect message to sender when direct
communication between on-link SSs occurs.
In the case of the VLAN scenario, direct communication between SSs
may be enabled for all SSs belonging to a particular VLAN. In this
case, no special handling is required.
8. Transmission of IP over Ethernet
Jeon, et al. Expires June 4, 2007 [Page 11]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
8.1. IPv4 over Ethernet
[RFC0894] defines the transmission of IP packets over Ethernet
networks. It contains the specification of the encapsulation of the
IP packets into Ethernet frames as well as rules for mapping of IP
addresses onto Ethernet MAC addresses. The use of ARP [RFC0826] is
recommended for dynamic address resolution.
8.1.1. Address Resolution
The bridge SHALL support an ARP Proxy. The bridge SHALL have the
ability to enable or disable the ARP Proxy.
If the ARP Proxy is disabled, the ARP Proxy Agent shall pass all ARP
packets without discrimination or modification using bridging. The
ARP Proxy Agent shall pass all ARP Response packets without
discrimination or modification using bridging.
If the ARP Proxy is enabled, upon receiving an ARP Request from an
radio side interface, the ARP Proxy Agent shall unicast an ARP
Response back to the interface provided that the target address
matches an entry in the ICT. Otherwise, the ARP Proxy Agent shall
flood the ARP Request to all network side interfaces, that are in a
forwarding state.
The ARP Proxy Agent shall silently discard any received self-ARP
Requests. Those are requests for a target IP address, that when
queried in the ICT results in a response MAC equal to the Request's
source MAC address.
The ARP Proxy Agent shall issue a gratuitous ARP on the network side
interfaces for any new addition to the ICT. An unsolicited broadcast
ARP Response constitutes a gratuitous ARP.
8.2. IPv6 over Ethernet
The transmission of IPv6 Packets over Ethernet Networks is defined by
[RFC2464] providing the frame format for encapsulation of IPv6
packets into Ethernet frames.
8.2.1. Router Discovery, Prefix Discovery and Parameter Discovery
Router Discovery, Prefix Discovery and Parameter Discovery procedures
are achieved by receiving Router Advertisement (RA) messages. The RA
is forwarded by using all-nodes IP multicast transmission.
This document assumes a point-to-point connection between each SS and
bridge. The ND Relay Agent of the bridge unicast the RA from AR via
Jeon, et al. Expires June 4, 2007 [Page 12]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
the point-to-point connection.
Note that the RA has a long lifetime and minimum packet size which
can be sent in IEEE 802.16 to the SSs being in sleep-mode during the
periodic wakeup-time.
8.2.2. Address Configuration
8.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.
8.2.2.2. Stateless Address Autoconfiguration
The global IPv6 addresses is derived based on prefix and EUI-64-
derived interface identifier and then confirmed through Duplicate
Address Detection (DAD) as specified in [RFC2462].
For DAD, the Source Node sends Neighbor Solicitation to the
solicited-node MAC address corresponding to the generated global IPv6
address for DAD. The Neighbor Solicitation is passed to the ND Relay
Agent when arriving at the bridge.
8.2.3. Address Resolution
The Source Node sends Neighbor Solicitation to the solicited-node
address corresponding to the target address for address resolution.
Upon receiving the Neighbor Solicitation, the bridge retrieves the
port corresponding to the solicited-node MAC address in its ICT and
then forwards the Neighbor Solicitation via that port.
Finally the Target Node responds to the Neighbor Solicitation.
8.3. Maximum Transmission Unit Consideration
When stacked VLAN headers are transferred over GRE tunnels, the sizes
of the VLAN headers and the GRE header need to be considered in
setting the value of MTU of the transport path.
9. Security Considerations
[RFC3971] specifies security mechanisms for ND Protocol and defines
means for securing ND Protocol messages. This document aims to fully
support security mechanisms specified in [RFC3971].
Jeon, et al. Expires June 4, 2007 [Page 13]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
10. Acknowledgement
We would like to express special thanks to David Johnston and Dave
Thaler for their inputs to this work.
11. Informative References
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-09 (work in progress),
October 2006.
[I-D.jee-16ng-ps-goals]
Jee, J., "IP over 802.16 Problem Statements and Goals",
draft-jee-16ng-ps-goals-00 (work in progress),
February 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, "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.1D]
IEEE Std 802.1D-2004, "IEEE Standard for Local and
metropolitan area networks, Media Access Control (MAC)
Bridges", June 2004.
[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.
Jeon, et al. Expires June 4, 2007 [Page 14]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
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
Jeon, et al. Expires June 4, 2007 [Page 15]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
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 June 4, 2007 [Page 16]
Internet-Draft IPoEth over IEEE 802.16 Dec 2006
Full Copyright Statement
Copyright (C) The IETF Trust (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, 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 June 4, 2007 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 04:35:43 |