NETLMM Working Group M. Sahasrabudhe
Internet-Draft Nokia Siemens Networks
Intended status: Best Current V. Devarapalli
Practice Azaire Networks
Expires: August 18, 2008 February 15, 2008
Proxy Mobile IPv6 and Mobile IPv4 interworking
draft-meghana-netlmm-pmipv6-mipv4-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 August 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Proxy Mobile IPv6 protocol provides mobility management for an
IPv4-only mobile nodes. It provides network-based mobility
management and session continuity for the IPv4 mobile node as long as
the mobile node is attached to the Proxy Mobile IPv6 domain. The
mobile node that attaches to the Proxy Mobile IPv6 domain, may also
implement Mobile IPv4. When a Mobile IPv4-capable mobile node
attaches to a Proxy Mobile IPv6 domain, there are some interactions
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 1]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
between Proxy Mobile IPv6 and Mobile IPv4 that need to be studied.
This document looks at a particular scenario where the mobile node
transitions between using Proxy Mobile IPv6 and Mobile IPv4.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Transitioning between Proxy Mobile IPv6 and Mobile IPv4 . . . 3
3.1. Booting up in the PMIPv6 domain . . . . . . . . . . . . . 4
3.2. Handover from PMIPv6 domain to non-PMIPv6 domain . . . . . 6
3.3. Handover in to the PMIPv6 domain . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Application of PMIPv6 - MIPv4 interactions to
LTE-HRPD handovers . . . . . . . . . . . . . . . . . 12
A.1. LTE to HRPD Handover . . . . . . . . . . . . . . . . . . . 13
A.2. HRPD to LTE Handover . . . . . . . . . . . . . . . . . . . 13
A.3. Serving-GW Relocation . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 2]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
1. Introduction
The Proxy Mobile IPv6 protocol [3] is a network-based mobility
management protocol that provides mobility management for both IPv4
and IPv6 mobile nodes as long as they are attached to the same Proxy
Mobile IPv6 domain. These mobile nodes that attach to the Proxy
Mobile IPv6 domain may also implement host-based mobility management
protocols like Mobile IPv6 [5] or Mobile IPv4 [2]. The interactions
between Proxy Mobile IPv6 and Mobile IPv6 are described in [6]. This
document captures a scenario related to interactions between Proxy
Mobile IPv6 and Mobile IPv4.
The scenario of particular interest in this document is where the
MIPv4 Home Agent and the Proxy Mobile IPv6 Local Mobility Anchor
functionality are co-located on the same network node. The mobile
node performs handovers between the Proxy Mobile IPv6 domain and the
Mobile IPv4 foreign link. The Proxy Mobile IPv6 domain may also
appear as the home link for the mobile node with respect to Mobile
IPv4. This document describes this scenario in more detail.
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 [1].
3. Transitioning between Proxy Mobile IPv6 and Mobile IPv4
The following describes a scenario where the mobile node moves
between access network(s) that are part of the Proxy Mobile IPv6
domain and an access network that is outside the Proxy Mobile IPv6
domain. The mobile node implements the Mobile IPv4 mobile node
functionality as described in [2]. The Mobile IPv4 home agent
function and the Proxy Mobile IPv6 LMA function are co-located on the
same network node.
In this scenario, the mobile node uses Proxy Mobile IPv6 as long as
it is in the Proxy Mobile IPv6 domain. Since the mobile node is an
IPv4 node, the MAG obtains an IPv4 address from the LMA using the
Proxy Binding Update and Proxy Binding Acknowledgement exchange as
described in [4]. The MAG then assigns the IPv4 address to the
mobile node. The mobile node may also use DHCP to configure the IPv4
address as described in [4].
The mobile node has the Mobile IPv4 stack active at the same time,
but as long as it is attached to the same Proxy Mobile IPv6 domain,
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 3]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
it will appear as if it is attached to the home link. If the mobile
node attaches to an access network that is not part of the Proxy
Mobile IPv6 domain, it acquires a care-of address from the access
networks, treats the IPv4 address acquired earlier in the Proxy
Mobile IPv6 domain as the Mobile IPv4 home address and performs a
Mobile IPv4 registration. The Mobile IPv4 registration is performed
with the same home agent that was earlier a local mobility anchor in
the Proxy Mobile IPv6 domain. If the foreign link supports the
foreign agent functionality, the mobile node does not configure a co-
located care-of address.
The home agent supporting the mobile node based on host-based
mobility management, is also configured to function as a local
mobility anchor for supporting local mobility management. The IPv4
address configured by the mobile node in the Proxy Mobile IPv6 domain
is the same as the MIPv4 home address when the mobile node is
attached to a foreign link. This is illustrated in Figure 1.
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\domain ) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN]
MN obtains Mobile IPv4 HoA from HA
MIPv4 HoA = PMIPv6 IPv4 MN-HoA
Figure 1: Transitioning between PMIPv6 and MIPv4
3.1. Booting up in the PMIPv6 domain
According to Section 2 of RFC 3344 [2], the mobile node should
receive an Agent Advertisement from its home agent to detect that it
is attached to the home link. The Agent Advertisement from a home
agent is distinguishable by the presence of the 'H' bit in the
advertisement.
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 4]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
In the scenario presented in Section 3, the mobile node is attached
to the home link when it is in the Proxy Mobile IPv6 domain. When
the mobile node boots up in the Proxy Mobile IPv6 domain, it first
authenticates itself to the Mobile Access Gateway (MAG) and sets up a
point-to-point link with the MAG. The current Proxy Mobile IPv6
specification only supports point-to-point links between the mobile
node and the MAG. As soon as the point-to-point link is up, the
mobile node should send an agent solicitation to check if it is
attached to the home link. When the MAG sees the agent solicitation
from the mobile node, it identifies that the mobile node has the
Mobile IPv4 client active. The MAG then sends an Agent Advertisement
on behalf of the Home Agent function co-located with the LMA
function. The 'Router Address' field in the Agent Advertisement is
set to the IPv4 address of the co-located MIPv4 Home Agent and PMIPv6
LMA functions.
When the mobile node receives the Agent Advertisement with the 'H'
flag set, it discovers that it is attached to the MIPv4 home link.
The mobile node extracts the address from the 'Router Address' field
in the Agent Advertisement and stores it as the MIPv4 home agent
address.
Figure 2 shows the sequence of steps by which the mobile node
discovers that it is attached to the home link.
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 5]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
MN MAG AR/FA LMA/HA
| | | |
| 1. Attach to MAG | | |
|<=================>| | |
| | | 2.Proxy BU |
| |------------------------------->|
| | | | IPv4 MN-HoA
| | | 3.Proxy BAck | allocation
| |<-------------------------------|
| | | |
| | |4. PMIPv6 tunnel|
| |================================|
| |================================|
| | | |
| 5. IP Addr assign | | |
|<=================>| | |
| (L2 mechanism or | | |
| using DHCP) | | |
| | | |
| 6. HA Advert | | |
|<------------------| | |
| | | |
|9. MN at | | |
| home | | |
Figure 2: Booting Up in the PMIPv6 domain
3.2. Handover from PMIPv6 domain to non-PMIPv6 domain
When the mobile node moves to an access network that is outside the
Proxy Mobile IPv6 domain, it starts Mobile IPv4 operation. The
mobile node performs movement detection as specified in [2]. If
there is a foreign agent on the access network, it starts using the
foreign agent. If there is no foreign agent on the access network,
the mobile node configures a care-of address from the access network.
Once the mobile node configures a care-of address from the access
network, it sends a registration request to the home agent. It uses
the home agent address obtained via the Home Agent Advertisement it
received while attached to the home link in the Proxy Mobile IPv6
domain. The mobile MAY include the IPv4 address configured when
attached to the Proxy Mobile IPv6 domain as the home address in the
registration request. The mobile node MAY also set the home address
to 0.0.0.0 in the registration request as specified in [2].
When the home agent receives the registration request for the mobile
node, it processes the registration request and creates a Mobile IPv4
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 6]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
binding cache entry for the mobile node. If there is a Proxy Mobile
IPv6 binding cache entry for the mobile node, that entry is deleted.
If the registration request had a valid home address, the home agent
creates a binding cache entry for the home address. If the
registration request had the home address field set to 0.0.0.0, the
home agent allocates the PMIPv6 IPv4 MN-HoA previously assigned to
the mobile node as the Mobile IPv4 home address. The home agent then
sends a registration reply to the mobile node as specified in [2].
Figure 3 shows the sequence of steps involved in the handover from a
Proxy Mobile IPv6 domain to an access router or a foreign agent
outside the Proxy Mobile IPv6 domain.
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 7]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
MN MAG AR/FA LMA/HA
| | | |
| 1. MN attached to | PMIPv6 tunnel |
| PMIPv6 domain |================================|
|<=================>|================================|
| | | |
|2. MN | | |
| moves | | |
| | | |
| 3. Attach to AR/FA | |
|<=================================>| |
| | | |
| 4. FA Agent Advert| | |
|<----------------------------------| |
| | | |
| 5. Registration | | |
| Request (HoA = 0.0.0.0) | |
|---------------------------------->| |
| | | |
| | |6. Registration |
| | | Request |
| | |--------------->|
| | | |IPv4 MN-HoA
| | | |allocated as
| | | |MIPv4 HoA
| | |7. Registration |
| | | Reply (HoA) |
| | |<---------------|
| | | |
| 8. Registration Reply (HoA) | |
|<----------------------------------| |
| | | |
| | |9. MIPv4 tunnel |
| | |================|
| | |================|
| | | |
The MIPv4 tunnel would be between the MN and the LMA/HA in the
co-located CoA mode.
Figure 3: Handover from PMIPv6 domain to non-PMIPv6 domain
3.3. Handover in to the PMIPv6 domain
When the mobile node moves in to an access network that is part of
the Proxy Mobile IPv6 domain, it is again attached to its home link.
It detects that it is attached to the home link when it receives a
home agent advertisement advertising the home link.
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 8]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
When the mobile node moves into the Proxy Mobile IPv6 domain, the LMA
receives a Proxy Binding Update from the MAG. The LMA that is co-
located with the Mobile IPv4 home agent functions responds with an
IPv4 address that is the same as the Mobile IPv4 home address. The
LMA also deletes the Mobile IPv4 binding cache entry for the mobile
node and creates a proxy binding cache entry for the mobile node.
The LMA then sends a Proxy Binding Acknowledgement message to the MAG
with the assigned IPv4 address. The MAG after processing the Proxy
Binding Acknowledgement, sends a Home Agent advertisement message to
the mobile node.
When the mobile node detects that it is attached to the home link, it
sends a registration request to the home agent with lifetime set to
zero to delete the binding cache entry. If the home agent receives a
de-registration message (registration request with lifetime set to
zero), when there is a proxy binding cache entry for the mobile node,
it MUST NOT delete the proxy binding cache entry. Instead it MUST
respond to the mobile node with a registration reply acknowledging
the de-registration.
Figure 4 shows the sequence of steps involved in the handover from an
access link outside the Proxy Mobile IPv6 domain in to the Proxy
Mobile IPv6 domain.
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 9]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
MN MAG AR/FA LMA/HA
| | | |
| | | MIPv4 tunnel |
| 1. MN attached to AR/FA |================|
|<=================================>|================|
| | | |
|2. MN | | |
| moves | | |
| | | |
| 3. Attach to MAG | | |
|<=================>| | |
| | | |
| | | 4.Proxy BU |
| |------------------------------->|
| | | | MIPv4 HoA
| | | | allocated as
| | | 5.Proxy BAck | IPv4 MN-HoA
| |<-------------------------------|
| | | |
| | |6. PMIPv6 tunnel|
| |================================|
| |================================|
| | | |
| 7. IP Addr assign | | |
|<=================>| | |
| (L2 mechanism or | | |
| using DHCP) | | |
| | | |
| 8. HA Advert | | |
|<------------------| | |
| | | |
|9. MN at | | |
| home | | |
Figure 4: Handover in to the PMIPv6 domain
4. Security Considerations
In the scenario described in Section 3, the mobile node transitions
between using Proxy Mobile IPv6 and Mobile IPv4. The binding cache
entry for the mobile node may be modified both by the MAGs in the
PMIPv6 domain and the mobile node. In Mobile IPv4, the binding cache
entry created by the mobile node can only be modified by the mobile
node. This document requires that the MIPv4 home agent that also
implements the PMIPv6 LMA functionality should allow both the mobile
node and the authorized MAGs to modify the binding cache entry for
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 10]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
the mobile node.
5. IANA Considerations
This document requires no action from IANA.
6. Acknowledgments
The authors would like to thank Lalit Kotecha for interesting
discussions on this topic.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[3] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10
(work in progress), February 2008.
[4] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile
IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in
progress), November 2007.
7.2. Informative References
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[6] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios
and related issues", draft-giaretta-netlmm-mip-interactions-02
(work in progress), November 2007.
[7] 3rd Generation Partnership Project, "3GPP Technical
Specification 23.402 V8.0.0: Technical Specification Group
Services and System Aspects; Architecture enhancements for non-
3GPP accesses (Release 8)", December 2007.
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 11]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
Appendix A. Application of PMIPv6 - MIPv4 interactions to LTE-HRPD
handovers
The 3GPP specification TS 23.402 [7] specifies handovers between 3GPP
LTE access and 3GPP2 HPRD access. This section describes how the
inter-working mechanism specified in Section 3 can be applied to
handovers between LTE and HRPD access networks.
The interworking between Mobile IPv4 and Proxy Mobile IPv6 is
especially of interest for the LTE-HRPD inter-system handover. The
HRPD network already has the Mobile IPv4 protocol implemented and
deployed. The LTE network will have the Proxy Mobile IPv6 protocol
deployed to support mobility management for the mobile node. For
handsets that are dual mode (support both LTE and HRPD technologies)
there is no common mobility protocol.
Mobility management for the mobile node can be supported though for
these nodes by having an interworking solution between Mobile IPv4
and Proxy Mobile IPv6. This solution should work for nodes that may
not implement IPv6 and should work with minimal changes to legacy
nodes on the HRPD network, for example, the PDSN.
The solution described in this document introduces the concept of
making the mobile node appear to be on the Home link with respect to
the Mobile IPv4 protocol when it is attached to the LTE network and
is in the PMIPv6 domain. When the Mobile Node is in the HRPD
network, Mobile IPv4 Foreign Agent care-of address mode is used.
The solution requires the Proxy Mobile IPv6 LMA functionality and the
Mobile IPv4 home agent functionality to be co-located which will most
likely reside on the PDN-GW in the LTE network.
When the mobile node first attaches to the LTE network, during
authentication the MN profile will indicate that this is a dual mode
MN that has subscription on both the LTE and HRPD networks. The
profile can additionally indicate that the Mobile Node is an IPv4
only node. When the MAG on the Serving-GW sends the Proxy Binding
Update (PBU) message to the LMA, it requests for a dynamic IPv4 Home
Address allocation for the MN. It does so by setting the IPv4 Home
Address field to all zeros in the IPv4 Home Address option.
The LMA that can reside on the PDN-GW assigns an IPv4 HoA to the
mobile node and returns this address in the Proxy Binding
Acknowledgement message to the MAG. Once the PMIPv6 tunnel between
the MAG and the LMA is set up, the S-GW sends out a Home Agent
Advertisement message for the mobile node with the home agent address
set to the PDN-GW address. This indicates to the mobile node that it
is attached to the home link.
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 12]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
A.1. LTE to HRPD Handover
In the LTE to HRPD handover, the PDSN downloads the mobile node
profile during access authentication. The profile would indicate
that the mobile node is a dual mode device that can connect to the
LTE as well as HRPD network. The profile may also indicate to the
PDSN that it should use a certain PDN-GW as the Mobile IPv4 home
agent for the mobile node.
The PDSN sends a Foreign Agent Advertisement message. This Agent
advertisement prompts the MN to send a Mobile IPv4 Registration
request message. The home address field in the message is set to
0.0.0.0. The PDSN forwards the registration request to the PDN-GW.
The PDN-GW acting as the Mobile IPv4 home agent returns the same
address that was assigned as Proxy Mobile IPv6 IPv4 MN-HoA as the
Mobile IPv4 home address.
The home address is returned to the PDSN in a Mobile IPv4
Registration Reply message. The Foreign Agent function on the PDSN
forwards the Registration Reply message to the mobile node indicating
the Mobile IPv4 home address to use.
The mobile node can now roam on the HRPD network using the Mobile
IPv4 protocol and the MIPv4 home address using the FA address on the
PDSN as the care-of address.
A.2. HRPD to LTE Handover
When a HRPD to LTE handover is performed, the access authentication
phase supplies the mobile node's profile to the MME. This indicates
to the MME that the MN is a dual mode handset that is capable of
interworking. Once the bearer establishment between mobile node and
the Serving-GW is done, the Serving-GW will send a Proxy Binding to
the PDN-GW to perform a PMIPv6 registration. The Serving-GW will
request for an IPv4 address for the MN in the Proxy Binding Update
message.
The PDN GW responds with a Proxy Binding Acknowledgement including
the IPv4 MN-HoA information. This creates a PMIPv6 tunnel between
the MAG on the Serving-GW and the LMA on the PDN-GW. The Serving-GW
then sends a Home Agent advertisement on behalf of the PDN-GW to make
it appear to the mobile node that it is attached to the home link.
A.3. Serving-GW Relocation
When the mobile node moves from one Serving-GW to another in the
Proxy Mobile IPv6 domain, it is assigned the same IPv4 address. As
long as the mobile node attaches to MAGs inside the Proxy Mobile IPv6
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 13]
Internet-Draft PMIPv6 and MIPv4 interworking February 2008
domain, mobility management is done using Proxy Mobile IPv6. The
mobile node configures the same IPv4 MN-HoA across the Proxy Mobile
IPv6 domain. The Serving-GWs that the mobile node attaches to send a
Home Agent advertisement to the mobile node to make it appear that it
is still attached to the home link.
Authors' Addresses
Meghana Sahasrabudhe
Nokia Siemens Networks
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: meghana.sahasrabudhe@nsn.com
Vijay Devarapalli
Azaire Networks
3121 Jay Street
Santa Clara, CA 95054
USA
Email: vijay.devarapalli@azairenet.com
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 14]
Internet-Draft PMIPv6 and MIPv4 interworking February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 15]