Softwire Working group S. Yamamoto Internet-Draft C. Williams Intended status: Informational H. Yokota Expires: August 30, 2007 KDDI R&D Labs February 26, 2007 Tunnel Endpoint Discovery Problem Statement draft-yamamoto-tun-dis-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Tunnel Endpoint Discovery is an enhancement to the Softwire feature. Defining a dynamic tunnel endpoint map allows you to be able to dynamically determine a Tunnel Broker peer; however, only the receiving client has this ability. This document frets out the problem scope as well as the motivation for specifying such a feature within the Softwire protocol. Yamamoto, et al. Expires August 30, 2007 [Page 1] Internet-Draft Tunnel End Discovery Prob Statement February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Redundancy and Bootstrapping . . . . . . . . . . . . . . . . . 3 4. Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security considerations . . . . . . . . . . . . . . . . . . . . 4 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative references . . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 6 Yamamoto, et al. Expires August 30, 2007 [Page 2] Internet-Draft Tunnel End Discovery Prob Statement February 2007 1. Introduction Devices running the Softwire protocol need to know where to find the IPv6 Tunnel End Point (TEP) in the case that IPv6 encapsulation method is used. In this case the TEP provides the IPv6 connectivity, just in case native IPv6 connection is not available. Users want plug-and-play devices and services and that most of them do not have any knowledge about how the Softwire protocol works or where the nearest TEP is located. It is required to consider the auto- discovery of the TEP. The Softwire protocol deals with the tunnel setup handshake and is not part of this auto-discovery feature. 2. Terminology Softwire (SW) - A "tunnel" that is created on the basis of a control protocol setup between softwire endpoints with shared point-to-point or multipoint-to-point state. Softwires are generally dynamic in nature (they may be initiated and terminated on demand), but may be very long-lived. Softwire Concentrator (SC) - The node terminating the softwire in the service provider network. Softwire Initiator (SI) - The node initiating the softwire within the customer network. 3. Redundancy and Bootstrapping This feature to Softwire protocol is required for a new machine on the network bootstraps itself by obtaining its first policy, and secure route discovery in the face of complex topologies and multiple secure paths for load-balancing and/or redundancy. In order to deploy a Softwire solution to an existing operators customer base, load-balancing and redundancy is required. Tens of thousand if not millions of end devices may require the Softwire service. This would mean that hundreds of Softwire network devices within the operators network would be needed. Load-balancing and redundancy within these Softwire devices (i.e., Softwire Concentrators) requires an auto- discovery feature to Softwire that is transparent to the end user. An example of a scenario is a common cause of service outages are powering problems with the active network elements (such as a utility power outage, a power supply failure, or simply a blown fuse). By protecting against these failures within the Softwire service, operators can ensure overall network reliability in all but a handful of instances. Yamamoto, et al. Expires August 30, 2007 [Page 3] Internet-Draft Tunnel End Discovery Prob Statement February 2007 4. Roaming Nomadic roaming is different from seamless roaming. Nomadic roaming is best described as the use of an 802.11-enabled laptop in an office environment. As an example, suppose a user of this laptop has network connectivity while seated at his desk and maintains connectivity to a single AP. When the user decides to roam, he undocks his laptop and walks over to a conference room. Once in the conference room, he resumes his work. In the back-ground, the 802.11 client has roamed from the AP near the user's desk to an AP near the conference room. This type of roaming is deemed nomadic because the user is not using network services when he roams, but only when he reach his destination. It is critical with Nomadic roaming that an auto-discovery feature be deployed for end hosts or routers using the Softwire service. In order to maximize the value of WiMAX or WiFi technology connectivity for nomadic users roaming must be transparent to them. This has been largely achieved by cellular providers and the same can be done between all forms of wireless broadband access. Softwire deployment must take into account this existing transparency and an auto- discovery solution for enabling network operators and service providers to bring Softwire subscribers and varying underlying network types together, both from a technology and business perspective, but the Softwire protocol as a whole must also work toward resolving challenges that could stand in the way of end-user adoption. 5. Security considerations The auto-discovery protocol feature to Softwire must prevent a malicious node from interjecting his own IP related information such that service goes through the bad node. Please see the Softwire Security Analysis document for more details on various security threats overall. 6. Conclusion The draft [1] is a memo that analyses the different approaches for configuring the IPv6 tunnel endpoint on a node. This document only servers to provide the problem scope and motivation. 7. References Yamamoto, et al. Expires August 30, 2007 [Page 4] Internet-Draft Tunnel End Discovery Prob Statement February 2007 7.1. Normative references 7.2. Informative References [1] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work In Progress draft-palet-v6ops-tun-auto-disc-01.txt , June 2004. Authors' Addresses Shu Yamamoto KDDI R&D Labs 2-1-15 Fujimino-shi Saitama 356-8502 Japan Phone: 81 (49) 278-7311 Email: shu@kddilabs.jp Carl Williams KDDI R&D Labs Palo Alto, CA 94301 USA Phone: +1.650.279.5903 Email: carlw@mcsr-labs.org Hidetoshi Yokota KDDI R&D Labs 2-1-15 Fujimino-shi Saitama 356-8502 Japan Phone: 81 (49) 278-7311 Email: yokota@kddilabs.jp Yamamoto, et al. Expires August 30, 2007 [Page 5] Internet-Draft Tunnel End Discovery Prob Statement February 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). Yamamoto, et al. Expires August 30, 2007 [Page 6]