Internet-Draft Syam Madanapalli July 7, 2004 S. Daniel Park Radhakrishnan S OLN Rao SAMSUNG Configured Tunnel End-Point Configuration using DHCPv4 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 6, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The intent of this draft is to provide a solution to automate tunnel end-point configuration for a configured IPv6-over-IPv4 tunnel. This uses a DHCPv4 option to percolate the tunnel end-point configuration information. This is very useful to connect a newly deployed native IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6 networks through IPv4. Syam, et al, Expires: January 6, 2005 [Page 1] Internet Draft CTEP Automate Conf. July 2004 1. Introduction In the initial deployment of IPv6, the IPv6 nodes may need to communicate with the other IPv6 nodes via IPv4 networks. Configured tunnels [5] provide a way to encapsulate the IPv6 packets in IPv4 packets and tunnel them in the IPv4 network. Configured Tunnel [4] is a simple transition mechanism which allows isolated IPv6 networks or hosts, attached to a legacy IPv4 network which has no native IPv6 connectivity, to communicate with other such IPv6 networks or hosts without manual configuration. To configure IPv6-over-IPv4 tunnel between isolated IPv6 networks, administrator typically configure available tunnels by hand. That is, imagine that we want to connect 10 sites together from our border router using full-mesh configured tunneling. We will have to set up 9 tunnels in each site, 9*10 tunnels in total. Thus we need a solution to automate the process of building configured tunnels at border routers connected through IPv4 backbone. This introduces new DHCPv4 options to distribute the configuration tunnel information automatically. Syam, et al, Expires: January 6, 2005 [Page 2] Internet Draft CTEP Automate Conf. July 2004 2. Common IPv6 deployment Scenarios Here is the diagram to explain the automation process in one of the typical transition scenario. ----------- / \ | CLOUD 1 | \ / -+-------+- | | | TS1 | | | +-------+ || T1|| || +-------+ | | | TS1 | | | -+-------+- / \ | CLOUD 2 | \ / ----------- Legend: TS1 - Dual-stack Tunnel server acting as a border router with DHCPv4 server. TS2 - Dual-stack Tunnel server acting as a border router with DHCPv4 client. Tn - Configured Tunnel CLOUD n - IPv6 clouds. In the above scenario if one or more IPv6 network wants to attach, the number of manual tunnel configurations needed is 4. In more general sense if there are "n" existing border routers and an "n+1"th border router is to be added, the number of manual tunnel configurations required is 2n. With this approach, each site's administrator has to be informed whenever a new IPv6 network wishes to get connected. The suggested approach in this document will automate the process of configuring the tunnels in all of the border routers. Syam, et al, Expires: January 6, 2005 [Page 3] Internet Draft CTEP Automate Conf. July 2004 3. Terminology This document uses terminology specific to IPv6 and DHCPv4 as defined in "Terminology" section of the DHCPv4 specification [1]. 4. Automated Configured Tunnel Establishment This section describes two options for configuring available tunnel end-points automatically among the border routers enabled DHCP functions. 4.1 Configured Tunnel End Point Reply Option - Option definition: The Configured Tunnel End Point Option gives the information to the clients about the Configured Tunnel End Point [5] to be contacted for reaching the nodes in the various IPv6 networks which are separated by IPv4 networks. The clients are expected to install these routes in their machines. The format of the Configured Tunnel End Point Option is as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OPTION_CTEP_REP| option-len | reserved | prefix-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination Prefix (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Configured TEP Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_CTEP_REP (TBD) option-len: Total length of the option. It MUST be set to 28. prefix-len: prefix length of the Destination Prefix. lifetime: The lifetime validity for this tunnel endpoint in Syam, et al, Expires: January 6, 2005 [Page 4] Internet Draft CTEP Automate Conf. July 2004 seconds. A value 0xFFFFFFFF means infinite lifetime. Destination Prefix: An unicast IPv6 Prefix. Configured TEP Address: IPv4 Address of the Configured TEP. This can be any valid unicast IPv4 address. The clients are expected to install/refresh the tunnel and associated routes identified by the tuple once they receive this option from the server, only if lifetime is non-zero. Lifetime zero means that the clients are expected to delete the routes identified by the tuple . - Appearance of this option: The Configured Tunnel End Point Reply Option MUST NOT appear in any message other than the DHCPREPLY message in correspond to the Configured Tunnel End Point Request Option with DHCPREQUEST message. This option MAY appear multiple times in DHCPREPLY message. Syam, et al, Expires: January 6, 2005 [Page 5] Internet Draft CTEP Automate Conf. July 2004 4.2 Configured Tunnel End Point Request Option - Option definition: The Configured Tunnel End Point Request Option is used by clients to request the DHCPv4 server for obtaining Configured Tunnel end point Information. The format of the Configured Tunnel End Point Request Option is as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OPTION_CTEP_REQ| option-len | reserved | prefix-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination Prefix (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Configured TEP Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_CTEP_REQ (TBD) Otherwise all value is same as CTEP Reply option. - Appearance of this option: The Configured Tunnel End Point Request Option MUST NOT appear in any message other than the DHCPREQUEST message. This option MUST appear only once in DHCPREQUEST message. Syam, et al, Expires: January 6, 2005 [Page 6] Internet Draft CTEP Automate Conf. July 2004 5. Applicable Scenarios This section simply describes what applicable scenarios are available in current network architecture. ----------- / \ | CLOUD 1 | \ / -+-------+- | | | TS1 | | | +-------+ +-------+ || | | T1|| | TS3 | || | | +-------+ -+-------+- | | / \ | TS2 | | CLOUD 3 | | | \ / -+-------+- ----------- / \ | CLOUD 2 | \ / ----------- 5.1 Sequence for attaching IPv6 cloud 3 - Assumptions: For configuring available tunnel information, TS3 should search for what TS performs this operation, thus TS sends a DHCPDISCOVER message including Parameter Request List option (Option codes is TBD). TSes not equipped to interpret this option sent by a TS3 MUST ignore it (although it may be reported). TSes can interpret this option send DHCPOFFER message with reserved CTEP information into the CTEP_REP option (or multiple options). There is no preference but TS3 can select one of the TS among them following the longest options as higher preference. - Sequence of operation: 1. TS3 sends a DHCPREQUEST message with CTEP Request option including its own IPv4 address and allocated IPv6 prefix to DHCPv4 server TS1. If TS1 does not support CTEP Request option since it is not used for tunnel end-point, it sends a DHCPNAK message. Syam, et al, Expires: January 6, 2005 [Page 7] Internet Draft CTEP Automate Conf. July 2004 2. TS1 sends a DHCPACK message with CTEP Reply option to TS3 including available configured tunnel end-points list. 3. TS1 establishes configured tunnel with the TS3 using the IPv6 and IPv4 addresses assigned into CTEP Request option from TS3. 4. TS3 establishes configured tunnel with the TS1 using the IPv6 and IPv4 addresses in CTEP Reply option received from TS1. 5. TS3 repeats the sequence in step 1 through 4 for all DHCP servers (TSs) which had sent DHCPOFFER message to TS3. However this step depends on administrator configuration whether or not to repeat. At the end of the above mentioned sequence the newly established tunnels are depicted in below figure. ----------- / \ | CLOUD 1 | \ / -+-------+- | | | TS1 | | | +-------+ +-------+ || ======T2======| | T1|| | TS3 | || ======T3======| | +-------+ -+-------+- | | / \ | TS2 | | CLOUD 3 | | | \ / -+-------+- ----------- / \ | CLOUD 2 | \ / ----------- Syam, et al, Expires: January 6, 2005 [Page 8] Internet Draft CTEP Automate Conf. July 2004 5.2 Advantages in this approach (a) Whenever a new border router belonging to an IPv6 cloud attaches itself to an existing IPv4 mesh network backbone, the manual effort required to establish configured tunnels between the existing border routers and the new one is drastically reduced. One typical example of such a mesh network is a company with IPv6 networks at geographically different branches/offices and connected to each other through IPv4 backbone (b) Unlike in other automatic tunnels (6to4) where IPv6 addresses are global, this approach imposes no such limitations on the use IPv6 addresses for the nodes in different IPv6 clouds. 6. Security Considerations The Configured Tunnel End Point Request/Reply Options may be used by an intruder DHCPv4 server to provide invalid or incorrect configured tunnel end point. This makes the client unable to reach its destination IPv6 node or to reach incorrect destination. The latter one has very severe security issues as IPv6 destination is spoofed here. To avoid attacks through this option, the DHCPv4 client SHOULD use authenticated DHCP (see Authentication of DHCPv4 messages specifications [7]). 7. IANA Considerations IANA is requested to assign an option code to the following options from the option-code space defined in Definition of New DHCPv4 options [3]. Option Name Value Described in OPTION_CTEP_REP TBD Section 4 OPTION_CTEP_REQ TBD Section 4 Syam, et al, Expires: January 6, 2005 [Page 9] Internet Draft CTEP Automate Conf. July 2004 References Normative References [1] R. Droms (ed.), "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] R. Droms,"Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", RFC 2939, September 2000. Informative References [4] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [5] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [6] A. Durand, P. Fasano, Guardini I., Lento D., "IPv6 Tunnel Broker", RFC 3053, January 2001. [7] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [8] S. Park, A.K. Vijayabhaskar, "Configured Tunnel End Point Option for DHCPv6", Internet Draft, March 2004 Syam, et al, Expires: January 6, 2005 [Page 10] Internet Draft CTEP Automate Conf. July 2004 Authors' Addresses Syam Madanapalli Network Systems Division Samsung India Software Operations Email:syam@samsung.com Soohong Daniel Park Mobile Platform Laboratory Samsung Electronics. E-Mail:soohong.park@samsung.com Radhakrishnan S. Network Systems Division Samsung ISO Email:rkrishnan.s@samsung.com O.L.N Rao Network Systems Division Samsung ISO Email:olnrao@samsung.com Syam, et al, Expires: January 6, 2005 [Page 11] Internet Draft CTEP Automate Conf. July 2004 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 IETF's procedures with respect to rights in IETF 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 (2004). 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. Syam, et al, Expires: January 6, 2005 [Page 12]