Internet Draft O.Menzel, D.Wagner, Expires: September 4, 2006 I. Miloucheva, SATCOM April 2006 Support of mobile receivers with unidirectional links in MIPv6 draft-menzel-udlr-mipv6-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 September 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses mechanisms for Mobile IPv6 allowing the efficient establishment of bidirectional link layer connectivity of mobile receivers moving to access networks with unidirectional links. Scenarios are derived from the need to support seamless mobile in heterogeneous networking environment including unidirectional downstream link interfaces, such as DVB-H, DVB-T, DVB-S or satellites. In order to establish quickly the upstream connectivity of a mobile receiver, when moving to downstream unidirectional network in MIPv6 environment, the Link-Layer Tunneling Mechanisms defined in RFC 3077 are used in interaction with Mobile IPv6 protocols. Menzel Expires September 4, 2006 [Page 1] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 For the mobile receivers with interfaces to unidirectional downstream links is required to have at least one additional interface, allowing to provide the upstream connectivity over Internet. The information for the upstream link, called also "feed" in the framework of RFC 3077, is included in the route advertisement message as an "unidirectional link tunneling" option. This option contains the IPv6 tunnel address for the upstream connectivity of a mobile node over the additional link. The integration of the "unidirectional link tunneling" option is also proposed for Fast Handovers and Candidate Access Router Discovery (CARD). Table of Contents 1. Overview.................................................. 2 2. Terminology used in this document......................... 3 3. Scenarios using mobile receivers with unidirectional links 4 4. Requirements of mobile nodes with unidirectional links.... 5 5. Integration of unidirectional link tunneling information in IPv6 mobility protocols................................ 9 6. Operational considerations................................ 10 6.1 Mobility support for Ipv6................................ 10 6.2 Fast Handovers for Ipv6.................................. 11 6.3 CARD protocol............................................ 12 7. IANA considerations......................................... 13 8. Further work................................................ 13 References..................................................... 13 Author's Addresses............................................. 15 1. Overview Mobile IPv6 does not attempt to solve all general problems related to mobile nodes, as for instance when they have interfaces atached to links with unidirectional connectivity [4]. For the integration of technologies based on unidirectional links (satellites, DVB-H, DVB-T [8]) into mobile IPv6 environment, there is a need to define facilities for dynamic management of the bidirectional connectivity of the mobile node, when the node changes the access point to and/or moves to unidirectional access network. The Link-Layer Tunneling Mechanisms (LLTM) and the Dynamic Tunneling Configuration Protocol (DTCP) described in RFC 3077 [1] are aimed to emulate bidirectional connectivity for unidirectional links in Internet. LLTM was primary defined and used based on scenarios mainly including IPv4 fixed multicast services over unidirectional links, such as satellites [13]. In the European project DAIDALOS [22], LLTM is used to support mobile Menzel Expires September 4, 2006 [Page 2] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 receivers based on DVB-technologies for IPv6 environment. This is based on integration of IPv6 services and protocols, such as PIM-SM routing [18], [19],and Multicast Listening Discovery (MLDv2) [17]), in mobile Internet environment considering the specifics of unidirectional links. In order to support efficently bidirectional connectivity of mobile nodes with unidirectional links in IPv6, this document proposes an OPTIONAL facility extending IPv6 mobility protocol [4] and its complementary protocols for Fast Handovers [15] and CARD [6] considering interoperation with LLTM [1]. The proposed facility allows dynamically bidirectional connectivity using LLTM and is RECOMMENDED for efficient support of IPv6 mobile nodes with unidirectional links during their movement from one access network to another. This document discusses the usage of LLTM for MIPv6 and defines the operational considerations for the integration of the option for unidirectional link handling in MIPv6, Fast Handovers and CARD. 2. Terminology used in this document 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 [9]. Abbreviations used in the following text: CoA Care-of Address pCoA previous Care-of Address pAR previous Access Router pAP previous Access Point nCoA next Care-of Address nAR next Access Router nAP next Access Point AR Access Router Mobility related terminology is defined in [10]. For nodes with unidirectional links, the terminology of [1] is used enhanced with definitions for mobile environment as follows: Access Router Feed Access Router attached to an unidirectional link with established tunnel end-points for bidirectional link (BDL) emulation. Access Router Feed information (FeedInfo) Information describing tunnel end-points established at the access router for bidirectional link emulation. Menzel Expires September 4, 2006 [Page 3] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 Unidirectional link (UDL) A layer 2 link with asymmetric reachability, defined in [23] as non-reflexive reachability link, which means packets from A reach B and packets from B do not reach A. Unidirectional Link Access Point (UdlAP) A layer 2 device connected to an IP subnet that offers unidirectional multicast/unicast connectivity. Unidirectional Link handling option (UdlOpt) An option, which contains list of feed information about unidirectional link access points. Multihomed Mobile Node A mobile node (either a host or a router) is multihomed when it has at least multiple CoAs. 3. Scenarios using mobile receivers connected to unidirectional links Unidirectional networks, based on satellites, DVB-T and DVB-H, could be part of different scenarios for media content distribution to multiple receivers and deploying of large scale multicast with saving of bandwidth and administration costs. In order to benefit from a better coverage area, costs and the characteristics of the satellite and broadcast technology, the unidirectional links are often used in heterogeneous wired and wireless environment. Such scenarios are typically based on asymmetric communication. An example is described in [11], in which multicasting of cache objects is performed on a high bandwidth downstream unidirectional satellite links, while the acknowledgments and requests from the receivers are transferred on an additional low bandwidth link over Internet. Satellites as unidirectional link could be efficiently used to deliver multicast traffic to a large number of listeners located in different geographic areas [16]. In this case, downstream shortcuts from multicast sources to multicast listeners are created, where upstream different wireless technologies could be used to provide connectivity over Internet to the sending source. In the heterogeneous mobile networking environment of Mobile IPv6 [4], the receivers with unidirectional downstream links are connected upstream using additional wireless access technologies. When the mobile receivers with unidirectional links move, there are different kinds of handover related to the unidirectional links, which should be seamlessly performed: Menzel Expires September 4, 2006 [Page 4] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 - handover to another unidirectional access link for downstream transfer, which requires establishment of new upstream tunnel over the additional wireless access network and release of already exiting tunnel; - handover to a wireless access network with release of already existing upstream tunnel; - handover to a new upstream tunnel over the additional wireless access network and establishment of new upstream channel and release of already exiting; Mobile IPv6 is designed to allow a mobile node to maintain its IPv6 communications while moving between IPv6 subnets. However, the current specification of Mobile IPv6 lacks support for mobile nodes with unidirictional links using additional wireless access network for upstream communication. In case of unidirectional links, different IP addresses (CoAs) should be assigned to the mobile node to the downstream (unidirectional) and upstream link allowing the bidirectional connectivity. For this purpose multihoming of the mobile node with unidirectional link in MIPv6 is required, which is currently under standardisation [7], [28], [29]. 4. Requirements of mobile nodes with unidirectional links Emulation of bidirectional connectivity for mobile nodes with unidirectional links is required to support mobile IPv6 services. Bidirectional connectivity is needed for address configuration in MIPv6 based on Neighbor discovery [23], dynamic stateless [24] and stateful [25] mechanisms. Multicast protocols, particularly used for integration of DVB-T in IPv6 mobile environment, such as PIM-SM [18], [19] and multicast listening based on MLDv2 [17], require bidirectional links for their protocol messages. For dynamically establishment of bidirectional connectivity based on unidirectional links, dynamic LLTM protocol [1] was proposed, which is adding a layer between the network interface and the routing software to emulate the full bidirectional connectivity using Internet tunnels. The focus of the UniDirectional Link Routing (UDLR) Working group was to integrate LLTM to support Internet routing and multicast services on UDLs such as satellites. Application of LLTM in different scenarios was studied. Experiments with IGMP protocol in Ipv4 environment using LLTM are reported in [14]. Configuration issues of the multicast routing protocol DVMRP for UDLs based on LLTM are addressed in [12]. Usage of LLTM to support Ipv4 multicast receivers connected over UDLs to IPv6 infrastructures is described in [13]. Menzel Expires September 4, 2006 [Page 5] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 This document extends the current state-of-the art of LLTM usage for mobile nodes with unidirectional links adapting the LLTM mechanisms to the mobile IPv6 requirements. The usage of LLTM in MIPv6 environment, when the mobile node moves, depends on the possibility of establishment of Internet based connections for the tunnels emulating the bidirectional links. Figure 1 describes a scenario based on mobile nodes with UDLs in IPv6 mobile environment using Access Routers acting as "feeds" and mobile nodes as "receivers" considering the LLTM terminology. +------+ +----------------------+ +--------+ +---->| pAR | --->| INTERNET | <--- | nAR |---+ | +------+ +----------------------+ +--------+ | | | | | | | | | | pAR_Feed v v nAR_Feed | | +-------------+ +-------------+ | | | pAR_BDL | | nAR_BDL | | | |-------------| |-------------| | | | pAR_UDL | | nAR_UDL | | | UDL_pAP--->+-------------+ +-------------+ <--UDL_nAP| | | | | | | | | | v MN MN v | | +-------------+ +--------------+ | | |pCoA_UDL | handover|nCoA_UDL | | | | ----------- | ------> |--------------| | +<----------|pCoA_BDL | |nCoA_BDL |--------->+ +-------------+ +--------------+ Figure 1: UDL topology based on "receiver" mobile nodes and feed AR An example for a mobile node with "receive only" capable unidirectional link in MIPv6 is the mobile terminal with DVB-T reception antenna supporting Digital Video Broadcasting. In this scenario, mobile nodes with "receive-only" capable UDLs are considered, which MUST be in addition equipped with other wireless links providing bidirectional connectivity such as UMTS, WLAN (IEEE 802.11x), or IEEE 802.16-2004 promoted by the WiMAX Forum. The equipment of the mobile node with additional bidirectional wireless links is required for emulation of bidirectional connectivity using LLTM. Before the handover, the mobile node was attached to an access point with unidirectional link (UDL_pAP) using the previous AR acting as Feed (pAR_Feed). After the handover, the mobile node moves its attachment to the next access point (UDL_nAP) using the nAR acting as Feed (nAR_Feed). Menzel Expires September 4, 2006 [Page 6] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 During the movement, it is a need to establish the bidirectional connectivity to the next AR Feed (nAR_Feed) using the additional bidirectional wireless link of the mobile node. The handover due to a new access point for the UDL is independent on the handover to a nAR connected to the bidirectional wireless links. The usage of LLTM requires a guarantee that the mobile node is connected over the additional bidirectional wireless link to the Internet and there is a route available to the AR Feed connecting the node with UDL. The routing and management requirements for the additional BDL interface are not focus of this document. The particular goal of this document is to define mechanisms in Mobile IPv6, which allow to provide efficient handover based on learning of the next Care-of address for the UDL interface together with the feed information to provide BDL connectivity. Currently in the mobile IPv6 [4], the configuration of a new Care-of address for the mobile node is defined based on the Neighbor Discovery [23], stateless [24] and stateful [25] configuration, but the particular issues of configuration of care-of addresses for mobile nodes with UDL is still not considered. It requires not only to obtain information for the next Care-of Address of the UDL interface, but also to get simultaneously the feed endpoints established at the next AR for emulation of bidirectional connectivity. Further requirements are to support the same tunneling protocol and link layer addressing schemes at the mobile node and access router feed. For this purpose the Generic Routing Encapsulation (GRE) [2] with Ipv6 as delivery protocol could be used. Interoperable link layer addressing for the BDL emulation should be also guaranteed. As it is shown in figure 2, the LLTM packet using GRE for encapsulation and IPv6 as delivery protocol has the following format: +-------------------------------------------+ | Delivery Header (IPv6 header) | | dest address = feed_IP_addr | | next header = 47 (GRE) | +-------------------------------------------+ | GRE Header ( | | prototype=ETHER_TYPE(emulated link layer) | | . . . . . . ) | +-------------------------------------------| | MAC header of emulated link layer | | IPv6 Encapsulated packet | +-------------------------------------------+ Figure 2: Packet encapsulation using Ipv6 and GRE Menzel Expires September 4, 2006 [Page 7] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 The destination address of the Ipv6 header is the feed tunnel end point at the AR. The "next header" field of the IPv6 header is 47, pointing on the IP protocol number of the GRE protocol described by the following header [0]. The prototype field of GRE header shows the type of the emulated BDL [21], which SHOULD be supported by the mobile nodes and feed ARs. In mobile environment, there are always requirements to reduce the overhead of the mobile nodes. Therefore, the sending intervals of the "HELLO" messages for announcing tunnel end-points as defined in Dynamic Tunneling Configuration Protocol (DTCP) should be adapted for the mobile environment. In order to establish bidirectional connectivity network between the "feed" and "receivers", there is a need to advertise the "feed" information of the new access router (currently sent by "HELLO" message) during the handover processing using IPv6 Mobility protocols. This should accelerate the services concerning dynamic address configuration of mobile nodes with UDLs during the handover. In particular, this document proposes to learn the AR feeds more quickly based on extensions of mobile IPv6 packets with a new option for handling of UDLs, which contains information derived from the "HELLO" message. The cause is that based on the "HELLO" messages the learning of the "feeds" of the mobile node with unidirectional links during the handover is delayed after its attachment on the new links and that is an unacceptable delay for the configuration of mobile node's Care-of address in IPv6. In summary, the requirements for handling of mobile nodes with UDLs using LLTM in MIPv6 are: - Support of mobile nodes with unidirectional links during handover for quickly care-of address configuration based on feed information provided by the access routers. - Adapting DTCP parameter for mobile environment based on reducing the overhead to the mobile nodes. - Supporting of interoperable tunneling protocol type (GRE with IPv6 as delivery protocol is recommended) and link layer addressing scheme for bidirectional link emulation. - Management of mobile access router connectivity in order to guarantee the connections using the additional bidirectional wireless links to the feed ARs. Further requirements for unidirectional link handling could arise considering specific scenarios, as for instance multicast feedback implosion problem, but they are out of scope. Menzel Expires September 4, 2006 [Page 8] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 5. Integration of unidirectional link tunneling information in IPv6 mobility protocols This document proposes the Unidirectional Link tunneling information, which is RECOMMENDED to enhance the Mobile IPv6 messages defined in MIPv6 [4], Fast Handovers [15] and CARD protocol [6] in order to establish dynamically the bidirectional connectivity of a mobile node with interfaces to unidirectional links. This option is used to get the IPv6 address for the "feeds" of the a access router providing the upstream connectivity of the mobile node with the unidirectional link. There are different alternatives to include the option in IPv6 Mobility protocols: - Router Advertisement Message used in Mobile IPv6 [4] - Proxy Router Advertisement Message defined in Fast Handovers for MIPv6 [15] - Reply message of the CARD [6]. The Unidirectional Link Handling option is described by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | | | | | | | PrRtAdv (UdlOpt)| | | <----------------| | | | | |* tunnel establ. [1] | | |* nCoA config. [24],[25] | | Figure 4: Unidirectional link handling in Fast Handovers MIPv6 6.3 UDL handling with CARD protocol The Candidate Access Router Discovery (CARD) protocol was designed to support the acquisition of information about the possible next ARs that are candidates for the mobile node's handover [6]. This document proposes to use CARD to report UDL feed information, when selecting a next router with UDLs. Menzel Expires September 4, 2006 [Page 12] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 CARD protocol is used in EU project DAIDALOS [22] together with the Context Transfer protocol [5] and IPv6 Fast Handovers [15] for efficient handover aimed at optimization of service re-establishment in case of MIPv6 node handover. The UDL handling option is included as sub-option in the CARD Reply Signalling message exchanged between access routers and mobile nodes, in order to provide the feedback information to the mobile node, arriving at the access network with unidirectional link. The signalling messages using CARD protocol for reporting of unidirectional link informations are shown in figure 5: Mobile Node Prev-AR Next-AR | | | | |AR-AR CARD Request | | |------------------> | | | | | | AR-AR CARD Reply(UdlOpt)| | | <---------------------- | |MN-AR CARD Request | | |------------------ > | | | | | | MN-AR CARD Reply(UdlOpt)| | | <------------------------| | |*selection of optimal CAR | | |*tunnel establ. | | |*nCoA config. | | Figure 6: Unidirectional link handling based on CARD 7. IANA considerations IANA should record a value for Unidirectional Link Handling Option (Mobile IPv6 Option). 8. Further work The integration of unidirectional link handling in mobile IPv6 is important for efficient handover using technologies based on DVB-T and satellites to connect mobile users. Facilities for handling of unidirectional links in IPv6 based on LLTM [1] with extensions for IPv6 mobility are proposed. LLTM with GRE support [2] is implemented in DAIDALOS EU project for mobile Ipv6 heterogeneous networking environment in interaction with Mobile IPv6, Fast Handovers IPv6 and CARD Protocol. Menzel Expires September 4, 2006 [Page 13] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 The scenarios for LLTM usage in DAIDALOS are based on DVB-T with access routers acting as feeds and mobile nodes as receivers. Other issues such as security and routing implications in case of unidirectional links are topic of further work. References [1] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional Links', RFC 3077, March 2001 [2] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina, "Generic Routing Encapsulation", RFC 2784 March 2000. [3] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", RFC 2780, March 2000. [4] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6, RFC 3775, 2004 [5] J. Loughney, M. Nakhjiri, C. Perkins, R. Koodli, Context Transfer Protocol, RFC 4067, 2005 [6] M. Liebsch, A. Singh, H. Chaskar, D. Funato, E. Shim, Candidate Access Router Discovery, RFC 4066, 2005 [7] Ng, C., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-05 (work in progress), February 2006. [8] ETSI: "Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television (DVB-T)", European Standard EN 300 744 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [10] J. Manner, M. Kojo, Ed., "Mobility Related Terminology", Network Working Group, Request for Comments: 3753, Category: Informational, March2004 [11] P. Basu, and K. Kanchanasut. "A Multicast Push Caching System over a UDLR Satellite Link", in SAINT 2003 Satellite Internet Workshop, IEEE Computer Society, Orlando, January 2003 Menzel Expires September 4, 2006 [Page 14] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 [12] C. Benassy-Foch, P. Charron, Y. Guinamand, Configuration of DVMRP over a unidirectional link, UDLR Working Group, IETF Draft, June2002, Work in Progress [13] E. Duros et al., Experiments with RFC 3077, Internet-Draft, , October 2002, Work in Progress [14] J.Takei, H.Izumiyama, Identifying Multicast Implications in a Link-Layer Tunneling Mechanism for Unidirectional Links, Internet-Draft, Network Working Group, February 2002, , Work in Progress [15] R. Koodli (ed.), Fast Handovers for Mobile Ipv6, draft-ietf-mipshop-fast-mipv6-02.txt, November 2004, Internet Draft, Work in Progress [16] A.H. Thamrin, H. Izumiyama, H. Kusumoto, PIM-SM Configuartion and Scalability on Satellite Unidirectional Links, Proceedings of the 2003 Symposium on Applications and the Internet Workshops (SAINT'03 Workshops), January, 2003 [17] R. Vida, and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, March2004. [18] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, Network Working Group, Experimental, June, 1998 [19] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas. "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised)," draft-ietf-pim-sm-v2-new-10.txt, July 2004, Work in Progress [20] IP Protocol Numbers, last updated 18 October 2004, http://www.iana.org/assignments/protocol-numbers [21] Ether Types, last updated 23 February 2006, http://www.iana.org/assignments/ether-numbers [22] Designing Advanced Interfaces for the Delivery and Administration of Location independent Optimised personal Services, EU IST project, www.ist-daidalos.org [23] T. Narten, E. Nordmark, W. Simpson, Neighbor Discovery for IP Version 6 (IPv6),RFC 2461, 1998 [24] S. Thomson, T. Narten, IPv6 Stateless Address Autoconfiguration, Request for Comments: 2462, 1998 [25] R.Droms, J.Bound, B.Volz, T. Lemon, C.Perkins, and M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003 [26] N. Montavont, R. Wakikawa, T. Ernst, C. Ng, K. Kuladinithi, Analysis of Multihoming in Mobile IPv6, IETF MONAMI6 Working Group, Internet-Draft, draft-ietf-monami6-mipv6-analysis-00.txt (work in progress), February 20, 2006 [27] Ernst, T., "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivations-scenarios-00 (work in progress), February 2006 Author's Addresses Olaf Menzel Phone: +49-2241-14-3494 Email: olaf.menzel@fokus.fraunhofer.de David Wagner Phone: +49-2241-14-3491 Email: david.wagner@fokus.fraunhofer.de Ilka Miloucheva Phone: +49-2241-14-3471 Email: ilka.miloucheva@fokus.fraunhofer.de FOKUS - Fraunhofer Institute for Open Communication Systems CC.SatCom,Schloss Birlinghoven 53757 Sankt Augustin, Germany 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. Menzel Expires September 4, 2006 [Page 15] INTERNET-DRAFT Mobile nodes with UDLs in Ipv6 April 2006 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. Menzel Expires September 4, 2006 [Page 16]