Network Working Group J-H. Na
Internet-Draft ETRI
Intended status: Standards Track S. Park
Expires: January 12, 2009 Chungnam National University
J-M. Moon
S. Lee
ETRI
E. Lee
S-H. Kim
Chungnam National University
July 11, 2008
Roaming Mechanism between PMIPv6 Domains
draft-park-netlmm-pmipv6-roaming-01
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 January 12, 2009.
Na, et al. Expires January 12, 2009 [Page 1]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
Abstract
Proxy Mobile IPv6 (PMIPv6) is designed to provide mobility service to
mobile nodes in the network domain which does not require the mobile
nodes to be involved in IP mobility management. In other words, the
PMIPv6 can transparently support roaming within a PMIPv6 domain, i.e.
intra-domain roaming, to mobile nodes. However, if the mobile nodes
move to other PMIPv6 domains, the nodes should have additional
protocols for the inter-domain roaming although the domains also
provide the transparent mobility. Hence, an inter-domain roaming
solution would be needed for providing transparent mobility to mobile
nodes that only move around among PMIPv6 domains. This document
specifies the inter-domain roaming controlled by the networks
adopting the PMIPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Inter-Domain Roaming Overview . . . . . . . . . . . . . . . . 6
3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
4. Roaming Mechanism Operations . . . . . . . . . . . . . . . . . 9
4.1. Control Plan Flow . . . . . . . . . . . . . . . . . . . . 9
4.2. Data Plan Flow . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Na, et al. Expires January 12, 2009 [Page 2]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
1. Introduction
PMIPv6 [I-D.ietf-netlmm-proxymip6] is a network-based mobility
management protocol that does not require mobile nodes to be involved
in mobility management. In a PMIPv6 domain, a Mobile Access Gateway
(MAG) performs signaling with a Local Mobility Anchor (LMA) for
mobility management on behalf of mobile nodes attached to the MAG.
The LMA functions as the home agent for the mobile nodes in the
PMIPv6 domain. If a mobile node moves and changes its point of
attachment from one MAG to the other, it can still continue to use
the same address configuration by the signaling between the MAGs and
the LMA of the node [I-D.ietf-netlmm-proxymip6]. In other words,
PMIPv6 can only support roaming within a PMIPv6 domain transparent to
mobile nodes without mobility functionality.
Next-generation wireless networks, such as 802.16e [IEEE802.16e] and
Super 3G/3.9G [3GPP], have the potential to run IP deeper into the
access network than the current 3G cellular networks, similar to
today's WLAN networks [RFC4830]. It means such various and
heterogeneous access networks would be routed IP networks. Also, the
access networks would provide IP mobility by PMIPv6 since the access
networks try to adopting PMIPv6 protocol as local mobility management
solution specified in [3GPP] [WiMAX]. This development might lead to
frequent roaming of mobile nodes within a PMIPv6 domain, i.e. intra-
domain roaming, and between PMIPv6 domains, i.e. inter-domain
roaming.
Existing inter-domain roaming solution described in
[I-D.giaretta-netlmm-mip-interactions] considers interworking between
PMIPv6 and MIPv6 [RFC3775]. It means that a mobile node should have
MIPv6 and be involved in mobility management via the MIPv6 if the
mobile node in a PMIPv6 domain moves into another PMIPv6 domain.
However, such involvement of mobile nodes causes several considerable
and ironical problems as follows.
o If a mobile node involves MIPv6 protocol stack, the mobile node
suffers update latency, signaling overhead, and location privacy
problems described in [RFC4830] although the node is located in
the domain adopting PMIPv6 proposed to solve such problems.
o If a mobile node involves MIPv6 protocol stack, the visited PMIPv6
domain can not provide transparency to the mobile node though the
domain also support transparent mobility to the mobile node in
network-based management manner.
o If a mobile node that do not have MIPv6 protocol stack, the
visited PMIPv6 domain can not provide seamless IP mobility to the
mobile node although the domain also offers mobility management
Na, et al. Expires January 12, 2009 [Page 3]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
service.
This document specifies roaming mechanism between PMIPv6 domains to
provide transparent and seamless inter-domain mobility to mobile
nodes. In this solution, LMAs and MAGs in two domains perform
exchange of signaling messages to mobility management on behalf of
mobile nodes. The signaling is performed to re-establish bi-
directional tunnels for data flow and emulate home link of each
mobile node. Thus, the mobile node can maintain session continuity
via a global unicast IPv6 address organized in home PMIPv6 domain if
the mobile nodes move into visited PMIPv6 domain. Namely, inter-
domain roaming of the mobile nodes can be supported transparently in
network-based manner like intra-domain roaming.
Na, et al. Expires January 12, 2009 [Page 4]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
2. Terminology
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 [RFC2119].
This document uses the terminology defined in [RFC3775],
[I-D.ietf-netlmm-proxymip6]. All user authentication and prefix
allocation related terms are defined in [RFC2865], [RFC3588],
[RFC4818].
o Home PMIPv6 Domain - This refers to the network where a mobile
node registered to be provided the network-based mobility
management service and the mobility management of the mobile node
is handled using the Proxy Mobile IPv6 protocol.
o Visit PMIPv6 Domain - This refers to any PMIPv6 network other than
Home PMIPv6 Domain of a mobile node, to which the mobile node is
currently connected. Through a contact among PMIPv6 domains, it
provides the networks-based mobility management service to mobile
nodes of other PMIPv6 domains when they enter in it.
o Intra-Domain Roaming - This means that a mobile node is provided
network-based mobility management support, without requiring the
participation of it in any mobility related signaling when the
mobile node moves between MAGs within a PMIPv6 domain.
o Inter-Domain Roaming - This means that a mobile node is provided
network-based mobility management support, without requiring the
participation of the mobile node in any mobility related signaling
when the mobile node moves into other PMIPv6 domains.
o LMAh - This is the Local Mobility Anchor for a mobile node in the
Home PMIPv6 domain. It is the topological anchor point for the
mobile node's home network prefix and manages the mobile node's
binding state. It has the functional capabilities of a Local
Mobility Anchor as defined in Proxy Mobile IPv6 base specification
[I-D.ietf-netlmm-proxymip6] with the additional capabilities
required for supporting the inter-domain roaming as defined in
this specification.
o LMAv - This is a Local Mobility Anchor in the Visit PMIPv6 Domain
to which a mobile node visits. To support the network-based
mobility management service to the mobile node, it establishes a
bi-directional tunnel with the LMAh in the Home PMIPv6 Domain of
the mobile node and delivers data on behalf of the mobile node
through the tunnel.
Na, et al. Expires January 12, 2009 [Page 5]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
3. Inter-Domain Roaming Overview
This specification describes a network-based roaming mechanism
between Proxy Mobile IPv6 domains. It is called Inter-Domain Roaming
and based on Proxy Mobile IPv6[I-D.ietf-netlmm-proxymip6].
Inter-Domain Roaming mechanism is intended for providing network-
based mobility management support to a mobile node, without requiring
the participation of the mobile node in any mobility related
signaling when the mobile node moves an access network in other proxy
domains.
The core functional entity in the Inter-Domain Roaming is the Local
Mobility Anchor (LMA). The LMA is defined as Visited LMA(LMAv) and
home LMA(LMAh) for inter-proxy domain roaming. LMAv is a local
mobility anchor in visited proxy domain and LMAh is a local mobility
anchor in home proxy domain. The local mobility anchor is
responsible for rechability of the mobile node and is the topological
anchor point for home network prefix of the mobile node.
3.1. Scenarios
Figure 1 shows a circumstance of the roaming between PMIPv6 domains.
A MN receives its home network prefix in a PMIPv6 home domain and
configures its address, MN-HoA. The MN sends and receives data by
using the HoA during moving in the home domain. Even though the MN
moves into a PMIPv6 visit domain, the MN sends and receives data
without cutoff of the session by using the MN-HoA, as the MN resides
in the domain that PMIPv6 service is possible.
Na, et al. Expires January 12, 2009 [Page 6]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
+----+
+--------| CN |
| +----+
+---------------|---+
+-----| Internet Backbone |-----+
| +-------------------+ |
| |
+--------------|-----------+ +------------|-------------+
|Visit +------+ ______________________ +------+ Home |
|PMIPv6 | LMAv |-______________________-| LMAh | PMIPv6|
|Domain +------+ | | +------+ Domain|
| | <-- LMAAv | | LMAAh --> | |
| / / | | \ \ |
| / / | | \ \ |
| / / +------+ | | +------+ \ \ |
| / / | AAAv | | | | AAAh | \ \ |
| / / +------+ | | +------+ \ \ |
| / / | | \ \ |
| / / | | \ \ |
| | <-- Proxy-CoAv | | Proxy-CoAh --> | |
| +------+ | | +------+ |
| | MAGv | | | | MAGh | |
| +------+ | | +------+ |
+--------|-----------------+ +-------------------|------+
MN-HoA --> | | <-- MN-HoA
+----+ Movement +----+
| MN | <------------------------------------ | MN |
+----+ +----+
Figure 1: Inter-domain roaming scenario
3.2. Assumptions
To support roaming between PMIPv6 domains, the proposed protocol
makes the following assumptions:
o Through a contact among PMIPv6 domains, LMAs and MAGs can request
authentication about hosts of other domains as well as hosts of
its domain, to AAA.
o EAP and AAA protocols, RADIUS [RFC2865] or Diameter [RFC3588], can
be used for user authentication and prefix allocation as defined
in [RFC4818].
o A Network Access Identifier (NAI) of a MN, i.e. MN-ID, used for
user authentication and prefix allocation might be a e-mail
Na, et al. Expires January 12, 2009 [Page 7]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
address, etc.
o Concatenated tunnels could be established to support inter-domain
roaming.
Na, et al. Expires January 12, 2009 [Page 8]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
4. Roaming Mechanism Operations
4.1. Control Plan Flow
To support inter-domain roaming through the proposed mechanism, the
signalings due to movement of a MN follows figure 2. The MN within a
home domain requests authentication to the MAGh through its NAI.
This authentication is initiated through L2 access. The MAGh
requests authentication with regard to the MN' ID (foo@home) to AAAh.
If the MN is authenticated as an authorized host, the AAAh delivers
an LMAh address of the MN to the MAGh. The MAGh sends Proxy Binding
Update (PBU) message with its address, Proxy-CoAh, and the MN address
to the LMAh. The LMAh registers the MAGh address in regard to the MN
and sends Proxy Binding Acknowledgement (PBA) message including a
Home Network Prefix of the MN to the MAGh. If the MAGh receives the
PBA message, it is established a bi-directional tunnel between the
LMAh and MAGh, for data from or to the MN. The MAGh registers the
home network prefix of the MN and sends Router Advertisement (RA)
message including the home network prefix to the MN. The MN on
receiving this RA message has a valid address (MN-HoA) through
configuring its interface with its home network prefix. The MN sends
and receives data through the tunnel using the MN-HoA.
If the MN moves to the visit domain, it cannot communicate with the
home domain. Then, the MN again requests an authentication to an
MAGv through L2 access. The MAGv on receiving the authentication
request of the MN requests authentication to an AAAv. Because the
AAAv knows that the MN is a host of the home domain, it again
requests authentication to the AAAh. The AAAh sends LMAh address to
AAAv after the authentication in regard to the MN. The AAAv sends
LMAv address in regard to the MN and LMAh address sent from the AAAh,
to the MAGv. The MAGv sends a PBU message including its address, the
MN' ID, and LMAh address, to the LMAv. The LMAv registers MAGv
address in regard to the MN and sends a PBU message including its
address and the MN' ID to the LMAh. The LMAh removes the previous
tunnel in regard to the MN and re-establishes new tunnel in regard to
the MN to LMAv. The LMAh also sends a PBA message including the home
network prefix of the MN to the LMAv. The LMAv registers the
received home network prefix and sends a PBA message including the
prefix to the MAGv. So, to support inter-domain roaming of the MN,
concatenated tunnels from LMAh to LMAv and from LMAv to MAGv is
established by exchanging the PBU and PBA messages. The MAGv
registers the home network prefix of the MN and sends RA messages to
the MN. Therefore, the MN believes it is still on the home domain,
and sends and receives continuously data.
Na, et al. Expires January 12, 2009 [Page 9]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
(NAI:foo@home) Domain@visit Domain@home
+----+ +------+ +------+ +------+ +------+ +------+ +------+
| MN | | MAGv | | LMAv | | AAAv | | MAGh | | LMAh | | AAAh |
+----+ +------+ +------+ +------+ +------+ +------+ +------+
| | | | | | |
L2 | | | | | |
Attachment | | | | | |
| User Auth. Req. | Access Req. |
|------------------------------------------>|------------------>|
|<------------------------------------------|<------------------|
| User Auth. Res. Access Res.(LMAAh)
| | | | | PBU | |
| | | | |-------->| |
| | | | |<--------| |
| | | | | PBA(HNP)| |
|<------------------------------------------|=Tunnel==| |
| | RA(HNP) | | | |
Address
Auto-Configuration
|
Move to
visit domain ....
|
L2
Attachment
|
User Auth. Req. Access Req. Access Req.
|---------->|------------------>|------------------------------>|
|<----------|<------------------|<------------------------------|
User Auth. Res. Access Res. Access Res. |
(LMAAv & LMAAh) (LMAAh as HA) |
| | PBU | PBU | |
| |-------->|------------------------------>| |
| |<--------|<------------------------------| |
| | PBA | PBA | |
(Previously assigned HNP) (Previously assigned HNP) |
|<----------|=Tunnel==|============Tunnel=============| |
| RA | | | | | | |
(Previously assigned HNP) | | | | |
| | | | | | |
Figure 2: Control Flow to establish concatenated tunnels
Na, et al. Expires January 12, 2009 [Page 10]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
4.2. Data Plan Flow
Figure 3 shows data flow between an NM and a CN. The data flow
consists of a bi-directional tunnel between an MAGv and an LMAv and a
bi-directional tunnel between the LMAv and an LMAh. When the CN
sends data to the MN, it includes its address and the MN address HoA
in IP header of data packet. The LMAh on receiving the packet from
the CN sends the packet encapsulating its address and LMAv address to
the LMAv. The LMAv decapsulates the packet and sends the packet
encapsulating its address and the MAGv address to the MAGv. The MAGv
decapsulates the packet to the original packet from the CN and sends
the original packet to the MN.
Na, et al. Expires January 12, 2009 [Page 11]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
+--------------------------+ +--------------------------+
| Domain@visit | | Domain@home |
+----+ | +------+ +------+ | | +------+ +------+ | +----+
| MN | | | MAGv | | LMAv | | | | MAGh | | LMAh | | | CN |
+----+ | +------+ +------+ | | +------+ +------+ | +----+
| | | | | | | | | |
Home | | | | | | | | |
Domain | | | | | | | | |
| | [CN|MN-HoA][payload] | | | | | |
|--------------------------------------->| | | |
| | | | | | |====Tunnel=====| | |
| | | | | [LMAAh|Proxy-CoAh][CN|MN-HoA] |
| | | | | | |-------------->| | |
| | | | | | | |[CN|MN-HoA]
| | | | | | | |--------->|
| | | | | | | |<---------|
| | | | | | | |[MN-HoA|CN]
| | | | | | |<--------------| | |
| | | | | [Proxy-CoAh|LMAAh][MN-HoA|CN] |
| | [MN-HoA|CN][payload] | | |===============| | |
|<---------------------------------------| | | |
| | | | | | | | | |
Visit | | | | | | | | |
Domain | | | | | | | | |
| | | | | | | | | |
[CN|MN-HoA]| | | | | | | |
|--------->|====Tunnel=====| | | | | | |
| [LMAAv|Proxy-CoAv][CN|MN-HoA] | | | | |
| | |-------------->|============Tunnel===========| | |
| | | | [LMAAh|LMAAv][CN|MN-HoA] | | |
| | | |---------------------------->| | |
| | | | | | | |[CN|MN-HoA]
| | | | | | | |--------->|
| | | | | | | |<---------|
| | | | | | | |[MN-HoA|CN]
| | | |<----------------------------| | |
| | | | [LMAAv|LMAAh][MN-HoA|CN] | | |
| | |<--------------|=============================| | |
| [Proxy-CoAv|LMAAv][CN|MN-HoA] | | | | |
| | |===============| | | | | | |
[MN-HoA|CN]| | | | | | | |
|<---------| | | | | | | |
| | | | | | | | | |
+--------------------------+ +--------------------------+
Figure 3: Data Flow via concatenated tunnels
Na, et al. Expires January 12, 2009 [Page 12]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
5. IANA Considerations
This document requests no action by IANA.
Na, et al. Expires January 12, 2009 [Page 13]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
6. Security Considerations
This document is based on the security requirements listed in
[I-D.ietf-netlmm-proxymip6]. The inter domain roaming requires the
signaling message, Proxy Binding Updates and Proxy Binding
Acknowledgement, exchanged between the visited local mobility anchor
and home local mobility anchor to be protected using IPsec, using the
established security association between them such as between the MAG
and the LMA in [I-D.ietf-netlmm-proxymip6].
Na, et al. Expires January 12, 2009 [Page 14]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
7. Acknowledgements
None.
Na, et al. Expires January 12, 2009 [Page 15]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-18 (work in progress),
May 2008.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
8.2. Informative References
[RFC4830] Kempf, J., "Problem Statement for Network-Based Localized
Mobility Management (NETLMM)", RFC 4830, April 2007.
[I-D.giaretta-netlmm-mip-interactions]
Giaretta, G., "Interactions between PMIPv6 and MIPv6:
scenarios and related issues",
draft-giaretta-netlmm-mip-interactions-02 (work in
progress), November 2007.
[IEEE802.16e]
"IEEE Standard for Local and Metropolitan Area Networks
Part 16: Air Interface for Fixed and Mobile Broadband
Wireless Access Systems Amendment 2: Physical and Medium
Access Control Layers for Combined Fixed and Mobile
Operation in Licensed Bands and Corrigendum 1",
February 2006.
[3GPP] "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3GPP
System Architecture Evolution: Report on Technical Options
Na, et al. Expires January 12, 2009 [Page 16]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
and Conclusions (Release 7)", March 2007.
[WiMAX] "Network Working Group_World Interoperability for
Microwave Access (WiMAX) Forum Network Architecture -
Stage 2 Part 2 - Release 1.0.0", March 2007.
Na, et al. Expires January 12, 2009 [Page 17]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
Authors' Addresses
Jee-Hyeon Na
ETRI
161 Gajeong-dong Yuseng-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 5408
Email: jhna@etri.re.kr
Soochang Park
Chungnam National University
220 Gung-dong, Yuseong-gu
Daejeon, 305-764
Korea
Phone: +82 42 821 7451
Email: winter@cclab.cnu.ac.kr
Jung-Mo Moon
ETRI
161 Gajeong-dong Yuseng-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 6748
Email: jmmoon@etri.re.kr
Sangho Lee
ETRI
161 Gajeong-dong Yuseng-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 6385
Email: leesh@etri.re.kr
Na, et al. Expires January 12, 2009 [Page 18]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
Euisin Lee
Chungnam National University
220 Gung-dong, Yuseong-gu
Daejeon, 305-764
Korea
Phone: +82 42 821 7451
Email: eslee@cclab.cnu.ac.kr
Sang-Ha Kim
Chungnam National University
220 Gung-dong, Yuseong-gu
Daejeon, 305-764
Korea
Phone: +82 42 821 6271
Email: shkim@cnu.ac.kr
Na, et al. Expires January 12, 2009 [Page 19]
Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Na, et al. Expires January 12, 2009 [Page 20]