NEMO Working Group J. Ryu Internet-Draft N. Choi Expires: December 21, 2006 Seoul National University E. Paik KT T. Kwon C. Park Seoul National University June 19, 2006 Bypassing Ingress Filtering for Multihomed mobile network draft-ryu-nemo-ingress-filtering-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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In this draft, a solution of the ingress filtering problem is proposed for a NEMO with multiple mobile routers. Extending the multiple care-of address registration mechanism and introducing a Ryu, et al. Expires December 21, 2006 [Page 1] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 "prefix peer" relationship among the mobile routers, we can solve the ingress filtering problem in a NEMO with multiple mobile routers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Prefix peer care-of address registration . . . . . . . . . 5 4.2. Prefix peer care-of address de-registration . . . . . . . 6 4.3. Bypassing ingress filtering . . . . . . . . . . . . . . . 6 5. Multiple care-of address extensions . . . . . . . . . . . . . 7 5.1. Binding Cache Structure Changes . . . . . . . . . . . . . 7 5.2. Binding Update Structure Changes . . . . . . . . . . . . . 7 5.3. Message Format Changes . . . . . . . . . . . . . . . . . . 7 5.3.1. Binding Unique Identifier sub-option . . . . . . . . . 7 5.4. HA Operation . . . . . . . . . . . . . . . . . . . . . . . 8 5.4.1. Registration and de-registration . . . . . . . . . . . 8 5.5. MR Operation . . . . . . . . . . . . . . . . . . . . . . . 8 5.5.1. Registration and de-registration . . . . . . . . . . . 8 5.6. New Message Format . . . . . . . . . . . . . . . . . . . . 9 5.6.1. ICMP Mobile Router Hint . . . . . . . . . . . . . . . 9 5.6.2. ICMP Mobile Router Hint Acknowledgement . . . . . . . 10 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. MR Failover . . . . . . . . . . . . . . . . . . . . . 12 A.1. HA operation . . . . . . . . . . . . . . . . . . . . . . . 13 A.2. MR operation . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Ryu, et al. Expires December 21, 2006 [Page 2] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 1. Introduction Recently, the NEMO working group [1] is dealing with the multihoming issues [2] in NEMO and is also concerned about an ingress filtering problem. However, there is no suitable solution for the ingress filtering problem in multihomed NEMO. So, we consider about this ingress filtering problem when there are multiple MRs, HAs, and MNPs. Suppose that there is a multihomed NEMO which has multiple MRs. If any MN wnats to handover to other MRs it should change its address. The stateless or stateful auto-configuration procedure of IPv6 for the acquisition of a new care-of address is used in this case, it takes very long time and connectivity cannot be sustained. In addition, if any MR fails, and hence it cannot provide any more service, one of the backup MRs should provide service on behalf of the blocked one. But in this case, if the mobile and fixed nodes are provided the Internet service by the backup MR with no change of their addresses, ingress filtering problem will occur. Accordingly, we propose a prefix peer CoA registration mechanism in this draft. The mobile and fixed nodes can be provided the Internet service without the ingress filtering problem nor address changing in the above situation using our proposed mechanism. And MN's soft handover is also possible while maintain its connectivity. Our proposed mechanism extends the multiple CoA registration mechanism for a multihomed host [3]. 2. Terminology Terms used in this draft are defined in [4], [5] and [6]. We define or redefine the following ones: Active Mobile Router An Active mobile router is an MR that is currently used and advertises its own mobile network prefix (MNP). Blocked Mobile Router A blocked mobile router is an MR i) whose egress interface or ingress interface fails. ii) itself fails. Here, "failure" means an MR loses the connectivity due to mobility, fading and so on. Peer Mobile Router A peer mobile router is an MR capable of providing Internet services instead of a blocked or an active MR. A peer MR (PMR) should be first authenticated by an active MR or its HA in the same NEMO to prevent malicious nodes from spoofing. An MR hearing Ryu, et al. Expires December 21, 2006 [Page 3] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 router advertisement (RA) messages from neighboring MRs initiates a PMR authentication depending on its policy. Also, the technique proposed in [7] can be also used for the PMR authentication. Prefix Peer Binding Update (PPBU) Prefix peer binding update means that this binding update message is sent by PMRs. PPBU has different meanings depending on the alternative flag in Binding Unique Identifier sub-option. If the alternative flag is set to 1, it means that a PMR sends this binding update message for PMR registration. Otherwise, this binding update message is sent by a PMR to change the active CoA of the MNP in binding cache of a HA. Active CoA An active CoA is a CoA that is currently used in the NEMO. The active field in binding cache entry of the HA corresponding to the CoA is set to 1. Peer CoA A peer CoA is a CoA that is assigned to the egress interface of a PMR. This CoA will be used to provide Internet service instead of a blocked mobile router. ICMP Mobile Router Hint The ICMP Mobile Router Hint message is sent by the active or blocked MR to its PMR. By this message, the PMR can know the state of the active MR more quickly and HA address of the active or blocked MR to perform PPBU. This is an option. 3. Problem Statement When there are multiple MRs in a multihomed mobile network, the MNP of each MR can be different from each other. When an MN wants to handover to another MRs without address changes or an MN of the blocked MR directly uses the peer MR without address change, an MN will send a packet to peer MR. The MR2, which is the peer MR, has only one tunnel to HA2 so all packets arrived at MR2 will be forwarded. And then this packet must be discarded at a home network of the peer MR because of the ingress filtering according to a policy of ISP. So, we need the solution of ingress filtering. For this, we introduce how to bypass ingress filtering. The detailed operation is followed. Ryu, et al. Expires December 21, 2006 [Page 4] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 +-----+ +-----+ | HA1 | | HA2 ==(Discarded) +--+--+ +--=--+ | = +--+----------=----+ MR2's +-----+ | Internet === |=======| MR2 | +--------------+---+ CoA +--+--+ | | = | +--+--+ | = | | CN | MR1's|CoA = | +-----+ +-----+ = |MNP2(+ MNP1) | MR1 | = | +--+--+ = | MN leaves MR1 = | | = | +--+-=------------+--+ | === NEMO | +--------------------+ = : path of MR1's packet when MR1 has some problem Figure 1. Ingress filtering problem. 4. Protocol Overview To provide a way to bypass ingress filtering for a multihomed mobile network, we propose to make a "prefix peer" relationship among the MRs. The prefix peer relationship is realized by introducing a prefix peer binding update (PPBU) message. Detailed operations are described in the following chapters. 4.1. Prefix peer care-of address registration Prefix peer CoA registration is an extended version of multiple CoAs registration mechanism for mobile IPv6 [4]. An MR can register not only its CoA but also delegate its PMR to register the PMR's CoA as a peer CoAs by using multiple CoAs registration. The registered CoA of PMRs is used to provide continuous Internet service and to bypass ingress filtering. If the MR wants to delegate its PMR to register the PMR's CoA, it must generate a BID and use this when it sends BU. The PMR also generate a BID and use that when it sends a PPBU. After receiving the BU or the PPBU, the HA adds or updates an entry corresponding to the CoA in the BU or the PPBU into its binding cache. Ryu, et al. Expires December 21, 2006 [Page 5] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 4.2. Prefix peer care-of address de-registration If the MR is plan to move another network or it can not provide peer services, it should de-register its CoA. When the MR wants to de- register its CoA, it sends a PPBU with the unset prefix peer flag in the Binding Update identifier sub-option to the HA which has this CoA entry as a peer CoA in its binding cache. After receiving this PPBU, the HA deletes this CoA entry from its binding cache. 4.3. Bypassing ingress filtering The point of our mechanism is that there are no IP address changes. The PMR takes over service of an active or a blocked MR by relaying the packets from an active or a blocked MR's node. Since a source address of that packet is not changed, ingress filtering will not occur. IF the PMR starts advertising the MNP of the active or blocked MR in addition to its own MNP, the PMR can provide Internet service for the active or blocked MR's node. That is, if the PMR receives a packet from fixed nodes or MNs belonging to the MNP of the active or the blocked MR, it forwards the packet through an appropriate tunnel between the HA of the active or the blocked MR and itself for seamless connectivity. So, ingress filtering problem is solved because there are no IP address changes. +-----+ +-----+ | HA2 | ==| HA1 | +--+--+ = +--=--+ | = = = +--+-=--------=----+ MR2's +-----+ | = Internet = = |=======| MR2 | +--=-----------+---+ CoA +--+--+ = | = | +--+--+ | = | | CN | MR1's|CoA = | +-----+ +-----+ = |MNP2(+ MNP1) | MR1 | = | +--+--+ = | MN leaves MR1 = | | = | +--+-=------------+--+ | === NEMO | +--------------------+ = : path of MR1's packet when MR1 has some problem Figure 2. Bypassing ingress filtering concept. Ryu, et al. Expires December 21, 2006 [Page 6] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 Especially, we illustrate the multihomed NEMO which consists of 2 HAs, 2 MRs, and 2 MNPs. The MR1 and the MR2 have a peer relationship each other using prefix peer binding update. If MN of MR1 wants to handover to MR2 or there are some problem (ingress or egress interface failure) at MR1, the peer MR (MR2) will take over the MR1's service. Packets from an MN or a fixed node of MR1 will be forwarded to HA1 through MR2, so there is no ingress filtering problem. 5. Multiple care-of address extensions 5.1. Binding Cache Structure Changes To support bypassing ingress filtering, there are multiple MRs in a multihomed NEMO. Hence, additional fields are defined in the binding cache structure as follow: - Active : Active means the CoA is now in use. The value MUST be zero if the CoA is not active. - Peer : Peer means this CoA is a PMR's one. The value MUST be zero if the CoA is not a PMR's CoA. 5.2. Binding Update Structure Changes Additional flags are required in the binding update structure, which are: - Prefix peer flag : Prefix peer flag MUST be set to 0 if the binding update is not sent by a peer MR or is used for de-registration of prefix peer CoA by PMR. - Alternative flag : Alternative flag MUST be set to 1 if the CoA is the peer CoA. 5.3. Message Format Changes Additional flags are required in the binding update structure, which are: 5.3.1. Binding Unique Identifier sub-option New Alternative (A) flag and new prefix peer flag (P) are included in the Binding Unique Identifier sub-option. The rest of the Binding Unique Identifier sub-option format remains the same as defined in [3]. Ryu, et al. Expires December 21, 2006 [Page 7] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Unique ID (BID) | Priority |B|P|A| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ Prefix Peer (P) The prefix peer flag is set to indicate to the HA whether this BU is sent by the PMR (PPBU) or a peer CoA de-registration for already registered one. If the flag is set to 0, it is just a BU or the de-registration sent by PMR. Alternative (A) The alternative flag is set to indicate to the HA whether the CoA in the binding update is a peer CoA or not. If this flag in PPBU is set to 0, the active filed of this CoA in binding cache should be set. For descriptions of the other fields in the message, see [3]. 5.4. HA Operation 5.4.1. Registration and de-registration When the HA receives the PPBU message that includes the CoA of a PMR with alternative flag set to 1, it checks its binding cache. If the HA does not have this CoA entry in its binding cache, it adds an entry corresponding to this CoA as a peer CoA. The binding cache entry has an active field set to 0 and a peer field set to 1. When the HA receive the BU message that includes the CoA of a PMR with alternative flag set to 1, it also checks its binding cache. If the HA does not have this CoA entry in its binding cache, it silently discards this packet. If it does, it deletes this CoA entry. After management its binding cache, the HA responds BU ACK to the PMR. 5.5. MR Operation 5.5.1. Registration and de-registration After the successful PMR authentication, the PMR sends a PPBU to the HA of the active MR for peer MR registration. This PPBU includes the CoA of a PMR and alternative flag set to 1 in Binding Update Identifier sub-option. If the PMR wants to de-register its CoA, it sends a PPBU with the unset prefix peer flag in the Binding Update Ryu, et al. Expires December 21, 2006 [Page 8] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 identifier sub-option and alternative flag set to 1 to the HA which has this CoA entry as a peer CoA in its binding cache. 5.6. New Message Format 5.6.1. ICMP Mobile Router Hint The ICMP Mobile Router Hint message is sent by the active or blocked MR to its PMR. By this message, the PMR can know the state of the active MR more quickly and HA address of the active or blocked MR to perform PPBU. If code value is 1, it means that this Hint message (Failure Notify) doesn't need an ACK message. This ICMP MR Hint message is an option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . HA Address . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address Home address of the active or blocked MR. Destination Address Home address of the PMR. ICMP Fields: Type Ryu, et al. Expires December 21, 2006 [Page 9] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 154 Code 0 = Failure notify; 1 = Failure notify without ACK; 2 ~ 255 = reserved. Checksum The ICMP checksum [8]. Identifier An identifier to aid in matching MR Hint acknowledgement messages to this MR Hint message. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. HA address HA address of the blocked MR. 5.6.2. ICMP Mobile Router Hint Acknowledgement The ICMP Mobile Router Hint Acknowledgement message is used by a PMR to respond to the active or blocked MR that sends an ICMP Mobile Router Hint message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Ryu, et al. Expires December 21, 2006 [Page 10] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 Source Address Home address of the PMR. Destination Address Home address of the active or blocked MR. ICMP Fields: Type 155 Code 0 = Failure notify ACK; 1 ~ 255 = reserved. Checksum The ICMP checksum [8]. Identifier The identifier from the invoking MR Hint message. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 6. Conclusion In this draft, we propose a solution of the ingress filtering problem on multihomed NEMO. The peer MRs can provide continuous Internet service to an MN for seamless MR handover or any node that has been attached to a blocked MR, thus ingress filtering problem can be avoided. For our proposed scheme, very few modifications to multiple care-of address registration and NEMO are required. 7. Security Consideration In this draft, we assume that a peer MR is already authenticated by using an MR authentication mechanism [7]. However, it is necessary Ryu, et al. Expires December 21, 2006 [Page 11] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 to design more secure authentication mechanism with low overhead. 8. References [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [2] Ng, C., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-05 (work in progress), February 2006. [3] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-05 (work in progress), March 2006. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-05 (work in progress), March 2006. [7] Choi, S., "Neighbor MR Authentication and Registration Mechanism in Multihomed Mobile Networks", draft-cho-nemo-mr-registration-00 (work in progress), April 2004. [8] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. Appendix A. MR Failover In this section, the mechanism of MR failover is described. In general, an MR uses the wireless channel as an egress interface for NEMO support. Because this wireless channel is subject to disconnectivity due to channel error, blackout, or handover, some link failures may occur. After the HA of an active MR authenticates and registers a PMR successfully, the PMR should be able to take over if the active MR fails. Ryu, et al. Expires December 21, 2006 [Page 12] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 +-----+ +-----+ | HA1 | | HA2 | +--+--+ +--+--+ | | | | +---+----------+----+MR2's +-----+ | Internet |------| MR2 | +---+----------+----+ CoA +--+--+ |MNP2(with MNP1) (failure) | +-----+ | | MR1 | | +--+--+ | | | | | +--+--------------+--+ | NEMO | +--------------------+ Figure 3. Multi-homed NEMO with blocked MR1 A.1. HA operation When a HA1 receives a PPBU with the unset alternative flag in the Binding Update Identifier sub-option but the peer field in binding cache entry of this HA corresponding to the CoA in the PPBU is set to 1, the HA1 assumes that the MR1 fails. If the HA1 does not have any entry corresponding to this CoA, it silently discards this message. The CoA of the active MR1 in binding cache whose active field set to 1 cannot be used because of active MR failure. Thus its active field is set to 0. An active field corresponding to the CoA in a PPBU is set to 1. A.2. MR operation If an MR1 detects its ingress (or egress) interface failure, it should immediately stop advertising its prefix and may send a new ICMP Mobile Router Hint message (code = 0) to the PMR (MR2). Any PMR detects an egress (or ingress) interface failure of the active MR (MR1), the PMR sends a PPBU to the HA1. The alternative flag of the Binding Update Identifier sub-option in this PPBU is set to 0. After receiving the PPBU ACK, this PMR replies a new ICMP Mobile Router Hint Acknowledgement (code = 0) to the blocked MR if it received ICMP MR Hint message. The PMR (MR2) starts advertising the MNP1 in addition to its own MNP (MNP2). The PMR (MR2) can provide Internet service for fixed and MNs instead of the blocked MR (MR1). That is, if the PMR (MR2) receives a packet from fixed or mobile nodes Ryu, et al. Expires December 21, 2006 [Page 13] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 belonging to the MNP of the blocked MR, it can forward the packet through an appropriate tunnel between the HA of the blocked MR and itself for seamless connectivity. Ryu, et al. Expires December 21, 2006 [Page 14] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 Authors' Addresses Jiho Ryu Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-1848 Fax: +82-2-872-2045 Email: jhryu@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~jhryu/ Nakjung Choi Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-876-7170 Fax: +82-2-876-7170 Email: fomula@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~fomula/ Eunkyoung Paik KT Advanced Technology Lab. KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5233 Fax: +82-2-526-5759 Email: euna@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/ Ryu, et al. Expires December 21, 2006 [Page 15] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 Taekyoung Kwon Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9105 Fax: +82-2-872-2045 Email: tk@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~tk/ Chulhyun Park Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-876-7170 Fax: +82-2-876-7170 Email: chpark@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~chpark/ Ryu, et al. Expires December 21, 2006 [Page 16] Internet-Draft Bypassing Ingress Filtering for NEMO June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ryu, et al. Expires December 21, 2006 [Page 17]