Network Working Group J-H. Na Internet-Draft ETRI Intended status: Standards Track S. Park Expires: January 12, 2009 Chungnam National University J-M. Moon S. Lee ETRI E. Lee S-H. Kim Chungnam National University July 11, 2008 Roaming Mechanism between PMIPv6 Domains draft-park-netlmm-pmipv6-roaming-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2009. Na, et al. Expires January 12, 2009 [Page 1] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 Abstract Proxy Mobile IPv6 (PMIPv6) is designed to provide mobility service to mobile nodes in the network domain which does not require the mobile nodes to be involved in IP mobility management. In other words, the PMIPv6 can transparently support roaming within a PMIPv6 domain, i.e. intra-domain roaming, to mobile nodes. However, if the mobile nodes move to other PMIPv6 domains, the nodes should have additional protocols for the inter-domain roaming although the domains also provide the transparent mobility. Hence, an inter-domain roaming solution would be needed for providing transparent mobility to mobile nodes that only move around among PMIPv6 domains. This document specifies the inter-domain roaming controlled by the networks adopting the PMIPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Inter-Domain Roaming Overview . . . . . . . . . . . . . . . . 6 3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 4. Roaming Mechanism Operations . . . . . . . . . . . . . . . . . 9 4.1. Control Plan Flow . . . . . . . . . . . . . . . . . . . . 9 4.2. Data Plan Flow . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Na, et al. Expires January 12, 2009 [Page 2] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 1. Introduction PMIPv6 [I-D.ietf-netlmm-proxymip6] is a network-based mobility management protocol that does not require mobile nodes to be involved in mobility management. In a PMIPv6 domain, a Mobile Access Gateway (MAG) performs signaling with a Local Mobility Anchor (LMA) for mobility management on behalf of mobile nodes attached to the MAG. The LMA functions as the home agent for the mobile nodes in the PMIPv6 domain. If a mobile node moves and changes its point of attachment from one MAG to the other, it can still continue to use the same address configuration by the signaling between the MAGs and the LMA of the node [I-D.ietf-netlmm-proxymip6]. In other words, PMIPv6 can only support roaming within a PMIPv6 domain transparent to mobile nodes without mobility functionality. Next-generation wireless networks, such as 802.16e [IEEE802.16e] and Super 3G/3.9G [3GPP], have the potential to run IP deeper into the access network than the current 3G cellular networks, similar to today's WLAN networks [RFC4830]. It means such various and heterogeneous access networks would be routed IP networks. Also, the access networks would provide IP mobility by PMIPv6 since the access networks try to adopting PMIPv6 protocol as local mobility management solution specified in [3GPP] [WiMAX]. This development might lead to frequent roaming of mobile nodes within a PMIPv6 domain, i.e. intra- domain roaming, and between PMIPv6 domains, i.e. inter-domain roaming. Existing inter-domain roaming solution described in [I-D.giaretta-netlmm-mip-interactions] considers interworking between PMIPv6 and MIPv6 [RFC3775]. It means that a mobile node should have MIPv6 and be involved in mobility management via the MIPv6 if the mobile node in a PMIPv6 domain moves into another PMIPv6 domain. However, such involvement of mobile nodes causes several considerable and ironical problems as follows. o If a mobile node involves MIPv6 protocol stack, the mobile node suffers update latency, signaling overhead, and location privacy problems described in [RFC4830] although the node is located in the domain adopting PMIPv6 proposed to solve such problems. o If a mobile node involves MIPv6 protocol stack, the visited PMIPv6 domain can not provide transparency to the mobile node though the domain also support transparent mobility to the mobile node in network-based management manner. o If a mobile node that do not have MIPv6 protocol stack, the visited PMIPv6 domain can not provide seamless IP mobility to the mobile node although the domain also offers mobility management Na, et al. Expires January 12, 2009 [Page 3] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 service. This document specifies roaming mechanism between PMIPv6 domains to provide transparent and seamless inter-domain mobility to mobile nodes. In this solution, LMAs and MAGs in two domains perform exchange of signaling messages to mobility management on behalf of mobile nodes. The signaling is performed to re-establish bi- directional tunnels for data flow and emulate home link of each mobile node. Thus, the mobile node can maintain session continuity via a global unicast IPv6 address organized in home PMIPv6 domain if the mobile nodes move into visited PMIPv6 domain. Namely, inter- domain roaming of the mobile nodes can be supported transparently in network-based manner like intra-domain roaming. Na, et al. Expires January 12, 2009 [Page 4] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses the terminology defined in [RFC3775], [I-D.ietf-netlmm-proxymip6]. All user authentication and prefix allocation related terms are defined in [RFC2865], [RFC3588], [RFC4818]. o Home PMIPv6 Domain - This refers to the network where a mobile node registered to be provided the network-based mobility management service and the mobility management of the mobile node is handled using the Proxy Mobile IPv6 protocol. o Visit PMIPv6 Domain - This refers to any PMIPv6 network other than Home PMIPv6 Domain of a mobile node, to which the mobile node is currently connected. Through a contact among PMIPv6 domains, it provides the networks-based mobility management service to mobile nodes of other PMIPv6 domains when they enter in it. o Intra-Domain Roaming - This means that a mobile node is provided network-based mobility management support, without requiring the participation of it in any mobility related signaling when the mobile node moves between MAGs within a PMIPv6 domain. o Inter-Domain Roaming - This means that a mobile node is provided network-based mobility management support, without requiring the participation of the mobile node in any mobility related signaling when the mobile node moves into other PMIPv6 domains. o LMAh - This is the Local Mobility Anchor for a mobile node in the Home PMIPv6 domain. It is the topological anchor point for the mobile node's home network prefix and manages the mobile node's binding state. It has the functional capabilities of a Local Mobility Anchor as defined in Proxy Mobile IPv6 base specification [I-D.ietf-netlmm-proxymip6] with the additional capabilities required for supporting the inter-domain roaming as defined in this specification. o LMAv - This is a Local Mobility Anchor in the Visit PMIPv6 Domain to which a mobile node visits. To support the network-based mobility management service to the mobile node, it establishes a bi-directional tunnel with the LMAh in the Home PMIPv6 Domain of the mobile node and delivers data on behalf of the mobile node through the tunnel. Na, et al. Expires January 12, 2009 [Page 5] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 3. Inter-Domain Roaming Overview This specification describes a network-based roaming mechanism between Proxy Mobile IPv6 domains. It is called Inter-Domain Roaming and based on Proxy Mobile IPv6[I-D.ietf-netlmm-proxymip6]. Inter-Domain Roaming mechanism is intended for providing network- based mobility management support to a mobile node, without requiring the participation of the mobile node in any mobility related signaling when the mobile node moves an access network in other proxy domains. The core functional entity in the Inter-Domain Roaming is the Local Mobility Anchor (LMA). The LMA is defined as Visited LMA(LMAv) and home LMA(LMAh) for inter-proxy domain roaming. LMAv is a local mobility anchor in visited proxy domain and LMAh is a local mobility anchor in home proxy domain. The local mobility anchor is responsible for rechability of the mobile node and is the topological anchor point for home network prefix of the mobile node. 3.1. Scenarios Figure 1 shows a circumstance of the roaming between PMIPv6 domains. A MN receives its home network prefix in a PMIPv6 home domain and configures its address, MN-HoA. The MN sends and receives data by using the HoA during moving in the home domain. Even though the MN moves into a PMIPv6 visit domain, the MN sends and receives data without cutoff of the session by using the MN-HoA, as the MN resides in the domain that PMIPv6 service is possible. Na, et al. Expires January 12, 2009 [Page 6] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 +----+ +--------| CN | | +----+ +---------------|---+ +-----| Internet Backbone |-----+ | +-------------------+ | | | +--------------|-----------+ +------------|-------------+ |Visit +------+ ______________________ +------+ Home | |PMIPv6 | LMAv |-______________________-| LMAh | PMIPv6| |Domain +------+ | | +------+ Domain| | | <-- LMAAv | | LMAAh --> | | | / / | | \ \ | | / / | | \ \ | | / / +------+ | | +------+ \ \ | | / / | AAAv | | | | AAAh | \ \ | | / / +------+ | | +------+ \ \ | | / / | | \ \ | | / / | | \ \ | | | <-- Proxy-CoAv | | Proxy-CoAh --> | | | +------+ | | +------+ | | | MAGv | | | | MAGh | | | +------+ | | +------+ | +--------|-----------------+ +-------------------|------+ MN-HoA --> | | <-- MN-HoA +----+ Movement +----+ | MN | <------------------------------------ | MN | +----+ +----+ Figure 1: Inter-domain roaming scenario 3.2. Assumptions To support roaming between PMIPv6 domains, the proposed protocol makes the following assumptions: o Through a contact among PMIPv6 domains, LMAs and MAGs can request authentication about hosts of other domains as well as hosts of its domain, to AAA. o EAP and AAA protocols, RADIUS [RFC2865] or Diameter [RFC3588], can be used for user authentication and prefix allocation as defined in [RFC4818]. o A Network Access Identifier (NAI) of a MN, i.e. MN-ID, used for user authentication and prefix allocation might be a e-mail Na, et al. Expires January 12, 2009 [Page 7] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 address, etc. o Concatenated tunnels could be established to support inter-domain roaming. Na, et al. Expires January 12, 2009 [Page 8] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 4. Roaming Mechanism Operations 4.1. Control Plan Flow To support inter-domain roaming through the proposed mechanism, the signalings due to movement of a MN follows figure 2. The MN within a home domain requests authentication to the MAGh through its NAI. This authentication is initiated through L2 access. The MAGh requests authentication with regard to the MN' ID (foo@home) to AAAh. If the MN is authenticated as an authorized host, the AAAh delivers an LMAh address of the MN to the MAGh. The MAGh sends Proxy Binding Update (PBU) message with its address, Proxy-CoAh, and the MN address to the LMAh. The LMAh registers the MAGh address in regard to the MN and sends Proxy Binding Acknowledgement (PBA) message including a Home Network Prefix of the MN to the MAGh. If the MAGh receives the PBA message, it is established a bi-directional tunnel between the LMAh and MAGh, for data from or to the MN. The MAGh registers the home network prefix of the MN and sends Router Advertisement (RA) message including the home network prefix to the MN. The MN on receiving this RA message has a valid address (MN-HoA) through configuring its interface with its home network prefix. The MN sends and receives data through the tunnel using the MN-HoA. If the MN moves to the visit domain, it cannot communicate with the home domain. Then, the MN again requests an authentication to an MAGv through L2 access. The MAGv on receiving the authentication request of the MN requests authentication to an AAAv. Because the AAAv knows that the MN is a host of the home domain, it again requests authentication to the AAAh. The AAAh sends LMAh address to AAAv after the authentication in regard to the MN. The AAAv sends LMAv address in regard to the MN and LMAh address sent from the AAAh, to the MAGv. The MAGv sends a PBU message including its address, the MN' ID, and LMAh address, to the LMAv. The LMAv registers MAGv address in regard to the MN and sends a PBU message including its address and the MN' ID to the LMAh. The LMAh removes the previous tunnel in regard to the MN and re-establishes new tunnel in regard to the MN to LMAv. The LMAh also sends a PBA message including the home network prefix of the MN to the LMAv. The LMAv registers the received home network prefix and sends a PBA message including the prefix to the MAGv. So, to support inter-domain roaming of the MN, concatenated tunnels from LMAh to LMAv and from LMAv to MAGv is established by exchanging the PBU and PBA messages. The MAGv registers the home network prefix of the MN and sends RA messages to the MN. Therefore, the MN believes it is still on the home domain, and sends and receives continuously data. Na, et al. Expires January 12, 2009 [Page 9] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 (NAI:foo@home) Domain@visit Domain@home +----+ +------+ +------+ +------+ +------+ +------+ +------+ | MN | | MAGv | | LMAv | | AAAv | | MAGh | | LMAh | | AAAh | +----+ +------+ +------+ +------+ +------+ +------+ +------+ | | | | | | | L2 | | | | | | Attachment | | | | | | | User Auth. Req. | Access Req. | |------------------------------------------>|------------------>| |<------------------------------------------|<------------------| | User Auth. Res. Access Res.(LMAAh) | | | | | PBU | | | | | | |-------->| | | | | | |<--------| | | | | | | PBA(HNP)| | |<------------------------------------------|=Tunnel==| | | | RA(HNP) | | | | Address Auto-Configuration | Move to visit domain .... | L2 Attachment | User Auth. Req. Access Req. Access Req. |---------->|------------------>|------------------------------>| |<----------|<------------------|<------------------------------| User Auth. Res. Access Res. Access Res. | (LMAAv & LMAAh) (LMAAh as HA) | | | PBU | PBU | | | |-------->|------------------------------>| | | |<--------|<------------------------------| | | | PBA | PBA | | (Previously assigned HNP) (Previously assigned HNP) | |<----------|=Tunnel==|============Tunnel=============| | | RA | | | | | | | (Previously assigned HNP) | | | | | | | | | | | | Figure 2: Control Flow to establish concatenated tunnels Na, et al. Expires January 12, 2009 [Page 10] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 4.2. Data Plan Flow Figure 3 shows data flow between an NM and a CN. The data flow consists of a bi-directional tunnel between an MAGv and an LMAv and a bi-directional tunnel between the LMAv and an LMAh. When the CN sends data to the MN, it includes its address and the MN address HoA in IP header of data packet. The LMAh on receiving the packet from the CN sends the packet encapsulating its address and LMAv address to the LMAv. The LMAv decapsulates the packet and sends the packet encapsulating its address and the MAGv address to the MAGv. The MAGv decapsulates the packet to the original packet from the CN and sends the original packet to the MN. Na, et al. Expires January 12, 2009 [Page 11] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 +--------------------------+ +--------------------------+ | Domain@visit | | Domain@home | +----+ | +------+ +------+ | | +------+ +------+ | +----+ | MN | | | MAGv | | LMAv | | | | MAGh | | LMAh | | | CN | +----+ | +------+ +------+ | | +------+ +------+ | +----+ | | | | | | | | | | Home | | | | | | | | | Domain | | | | | | | | | | | [CN|MN-HoA][payload] | | | | | | |--------------------------------------->| | | | | | | | | | |====Tunnel=====| | | | | | | | [LMAAh|Proxy-CoAh][CN|MN-HoA] | | | | | | | |-------------->| | | | | | | | | | |[CN|MN-HoA] | | | | | | | |--------->| | | | | | | | |<---------| | | | | | | | |[MN-HoA|CN] | | | | | | |<--------------| | | | | | | | [Proxy-CoAh|LMAAh][MN-HoA|CN] | | | [MN-HoA|CN][payload] | | |===============| | | |<---------------------------------------| | | | | | | | | | | | | | Visit | | | | | | | | | Domain | | | | | | | | | | | | | | | | | | | [CN|MN-HoA]| | | | | | | | |--------->|====Tunnel=====| | | | | | | | [LMAAv|Proxy-CoAv][CN|MN-HoA] | | | | | | | |-------------->|============Tunnel===========| | | | | | | [LMAAh|LMAAv][CN|MN-HoA] | | | | | | |---------------------------->| | | | | | | | | | |[CN|MN-HoA] | | | | | | | |--------->| | | | | | | | |<---------| | | | | | | | |[MN-HoA|CN] | | | |<----------------------------| | | | | | | [LMAAv|LMAAh][MN-HoA|CN] | | | | | |<--------------|=============================| | | | [Proxy-CoAv|LMAAv][CN|MN-HoA] | | | | | | | |===============| | | | | | | [MN-HoA|CN]| | | | | | | | |<---------| | | | | | | | | | | | | | | | | | +--------------------------+ +--------------------------+ Figure 3: Data Flow via concatenated tunnels Na, et al. Expires January 12, 2009 [Page 12] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 5. IANA Considerations This document requests no action by IANA. Na, et al. Expires January 12, 2009 [Page 13] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 6. Security Considerations This document is based on the security requirements listed in [I-D.ietf-netlmm-proxymip6]. The inter domain roaming requires the signaling message, Proxy Binding Updates and Proxy Binding Acknowledgement, exchanged between the visited local mobility anchor and home local mobility anchor to be protected using IPsec, using the established security association between them such as between the MAG and the LMA in [I-D.ietf-netlmm-proxymip6]. Na, et al. Expires January 12, 2009 [Page 14] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 7. Acknowledgements None. Na, et al. Expires January 12, 2009 [Page 15] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. 8.2. Informative References [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007. [I-D.giaretta-netlmm-mip-interactions] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. [IEEE802.16e] "IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1", February 2006. [3GPP] "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution: Report on Technical Options Na, et al. Expires January 12, 2009 [Page 16] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 and Conclusions (Release 7)", March 2007. [WiMAX] "Network Working Group_World Interoperability for Microwave Access (WiMAX) Forum Network Architecture - Stage 2 Part 2 - Release 1.0.0", March 2007. Na, et al. Expires January 12, 2009 [Page 17] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 Authors' Addresses Jee-Hyeon Na ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 5408 Email: jhna@etri.re.kr Soochang Park Chungnam National University 220 Gung-dong, Yuseong-gu Daejeon, 305-764 Korea Phone: +82 42 821 7451 Email: winter@cclab.cnu.ac.kr Jung-Mo Moon ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 6748 Email: jmmoon@etri.re.kr Sangho Lee ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 6385 Email: leesh@etri.re.kr Na, et al. Expires January 12, 2009 [Page 18] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 Euisin Lee Chungnam National University 220 Gung-dong, Yuseong-gu Daejeon, 305-764 Korea Phone: +82 42 821 7451 Email: eslee@cclab.cnu.ac.kr Sang-Ha Kim Chungnam National University 220 Gung-dong, Yuseong-gu Daejeon, 305-764 Korea Phone: +82 42 821 6271 Email: shkim@cnu.ac.kr Na, et al. Expires January 12, 2009 [Page 19] Internet-Draft Roaming Mechanism between PMIPv6 Domains July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Na, et al. Expires January 12, 2009 [Page 20]