One document matched: draft-jeong-netlmm-ro-support-for-pmip6-00.txt
Network Working Group S. Jeong
Internet-Draft ETRI
Intended status: Informational R. Wakikawa
Expires: January 3, 2008 Keio University
July 2, 2007
Route Optimization Support for Proxy Mobile IPv6 (PMIPv6)
draft-jeong-netlmm-ro-support-for-pmip6-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 January 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes route optimization support for Proxy Mobile
IPv6 (PMIPv6). The protocol specified in the document leverages
route optimization procedures defined in [RFC3775] and extend the
procedures in order to apply for PMIPv6. The protocol supports route
optimization for both IPv6 mobile nodes and IPv4 mobile nodes. Route
optimization over IPv4 transport network is also supported.
Jeong & Wakikawa Expires January 3, 2008 [Page 1]
Internet-Draft Route Optimization for PMIPv6 July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation for route optimization in PMIPv6 . . . . . . . 3
1.2. Route optimization scenarios in PMIPv6 . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5
2.1. Route Optimization with Return Routability Test . . . . . 5
2.1.1. IP Node without PMIPv6 Route Optimization
Functionality . . . . . . . . . . . . . . . . . . . . 5
2.1.2. IPv6 Node supporting PMIPv6 Route Optimization
Functionality . . . . . . . . . . . . . . . . . . . . 7
2.2. Route Optimization - Quick Mode . . . . . . . . . . . . . 7
2.3. Bindings Exchange with Correspondent Node . . . . . . . . 8
2.3.1. IPv6 Transport Support . . . . . . . . . . . . . . . . 8
2.3.2. IPv4 Transport Support . . . . . . . . . . . . . . . . 9
3. Mobile Access Gateway Considerations . . . . . . . . . . . . . 10
4. Correspondent Node Considerations . . . . . . . . . . . . . . 11
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Jeong & Wakikawa Expires January 3, 2008 [Page 2]
Internet-Draft Route Optimization for PMIPv6 July 2007
1. Introduction
The Proxy Mobile IPv6 (PMIPv6) base document [I-D.ietf-netlmm-
proxymip6] specifies a network-based local mobility management
protocol. The PMIPv6 base protocol describes a mobility management
solution without a mobile node's participation in mobility management
related signaling process. The PMIPv6 base document considers IPv6
home address mobility over IPv6 transport network. The IPv4 support
document [I-D.ietf-netlmm-pmip6-ipv4-support] extends the PMIPv6 base
protocol in order to support IPv4 home address mobility and IPv4
transport network.
1.1. Motivation for route optimization in PMIPv6
The Mobile IPv6 [RFC3775] and Enhanced Route Optimization [RFC4866]
specify route optimization procedures that allows the mobile node
(MN) to register its binding information to the corresponding node
(CN). After the route optimization procedures, the correspondent
node can directly send and receive packets from the MN's care-of-
address.
In the PMIPv6, packets originated from or sent to a MN are routed
through bidirectional tunneling between Mobile Access Gateway (MAG)
and Local Mobility Anchor (LMA) by default, so packets from/to the
mobile can be delivered through longer path than the optimized route,
especially when the MN and a CN are in topologically close location
and LMA is away from the mobile node. Hence, route optimization is
useful, when PMIP6 domain spans large area.
Mobility management signaling is exchanged among network entities in
PMIPv6. Further, the MN has home address (HoA) only, so care-of
address (CoA) test in the MIPv6 route optimization is not directly
applicable to PMIPv6. So, this document describes route optimization
solution based on MIPv6, which simultaneously supports PMIPv6 base
protocol and IPv4 extension specification. The document leverages
route optimization procedures in MIPv6 for PMIPv6 and MAG performs
MIPv6 route optimization on behalf the MN in the PMIPv6 domain.
1.2. Route optimization scenarios in PMIPv6
The followings are typical route optimization scenarios in PMIPv6
o Scenario 1 : A MN and a CN are in the same PMIPv6 domain and
anchored at an LMA. This scenario covers basic PMIPv6 route
optimization scenario.
Jeong & Wakikawa Expires January 3, 2008 [Page 3]
Internet-Draft Route Optimization for PMIPv6 July 2007
o Scenario 2 : A MN and a CN are in the PMIPv6 domain, but they are
anchored at the different LMAs. So, inter-LMA operation needs to
be involved in the route optimization procedures.
o Scenario 3 : A MN is in the PMIPv6 domain and initiates route
optimization procedures with a CN that is outside of the PMIPv6
domain. In this case, the CN supports route optimization
procedures defined in this document.
Note that as defined in the IPv4 extension document in PMIPv6
[I-D.ietf-netlmm-pmip6-ipv4-support], the MN and the CN can support
IPv4 home address mobility in scenario 1 and 2. Furthermore, the
network between MAG and LMA can provide IPv4 transport and NAT may
reside inside the network. Therefore, route optimization in PMIPv6
should support IPv4 home address and IPv4 transport network. This
document supports route optimization between IPv4 MNs in the PMIPv6
domain and/or IPv4 transport network. Route optimization between a
MN and a CN within a MAG is covered by PMIPv6 base specification
[I-D.ietf-netlmm-proxymip6].
Access | Transport |
Network | Network |
(IPv4/IPv6) | (IPv4/IPv6) |
+----+ +----- IPv4/IPv6
+---+ | | v Proxy CoA1
|MN |* * * * *|MAG1+----+
+---+ ^ | | \
| +----+ \ +---+ +----------+
IPv4/IPv6 ---+ \ | L | ( )
MN-HoA +---| M |----( Internet )
+-| A | ( )
/ +---+ +----------+
+----+ +---+ \
+----+ | | / \
|CN1 |* * * * *|MAG2|--+ \ <-- IPv6 Addr
+----+ ^ | | ^ +----+
| +----+ | |CN2 |
IPv4/IPv6 ---+ +---- IPv4/IPv6 +----+
CN-HoA Proxy CoA2
Figure 1: Typical Route Optimization Scenarios in PMIPv6
1.3. Terminology
Terminoloy used in this document is taken directly from [I-D.ietf-
netlmm-proxymip6] and [RFC3775].
Jeong & Wakikawa Expires January 3, 2008 [Page 4]
Internet-Draft Route Optimization for PMIPv6 July 2007
2. Protocol Specification
2.1. Route Optimization with Return Routability Test
This section describes return routability test with IP node (IPv4 or
IPv6) whose mobility is provided by PMIPv6. For simplicity,
scenarios covered in this section are the case where the MN and the
CN are anchored at the same LMA and the case where the CN is outside
of the PMIPv6 domain. When the mobile node and the correspondent
node are anchored at different LMAs, inter-LMA query will be used for
acquiring information about MAG2. Inter-LMA operation will be
discussed at the later version of this document.
2.1.1. IP Node without PMIPv6 Route Optimization Functionality
2.1.1.1. Return Routability Test in IPv6 Transport Network
Return routability test described in this document is based on
Section 5.2 of MIPv6 [RFC3775]. In this section, the headers and
addresses related to tunneling between MAG and LMA is omitted. It
follows PMIPv6 base specification [I-D.ietf-netlmm-proxymip6]. We
also assume that each MAG knows IPv4 and IPv6 addresses of other MAGs
in the PMIPv6 domain by bootstrapping mechanism or out-of band
signaling mechod.
When MAG1 initiates return routability test between IPv6 MN and IPv6
CN, MAG1 sends HoTI and CoTI messages to MAG2 as defined in MIPv6
[RFC3775]. However, since MN does not have care-of address in
PMIPv6, MAG1 sets the source addresses of CoTI as its IPv6 Proxy CoA.
Other parameters for authenticating the MN will be set same as MIPv6.
In order to acquire information about which MAG serves the CN, MAG1
queries it to LMA before initiating return routability procedures.
Details about query message is TBD.
Figure 2 and Figure 3 shows HoTI and CoTI message for route
optimization between IPv4 MN and IPv4 CN. In case of route
optimization between IPv4-only MN and CN, they do not have IPv6
address for inner IPv6 header. So, the source and destination
address of inner IPv6 header indicate IPv6 Proxy CoA of MAG1 and
MAG2, respectively. Then, the IPv4 addresses of the MN and the CN
are specified in the outer IPv4 header. Upon creating HoTI and CoTI
message, MAG1 tunnels the messages to LMA. Since deciding which
tunnel interface to be selected is based on MN's home address, MAG is
required to forward packets whose destination address is anchored at
LMA to IPv4 tunnel.
Jeong & Wakikawa Expires January 3, 2008 [Page 5]
Internet-Draft Route Optimization for PMIPv6 July 2007
IPv4 header (src=MN's IPv4 HoA, dst=IPv4 CN)
IPv6 header (src=MAG1's IPv6 P.CoA, dst=MAG2's IPv6 P.CoA)
Mobility header
- Proxy HoTI
Mobility Options
- IPv4 HAO /* MN's IPv4 HoA */
- IPv4 Alt CN Addr Option
/* CN's IPv4 Address */
Figure 2: HoTI message for IPv4 Address
IPv4 header (src= MAG1's IPv4 Proxy CoA, dst= IPv4 CN)
IPv6 header (src=MAG1's IPv6 P.CoA, dst=MAG2's IPv6 P.CoA)
Mobility header
- Proxy CoTI
Mobility Options
- IPv4 Alt Care-of Address Option
/* MAG1's IPv4 Address */
- IPv4 Alt CN Address Option
/* CN's IPv4 Address */
Figure 3: CoTI message for IPv4 Home Address
On receiving HoTI and CoTI message for route optimization with IPv6
address included, MAG2 processes the received packets according to
Section 9.4 of MIPv6 [RFC3775]. If the received HoTI and CoTI
include IPv4 addresses of MN and CN in the mobility option, MAG2
decapsulates outer IPv4 header and recovers original HoTI and CoTI
messages. Then, MAG2 replaces the source and destination address of
HoTI and CoTI message with IPv4 addresses in mobility option and
performs return routability procedures in MIPv6 [RFC3775]. After
completing return routability procedures, MAG1 sends Proxy Biding
Update to MAG2, as described in Section 2.3.
2.1.1.2. Return Routability Test in IPv4 Transport Network
When the transport network is an IPv4 network, route optimization
procedures need to be performed through IPv4 tunnel between MAGs.
When MAG1 initiates return routability for IPv6 MN and IPv6 CN,
similar to IPv6 transport network scenario, MAG1 sets the source
addresses of HoTI and CoTI as MN's IPv6 HoA and MAG1's IPv6 Proxy
CoA. Since MAG1 already has routing state regarding to MN's IPv6
HoA, HoTI and CoTI message will be delivered to LMA via IPv4 tunnel.
MAG1 is required to forward CoTI packet to IPv4 tunnel toward LMA by
looking up the destination address. LMA will look up routing table
and forward the HoTI and CoTI message to MAG2. In case of IPv4
Jeong & Wakikawa Expires January 3, 2008 [Page 6]
Internet-Draft Route Optimization for PMIPv6 July 2007
address support, HoTI and CoTI message have the same format as IPv6
transport network scenario, as shown in Figure 2 and Figure 3.
On receiving HoTI and CoTI message for route optimization between
IPv6 MN and IPv6 CN, MAG2 finishes return routability procedures as
defined in Section 9.4 of MIPv6 [RFC3775] except that HoT and CoT
will be replied to MAG1 via IPv4 tunnel. When IPv4 addresses are
included in mobility option, MAG2 performs the same operation as
Section 2.1.1.1.
Note that in case that NAT is present on the path, IPv6 packet
including IPv6 header and mobility header will be encapsulated by UDP
header, similar to IPv4 support document [I-D.ietf-netlmm-pmip6-ipv4-
support]. IPv6 address
2.1.2. IPv6 Node supporting PMIPv6 Route Optimization Functionality
In this scenario, route optimization with IPv6 CN is supported only.
Also, the network between MAG and the CN should be an IPv6 network.
MAG1 performs same operation as route optimization between IPv6 MN
and IPv6 CN over IPv6 transport network, as described in Section
2.1.1.1. MAG1 exchanges HoT/CoT messages with the CN on behalf of
the mobile node.
2.2. Route Optimization - Quick Mode
Unlike MIPv6, network entities that perform mobility management
signaling in a PMIPv6 domain are managed entities. Thus, it may be
possible to pre-establish security association among MAGs and LMAs by
bootstrapping mechanism which is not yet defined for PMIPv6. In this
section, we assume that security association was established by
bootstrapping. Then, MAGs can exchange binding information protected
by IPsec ESP. Each MAG may authenticate other MAGs by Peer
Authentication Database that will be established during bootstrapping
process. The Peer Authentication Database will be similar to PMIPv6
base specification [I-D.ietf-netlmm-proxymip6]. Details about
establishing security association between MAGs are out of scope of
this document.
In order to initiate route optimization, MAG1 queries the IP address
of MAG (i.e., MAG2) that manages the CN to LMA. Then, MAG1 and MAG2
exchange bindings. When the MN and the CN are anchored at different
LMA, inter-LMA query will be used for acquiring information about
MAG2. Inter-LMA operation will be discussed at the later version of
this document. Processing bindings is specified in Section 2.3.
Jeong & Wakikawa Expires January 3, 2008 [Page 7]
Internet-Draft Route Optimization for PMIPv6 July 2007
2.3. Bindings Exchange with Correspondent Node
2.3.1. IPv6 Transport Support
After completing return routability procedures, MAG1 and MAG2 perform
proxy binding update/acknowledgement exchange as described in section
9.5 and 11.7 of MIPv6 [RFC3775]. MAG1 and MAG2 perform the MN
operation and the CN operation, respectively. Figure 4 shows Proxy
Binding Update to the CN (i.e., MAG2). The Proxy Binding Update
message includes the MN's IPv6 home network prefix and the CN's IPv6
address in the mobility option. When the MN and the CN are IPv4
nodes, the IPv4 addresses are included in mobility option of Proxy
Binding Update, as shown in Figure 4. The Proxy Binding Update
should be protected by same encryption scheme as defined in MIPv6
[RFC3775] by default. Alternately, if bootstrapping mechanism is
applied to the PMIPv6 domain, MAGs may exchange Proxy Binding Update/
Acknowledgement protected by IPsec ESP.
IPv6 header (src=MAG1's IPv6 P.CoA, dst= MAG2's IPv6 P.CoA)
Mobility header
-BU /* new flag may be needed */
Mobility Options
union {
- HNP and - IPv6_CN-HNP
/* RO for IPv6 MN and IPv6 CN */
- IPv4_HAO and - IPv4_CN-HAO
/* RO for IPv4 MN and IPv4 CN */
}
- Time Stamp Option
Figure 4: Proxy Binding Update for Route Optimization
On receiving a Proxy Binding Update message for route optimization,
MAG2 replies with the Proxy Binding Acknowledgment message including
IPv6 Route Optimization Acknowledgment or IPv4 Route Optimization
Acknowledgement.
After HoT/CoT messages exchange, MAG creates binding cache entry for
optimized route. The contents of cache entry include (MN's HoA,
MAG1's Proxy CoA, CN's HoA, MAG2's Proxy CoA). Once MN sends a
packet destined to CN's HoA, MAG1 encapsulates the packet in IPv6
header. The source and destination address of outer IPv6 header is
MAG1's Proxy CoA and MAG2's Proxy CoA, respectively. Then, MAG1
tunnels the packet to MAG2. On receiving the tunneled packet, MAG2
decapsulates the packet and forwards it to CN.
Jeong & Wakikawa Expires January 3, 2008 [Page 8]
Internet-Draft Route Optimization for PMIPv6 July 2007
IPv6 header (src= MAG2's IPv6 P.CoA, dst= MAG1's IPv6 P.CoA)
Mobility header
- BA /* new flag may be needed */
Mobility Options
union {
- IPv6_RO_Ack
- IPv4_RO_Ack
}
- Time Stamp Option
Figure 5: Binding Acknowledgement for Route Optimization
2.3.2. IPv4 Transport Support
When the transport network between two MAGs is an IPv4 network, the
MAG should perform NAT detection scheme as defined in [I-D.ietf-mip6-
nemo-v4traversal]. If NAT is present on the path, MAG will exchange
Proxy Binding Update messages as defined in Section 4.4 of [I-D.ietf-
netlmm-pmip6-ipv4-support]. Figure 6 shows Proxy Binding Update
message sent from the MAG1 to MAG2. The source and destination
address of the outer IPv4 header are the IPv4 Proxy CoAs assigned to
MAG1 and MAG2, respectively. The source and destination address in
the inner IPv6 headers are set to the IPv6 Proxy CoAs of MAGs. The
mobility options carry IPv6 or IPv4 address of the MN and the CN.
UDP header exists in case that NAT traversal is required. Other
parameters and processing of Proxy Binding Update follows [I-D.ietf-
netlmm-pmip6-ipv4-support].
IPv4 header (src=MAG1's IPv4 P.CoA, dst=MAG2's IPv4 P.CoA)
UDP header /* if NAT is present */
IPv6 header (src=MAG1's IPv6 P.CoA, dst=MAG2's IPv6 P.CoA)
Mobility header
- BU /* new flag may be needed */
Mobility Options
union {
- HNP and - IPv6_CN-HNP
/* RO for IPv6 MN and CN */
- IPv4_MN-HAO and - IPv4_CN-HAO
/* RO for IPv4 MN and CN */
}
- Time Stamp Option
Figure 6: Binding Update for Route Optimization over IPv4 network
When MAG2 receives a Proxy Binding Update that contains Proxy Binding
Update message encapsulated in an IPv4 packet, MAG2 establishes
binding cache entry according to Section 4.4 of [I-D.ietf-netlmm-
Jeong & Wakikawa Expires January 3, 2008 [Page 9]
Internet-Draft Route Optimization for PMIPv6 July 2007
pmip6-ipv4-support] and replies with Proxy Binding Acknowledgement.
Figure 7 shows Proxy Binding Acknowledgement message sent from MAG2.
The Proxy Binding Update/Acknowledgement should be protected by same
encryption scheme as defined in MIPv6 [RFC3775] by default.
IPv4 header (src=MAG2's IPv4 P.CoA, dst=MAG1's IPv4 P.CoA)
UDP header /* if NAT is present */
IPv6 header (src= MAG2's IPv6 P.CoA, dst= MAG1's IPv6 P.CoA)
Mobility header
- BA /* new flag may be needed */
Mobility Options
union {
- IPv6_RO_Ack
- IPv4_RO_Ack
}
- Time Stamp Option
Figure 7: Binding Acknowledgement for route optimization over IPv4
network
3. Mobile Access Gateway Considerations
In order to support route optimization in PMIPv6, MAG supports all
the considerations explained in PMIPv6 base protocol [I-D.ietf-
netlmm-proxymip6] and IPv4 extension specification [I-D.ietf-netlmm-
pmip6-ipv4-support]. Also, return routability procedures in MIPv6
[RFC3775] need to be supported. In addition to that, followings are
to be considered.
o When MAG initiates route optimization, it should generate
different home init/care-of init cookies for each MN during return
routability procedures.
o Discovering IP addresses of other MAGs is out of scope of this
document.
o MAG needs to investigate incoming packets to MN/CN whether
messages for route optimization are encapsulated or not.
o If transport network between MAGs is IPv4 and NAT is detected on
the path, MAG should encapsulate outgoing packets in UDP and
transmit them to LMA or CN.
o When MAG receives a packet destined to a CN whose address is
anchored at LMA, MAG forwards the packet to LMA through IP tunnel.
Jeong & Wakikawa Expires January 3, 2008 [Page 10]
Internet-Draft Route Optimization for PMIPv6 July 2007
4. Correspondent Node Considerations
In order to perform route optimization with a MN, a CN should support
CN cooperation in Section 9 of MIPv6 [RFC3775] and return routability
procedures described in this document. In addition to that, the CN
needs to support following considerations.
o After route optimization between a MN (i.e., MAG) and a CN is
done, MAG transport the MN's packets to the CN via IPv6-in-IPv6
tunnel. The source and destination address of outer IPv6 header
are MAG's IPv6 Proxy CoA and the CN's IPv6 address. Thus, the CN
should decapsulate tunneled IPv6 packet and accept the inner
packet for further processing.
5. Message Format
This document introduces several new mobility options. The format of
new mobility options will be defined in the later version of this
document.
6. IANA Considerations
TBD
7. Security Considerations
This document extends the route optimization scheme in MIPv6 so as to
apply the scheme in PMIPv6. So, it does not introduce additional
security vulnerability other than security considerations related to
route optimization in MIPv6. However, since MAG performs mobility
signaling on behalf of MN, security considerations specified in
[I-D.ietf-netlmm-proxymip6] are also applied to this document.
When MAGs exchange binding information without return routability
procedures, MAGs pre-establish security association by using
bootstrapping. So, secure bootstrapping mechanism is required.
Also, signaling messages should be protected by IPsec ESP.
8. Normative References
[I-D.ietf-mip6-nemo-v4traversal]
Soliman, H., "Mobile IPv6 support for dual stack Hosts and
Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-04
(work in progress), March 2007.
Jeong & Wakikawa Expires January 3, 2008 [Page 11]
Internet-Draft Route Optimization for PMIPv6 July 2007
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-00
(work in progress), April 2007.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-01 (work in progress),
June 2007.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
Authors' Addresses
Sangjin Jeong
ETRI
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
Korea
Phone: +82-42-860-1877
Email: sjjeong@gmail.com
Ryuji Wakikawa
Keio University
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone:
Email: ryuji@sfc.wide.ad.jp
Jeong & Wakikawa Expires January 3, 2008 [Page 12]
Internet-Draft Route Optimization for PMIPv6 July 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).
Jeong & Wakikawa Expires January 3, 2008 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 17:30:07 |