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]