Internet DRAFT - draft-jeon-ipv6-ndp-ieee802.16
draft-jeon-ipv6-ndp-ieee802.16
Network Working Group H. Jeon
Internet-Draft J. Jee
Expires: December 28, 2006 ETRI
June 26, 2006
IPv6 NDP for Common Prefix Allocation in IEEE 802.16
draft-jeon-ipv6-ndp-ieee802.16-02.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 December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
IPv6 Neighbor Discovery Protocol [RFC 2461] assumes that the
underlying link layer support native multicast while IEEE 802.16 is a
point-to-multipoint network without bi-directional native multicast
support. Such a discordance between IPv6 Neighbor Discovery Protocol
and IEEE 802.16 network results in the on-link and multicast issues.
Jeon & Jee Expires December 28, 2006 [Page 1]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IPv6 Transmission Issues over IEEE 802.16 . . . . . . . . . . 4
4.1. On-Link Issue . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Multicast Issue . . . . . . . . . . . . . . . . . . . . . 5
5. IEEE 802.16 Network Model and IPv6 NDP Operations . . . . . . 5
5.1. IEEE 802.16 Network Model . . . . . . . . . . . . . . . . 5
5.2. IPv6 NDP Operations . . . . . . . . . . . . . . . . . . . 6
6. IPv6 Neighbor Discovery Support over IEEE 802.16 . . . . . . . 7
6.1. IP Convergence Sublayer . . . . . . . . . . . . . . . . . 7
6.2. Ethernet Convergence Sublayer . . . . . . . . . . . . . . 8
6.2.1. Identification Cache Table . . . . . . . . . . . . . . 8
6.2.2. Router Discovery, Prefix Discovery and Parameter
Discovery . . . . . . . . . . . . . . . . . . . . . . 9
6.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 9
6.2.4. Duplicate Address Detection . . . . . . . . . . . . . 9
7. Multicast Transmission Emulation . . . . . . . . . . . . . . . 10
7.1. Multicast Transmission Emulation using Common CID . . . . 10
7.2. Multicast Transmission Emulation using Replicated
Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Jeon & Jee Expires December 28, 2006 [Page 2]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
1. Introduction
IEEE 802.16 [IEEE 802.16][IEEE 802.16e] is a connection-oriented
broadband wireless access(BWA) technology. Down-stream in IEEE
802.16 is a point-to-multipoint connection and thus it is possible to
broadcast messages toward SS (Subscriber Station) from BS (Base
Station). However, up-stream is connected as point-to-point type.
Therefore, SS is not capable of multicasting as well broadcasting.
IPv6 Neighbor Discovery Protocol (IPv6 NDP) [RFC 2461] aims to solve
problems due to the interaction between nodes attached on the same
link. It is designed without dependence on a specific link layer
technology, but assumes that the link layer technology support a
native multicasting. As mentioned above, IEEE 802.16 supports
multicast and broadcast in down-stream. However, the original aim of
the multicast and broadcast is to transmit IEEE 802.16 MAC management
messages for bandwidth allocation, not IP data. Thus, IPv6 Neighbor
Discovery message on IEEE 802.16 cannot be delivered to neighboring
hosts by means of multicast.
IPv6 NDP messages have link-local scoped address as IP destination
address. It means those messages have to be delivered toward on-link
any hosts. However, when all SSs under same BS are configured with
common IPv6 network prefix, IEEE 802.16 disagrees with IPv6 Neighbor
Discovery on the definition of on-link host. This is because IPv6
NDP determines the on-link host with assigned prefixs while up-stream
in IEEE 802.16 is a point-to-point connection. IEEE 802.16 does not
allow direct communication among SSs even though each SS knows that
other SSs are neighboring ones at the IP level. Eventually, this
discrepancy results in limitation of transmission coverage of IPv6
NDP messages with link-local scoped address.
This document presents a mechanism which can allocate a common
network prefix to all SS under the same IPv6 link. Through the
mechanism, the standard IPv6 NDP can be applied to IEEE 802.16
networks without modifying conventional host-side operation.
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 [IEEE
Jeon & Jee Expires December 28, 2006 [Page 3]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
802.16] and [IEEE 802.16e].
BS (Base Station) : A generalized equipment set providing
connectivity, management, and control of the subscriber station.
SS (Subscriber Station) : A generalized equipment set providing
connectivity between subscriber equipment and a base station.
CS (Service-specific Convergence Sublayer) : Sublayer in IEEE 802.16
MAC layer which classifier external network data and associates them
to the proper MAC service flow identifier and connection identifier.
CID (Connection Identifier) : A 16 bit value that identifies a
connection to equivalent peers in the MAC of the base station and
subscriber station.
Source SS : SS which initiates IPv6 NDP message.
Target SS : SS which is identified with target field in IPv6 NDP
message.
Source BS : BS where Source SS is located.
Target BS : BS where Target SS is located.
DSA (Dynamic Service Addition) : The set of messages and protocols
that allow the base station and subscriber station to add the
characteristics of a service flow.
MBS (Multicast and Broadcast Services) : Globally defined service
flow that carries broadcast or multicast information towards a
plurality of SS.
MBS-CID (Multicast and Broadcast Services Connection ID) : Traffic
CID for MBS.
CCID (Common Connection Identifier) : CID shared by all SSs and BS
for the purpose of transmitting IPv6 Neighbor Discovery messages.
4. IPv6 Transmission Issues over IEEE 802.16
This section summarizes issues about IPv6 transmission on IEEE 802.16
under the condition all SSs are assigned with common prefix address.
4.1. On-Link Issue
The assignment of a common prefix to all SSs under a specific AR
Jeon & Jee Expires December 28, 2006 [Page 4]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
means locating them "on-link" in terms of IP packet transfer. From
[I-D.ietf-ipv6-2461bis], IP node determines destinations are on-link
by performing a longest prefix match against the prefix list.
Therefore, SSs sharing common prefix can be said to on-link IP nodes.
IPv6 NDP is a protocol to solve problems due to the interaction
between on-link nodes and requires direct communication between them.
By the way, IEEE 802.16 is a connection-oriented network. Even
though all data in IEEE 802.16 can be broadcasted to air shared to
all SSs, only SS associated with the CID included in the data can
receive the data. The connection of IEEE 802.16 always ends at the
BS. There is no support from 802.16 MAC/PHY for the direct
communication among SSs [I-D.jee-16ng-ps-goals] which results in the
problem of locating SSs on-link in terms of IP packet transfer.
4.2. Multicast Issue
IPv6 Neighbor Discovery messages excepting Redirect are destined for
link-local scoped multicast address such as all-router multicast
address, all-node multicast address, and solicited-node multicast
address.
Currently, it is not sure for IEEE 802.16 to provide dedicated CIDs
for multicasting IPv6 packet. Thus, any available traffic CID value
needs to be allocated for multicasting IPv6 packet.
Another consideration on multicast transmission is to avoid all-node
multicast transmission in order to prevent unrelated SSs from
frequently being waken from idle mode. Considering the limited
battery capacity from small size of mobile devices, power saving is
necessary to sustain the mobile devices alive for its lifetime.
5. IEEE 802.16 Network Model and IPv6 NDP Operations
5.1. IEEE 802.16 Network Model
IEEE 802.16 based network architecture depends on its Convergence
Sublayer (CS). When IP CS is applied, BS and AR may need to be
tightly coupled by physically or logically by tunneling mechanism
like GRE Tunneling (Figure 1 and 2). Therefore, IP packets which are
destined for on-link IP nodes needs to be first transferred toward
AR. Special consideration is required on the AR in treating IPv6 NDP
messages which have different destination forms like link-local
unicast, link-local all-nodes multicast, link-local all-routers
multicast and solicited node multicast address.
Jeon & Jee Expires December 28, 2006 [Page 5]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
+------+
| AR |
+-------+ +------+
| AR/BS | // || \\
+-------+ // || \\ <= tunnel
BS1 BS2 BS3
Figure 1 Figure 2
In case of Ethernet CS, IEEE 802.16 deployment architecture can be
configured as shown in Figure 3. Assuming Ethernet link between BS
and AR, we can consider similar bridging function on BS to one on
WLAN access point. Bridging function on BS is to interpret the
Ethernet header of packets received from SS and transmit the packets
toward expected next node. In Figure 3, such an next node can be
another BS, another SS, or AR.
+-----+
| AR |
+--+--+
|
-----+-----
/ / | \ \
/ | | | \
BS1 BS2 BS3 BS4 BS5
Figure 3
5.2. IPv6 NDP Operations
Table 1 shows the relation between operations of IPv6 Neighbor
Discovery and the above two issues according to the applied CS.
Router Discovery, Prefix Discovery, Parameter Discovery and Redirect
among IPv6 NDP operations are performed between SS and AR. Thus they
does not come under the On-Link issue. However, Multicast issue
still remains to be solved excluding Redirect operation.
As mentioned in Section 5.1, using IP CS always makes AR a neighbor
of SS even though SS sends data to any SSs. This fact indicates that
Address Resolution, Next-hop Determination, Neighbor Unreachability
Detection (NUD) and Duplicate Address Detection (DAD) should be
always performed toward AR. Moreover, absent Ethernet header in data
does not require Address Resolution. Those abnormal operations occur
due to On-Link issue.
Jeon & Jee Expires December 28, 2006 [Page 6]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
In case of Ethernet CS in Section 5.1, bridge function connects BSs
under same AR and allows each SSs to communicate each other directly
without detouring AR. Therefore, all IPv6 NDP messages can be
exchanged between SSs and there is no On-Link issue. Note that IEEE
802.16 BS should support local relay function in order to relay
packets between SSs served by same BS. However, Address Resolution
and DAD using multicast transmission should be considered in terms of
Multicast issue.
+--------------------------+---------------+---------------+
| Operations of | IP CS | Ethernet CS |
+ +-------+-------+-------+-------+
| IPv6 Neighbor Discovery |On-Link| Multi |On-Link| Multi |
+--------------------------+-------+-------+-------+-------+
| Router Discovery | X | O | X | O |
+--------------------------+-------+-------+-------+-------+
| Prefix Discovery | X | O | X | O |
+--------------------------+-------+-------+-------+-------+
| Parameter Discovery | X | O | X | O |
+--------------------------+-------+-------+-------+-------+
| Address Resolution | O | O | X | O |
+--------------------------+-------+-------+-------+-------+
| Next-hop Determination | O | X | X | X |
+--------------------------+-------+-------+-------+-------+
| NUD | O | X | X | X |
+--------------------------+-------+-------+-------+-------+
| DAD | O | O | X | O |
+--------------------------+-------+-------+-------+-------+
| Redirect | X | X | X | X |
+--------------------------+-------+-------+-------+-------+
Table 1
6. IPv6 Neighbor Discovery Support over IEEE 802.16
6.1. IP Convergence Sublayer
By aforementioned "On-Link" issue, IEEE 802.16 does not support
direct communication between on-link SSs. Moreover, AR in IP CS case
is always a next-hop neighbor even when SS sends data to on-link SSs
and thus all data have to be sent to AR as mentioned in Section 5.1.
As a result, the AR discards IPv6 NDP messages addressed link-local
all-node multicast and solicited node multicast address because the
messages do not intend for the AR. Therefore, it is necessary to
relay the restricted messages.
Jeon & Jee Expires December 28, 2006 [Page 7]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
Multicast Relaying Part (MRP) serves as packets relayer and is
located in AR. MRP over AR intercepts packets destined for the
multicast addresses and then prepares packet relaying while passing
those to upper layer. Intercepting rule of MRP is different
according to the case when IEEE 802.16 CS supports IPv6 over Ethernet
or native IPv6. In case of IP CS, MRP holds packets, which begin
with FF02 in IPv6 address. Note that the MRP does not intercept
packets addressed FF02::2. This is due to the assumption the AR
serves as default router and there is no other router in the subnet.
Table 2 shows IP multicast address types used in IPv6 NDP.
+--------------------------------+--------------------------+
| Type | IP Address Type |
+--------------------------------+--------------------------+
| Link-local all-nodes | FF02::1 |
| multicast address | |
+--------------------------------+--------------------------+
| Link-local all-routers | FF02::2 |
| multicast address | |
+--------------------------------+--------------------------+
| Solicited-node | FF02::1:FFxx:x |
| multicast address | |
+--------------------------------+--------------------------+
xx:x is last 24 bits of a unicast IPv6 address.
Table 2
When BS and AR are coupled as shown in Figure 1, AR should forward
unicast packets destined for on-link host. In the case, the packets
must be transmitted again via the incoming interface and AR has to
transmit Redirect message to sender whenever communication between
on-link SSs occurs. This problem can be issue in implementation of
AR and MRP can treat the problem.
6.2. Ethernet Convergence Sublayer
6.2.1. Identification Cache Table
Each BS maintains Identification Cache Table (ICT) on SSs covered by
the BS. The ICT contains L2, L3 address of SS, DAD flag, and
corresponding CID. If DAD flag is set, ICT includes tentative target
address in DAD Neighbor Solicitation (NS).The ICT is constructed by
following procedure.
- BS can be known about L2 address on SS during the initial ranging
procedure of IEEE 802.16 (refer to Section 6.3.1.1 in [IEEE 802.16]).
Jeon & Jee Expires December 28, 2006 [Page 8]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
- BS can be known about CID on SS after the initial ranging
procedure.
- BS can be known about L3 address on SS with Target field in DAD NS
which is not responded with DAD NA.
6.2.2. Router Discovery, Prefix Discovery and Parameter Discovery
Router Discovery, Prefix Discovery and Parameter Discovery procedures
are achieved by receiving Router Advertisement (RA) message. The RA
is advertised by using all-node multicast transmission. If IEEE
802.16 does not support IPv6 multicast transmission, the multicast
transmission should be emulated with the way described in Section 7.
Considering the power consumption on SS, AR should just unicast the
RA in response with RS without using all-node multicast transmission.
It can prevent SS from frequently being waken in idle mode.
6.2.3. Address Resolution
When Serving SS sends NS for Address Resolution, bridge on Serving BS
relays the NS toward backbone Ethernet link. Each BSs attached the
backbone receive the NS.
If network approves the proxy function for NDP, Target BS refers the
ICT and responds with NA.
Otherwise, Target BS refers the ICT and then finds a CID
corresponding to the target address in the NS, and relays the NS
message toward its own air using the CID. Target SS responds with
NA.
6.2.4. Duplicate Address Detection
When Serving BS receive DAD NS from Serving SS, the Serving BS set
DAD flag in ICT to non-zero and thus the Serving BS can be known who
sends the DAD NS. Bridge on Serving BS relays the NS for DAD toward
backbone Ethernet link. Each BSs attached the backbone receive the
NS.
If network approves the proxy function for NDP, Target BS refers the
ICT to see whether the tentative target address in the NS exists in
its own ICT table. If it exists, Target BS responds with NA.
Otherwise, discard the NS message silently.
Otherwise, Target BS refers the ICT and then finds a CID
corresponding to tentative target address in the NS, and relays the
NS message toward its own air using the CID. If the tentative target
Jeon & Jee Expires December 28, 2006 [Page 9]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
address is in use, Target SS responds with NA. Otherwise, the NS
message is ignored.
When each BS receives NA message, refer to DAD flag in ICT table to
see whether Serving SS is located in its serving area. If existing,
the BS sends the NA using corresponding CID. The CID is for unicast
traffic.
7. Multicast Transmission Emulation
This section describes how to transmit the packets with link-local
scoped multicast address into IEEE 802.16 network. We suggest
following two different approaches for the purpose of multicast
emulation.
7.1. Multicast Transmission Emulation using Common CID
IEEE 802.16 enables multicast transmission in down-stream. However,
it is difficult to create and maintain CIDs for multicast because
there can be manifold multicast sessions. Therefore, this document
defines Common CID (CCID) for transmitting multicast data.
There is one unique CCID in BS and it is shared by all SSs served by
the BS. All SSs can receive data transmitted via the CCID and IPv6
module in SSs see whether the multicast data are destined to
themselves or not.
Current IEEE 802.16 does not specify CID which can be shared by all
SSs and used for IP data. Following describes how to make CCID with
existing MBS-CID.
[IEEE 802.16e] proposes Multicast and Broadcast Service (MBS), which
presents media service to SSs using multicast or broadcast. Under
MBS architecture, each SS selects MBS contents and then configures a
corresponding CID by the DSA procedure. Such a CID for MBS is
referred to as MBS-CID. MBS-CID is one of transport CIDs and is
shared by all SSs requesting same media content.
CCID can be seen as a special type of MBS-CID. CCID is allocated to
BS and all SSs served by the BS utilizing a general DSA procedure in
MBS for transmitting link-local multicast data. For the assigning
the CCID, we assume that service flow for link-local multicast is
globally defined and the service flow is known to BS and all SSs.
Once initialization between BS and SS is completed, they perform DSA
procedure for creating the link-local multicast service flow. The
detailed process creating new service flow and updating CS for
mapping of the service flow to CCID is outside scope of this
Jeon & Jee Expires December 28, 2006 [Page 10]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
document.
BS transmits IPv6 Neighbor Discovery messages relayed by MRP towards
all SSs via the CCID.
7.2. Multicast Transmission Emulation using Replicated Unicast
The transmission using CCID allows IPv6 Neighbor Discovery messages
to be delivered only once per transmission. However, it requires a
new CID for multicast. This section shows how to transmit IPv6
Neighbor Discovery messages with existing unicast CID.
IPv6 Neighbor Discovery message can be delivered by repeated unicast
transmissions towards SSs involved in the multicast address of the
IPv6 Neighbor Discovery message.
IPv6 Neighbor Discovery messages with link-local all node multicast
address should be sent to all SSs and thus they can be transmitted by
replicated unicasts via all established CIDs on BS.
In this context, IPv6 Neighbor Discovery messages with solicited-node
multicast address should be transmitted by replicated unicasts via
CIDs of corresponding SSs. Thus, it is required to identify CIDs for
solicited-node multicast addresses.
Section 6.3.1.1 in [IEEE 802.16] states that a 48-bit universal MAC
address of SS is used during the initial ranging process to identify
connections to SS. Solicited-node multicast address of SS can be
derived by the MAC address. As a result, BS can be aware of the
solicited-node multicast addresses with the known MAC address of each
SS and match the derived addresses with each CIDs.
8. Security Considerations
IEEE 802.16e architecture supports a number of mandatory
authorization mechanisms such as EAP-TTLS, EAP-SIM and EAP-AKA.
[RFC 3971] specifies security mechanisms for NDP and defines securing
NDP messages.
Basically, our approach of using "MRP" enables SSs to exchange IPv6
NDP messages directly without depending on any proxy function at the
AR or BS. Therefore, it has advantage in securing NDP messages by
the mechanism specified from [RFC 3971].
9. References
Jeon & Jee Expires December 28, 2006 [Page 11]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 2006
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-07 (work in progress), May 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/D10, "Draft IEEE Standard for Local and
metropolitan area networks, Amendment for Physical and
Medium Access Control Layers for Combined Fixed and
Mobile Operation in Licensed Bands", Auguest 2005.
[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.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, January 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Jeon & Jee Expires December 28, 2006 [Page 12]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 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
Junghoon Jee
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-5126
Email: jhjee@etri.re.kr
Jeon & Jee Expires December 28, 2006 [Page 13]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 June 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.
Jeon & Jee Expires December 28, 2006 [Page 14]
