Network Working Group S. Daniel Park Internet-Draft P. Kim Expires: January 30, 2005 Samsung Electronics August 2004 DHCP Option for Configuring IPv6-over-IPv4 Tunnels draft-daniel-dhc-ipv6in4-opt-05.txt 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 30, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides a mechanism by which the DHCPv4 servers can provide information about the IPv6-over-IPv4 tunnel endpoint. The IPv4/IPv6 dual stack nodes can use this information to set up a tunnel to the tunnel endpoint to obtain IPv6 connectivity without requiring manual intervention at any of the tunnel endpoints at tunnel establishment time. Park & Kim Expires January 30, 2005 [Page 1] Internet-Draft DHCP Option for IPv6-over-IPv4 Tunnel August 2004 1. Introduction In the initial deployment of IPv6, the IPv6 nodes may need to communicate with the other IPv6 nodes via IPv4 tunnel service. The connectivity can be obtained by setting up an IPv6-over-IPv4 tunnel between a client and a tunnel router. This document defines a new option by which the DHCPv4 [RFC2131] server can notify the client with the list of endpoints of the possible IPv6-over-IPv4 tunnel defined in [RFC2893] in an automated manner. Through this mechanism, dual stack users attached to IPv4 only networks can connect its IPv6 connectivity to the endpoints as a tunnel router. Particularly, this mechanism is useful where the ISP is providing the IPv6 services but is doing it using tunneling over IPv4 to avoid upgrading all their infrastructure to support IPv6 on day one. Regarding IPv6-over-IPv4 tunnel, the tunnel broker [RFC3053] architecture has been widely deployed in the dual networks to obtain IPv6 connectivity via tunnel service because of easy configuration on the users. After configuring IPv6-over-IPv4 tunnel between the users and the selected tunnel server, tunnel broker allows user to get access to the 6bone or any other IPv6 network the tunnel server is connected to. In case of no tunnel broker, the proposed mechanism in this document can allow users to obtain the IPv6 connectivity efficiently. 1.1 Terminology The following terms pertaining to tunnel are used in this document as defined in [RFC2893] o IPv6-over-IPv4 Tunnel: The technique of encapsulating IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures. IPv6-over-IPv4 tunnel where the IPv4 tunnel endpoint address is determined by configuration information learned from the DHCP Server on the encapsulating node. o Tunnel endpoint address: Destination address of IPv4 encapsulating IPv6 packets. It is an IPv4 address in the TEP Option originated from the DHCP Server. Park & Kim Expires January 30, 2005 [Page 2] Internet-Draft DHCP Option for IPv6-over-IPv4 Tunnel August 2004 2. Requirements 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 [RFC2119]. 3. IPv6-over-IPv4 Tunnel End Point Option This option specifies the IPv6-over-IPv4 tunnel endpoint that client should use when discovering the IPv4 address of the ISP's tunnel router somehow via the Dynamic Host Configuration Protocol. Once the IPv4 address has been learned, it is configured as the tunnel endpoint for the IPv6-over-IPv4 tunnel. The format of the IPv6-over-IPv4 Tunnel End Point Option is shown as below; The code for this option is TBD. The length of this option is 4 (in case of single endpoint). Code Length TEP Order in Sequence 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_TEP | Len | TEP Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TEP Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the above diagram, TEP Addr is 32-bit integers corresponding to DHCP options which specify the IP address of a different IPv6-over-IPv4 tunnel endpoint. All IPv6 traffic generated on the dual node SHOULD be encapsulated within IPv4 and forwarded to the endpoint assigned into the TEP Addr field of TEP option. 4. DHCP Client Behavior The DHCP client will use this option to create a tunnel endpoint address for IPv6-over-IPv4 tunnel. The client may receive tunnel services in this option that it does not support or has not been Park & Kim Expires January 30, 2005 [Page 3] Internet-Draft DHCP Option for IPv6-over-IPv4 Tunnel August 2004 configured to access. Likewise, a client may receive an option that tunnel services for which no corresponding DHCP option was supplied. Clients will interpret this option in a system-specific manner whose specification is outside the scope of this document. As described in [RFC2893], the dual node received TEP option MUST store the tunnel endpoint address and this address is used as destination address for the encapsulating IPv4 header. Although the dual node obtains available tunnel endpoint address from the DHCP server, it can not receive any IPv6 packets from the tunnel router via IPv6-over-IPv4 tunnel because the tunnel router does not recognize which node is likely to configure its tunnel attached to the tunnel router. As described in [I-D.nielsen-v6ops-zeroconf-goals] the tunnel protocol proposed in this document MUST allow for one tunnel endpoint to verify the reachability of other tunnel endpoint towards which it intends to send packets. After verifying the reachability between them, IPv6 Router Advertisement messages including address configuration information are reached to the dual node correctly, and the dual node configures its unique IPv6 address by itself in a stateless address autoconfiguration manner [RFC2461]. The dual node thus is able to forward its IPv6 traffics to the tunnel router learned from the TEP option of DHCP. One example of the reachability function is shown in Section 10 while specific considerations is beyond scope of this document. The determination of which packets to tunnel is usually made by routing information on the encapsulator. This is usually done via a routing table, which directs packets based on their destination address using the prefix mask and match technique. For more information, refer to section 4. Configured Tunneling in [RFC2893]. Park & Kim Expires January 30, 2005 [Page 4] Internet-Draft DHCP Option for IPv6-over-IPv4 Tunnel August 2004 +---------------------------------------+ | IPv4 Network | | | | +------------+ | | | DHCP Server| | | +-----------+ +-----+------+ | | | Dual Stack| | | | | Node | | | | +------**---+ / +--------+ /------------\ | ||Tunnel Interface / | Tunnel | / \ | || | |Endpoint|------| IPv6 network | | |==================+========| | \ / | IPv6-over-IPv4 Tunnel +--------+ \------------/ | | | | | | | | +---------------------------------------+ Fig. 1, Simple network model for TEP option use case 5. Multiple Tunnel End Point Considerations For the simple IPv6-over-IPv4 tunnel, one tunnel endpoint is generally used and it assumes that all the networks will be reached through the same endpoint. In this case, one TEP Addr field in the TEP option is used for configured tunnel service. The list of endpoints can be installed as the default routes and the routes will be tried in a round robin fashion if the IPv6 host load-sharing is honored [I-D.ietf-ipv6-host-load-sharing]. Instead there can be specific default routes for the different destination. Generally, there may not be a need for installing multiple configured tunnel endpoints unless administrator wants two for redundancy purposes. It is out of scope of this document. 6. Security Considerations A rouge DHCP server can issue invalid or incorrect IPv6-over-IPv4 tunnel endpoint. This may cause denial of service due to unreachability or makes the client to reach incorrect destination. The latter has very severe security issues as the tunnel endpoint is on-the-path towards all the IPv6 destinations, and can trivially act as a man-in-the-middle attacker. Park & Kim Expires January 30, 2005 [Page 5] Internet-Draft DHCP Option for IPv6-over-IPv4 Tunnel August 2004 To increase secure exchange between users and tunnel endpoints, the tunnel broker or any tunnel agent can be used for configuring IPv6-over-IPv4 tunnels including authentication, security association and so on, but it is not scope of this document. The authenticated DHCP [RFC3118] can be also used for secure exchange between users and tunnel endpoints. 7. Extended Usage As stated in Introduction, the tunnel broker is a nice tool for allowing user to get the IPv6 connectivity through IPv6-over-IPv4 tunnel. To configure tunnel between users and tunnel servers, users have to access to the tunnel broker by web registration and then tunnel broker set up tunnel between users and a selected tunnel server. Prior to filling up the form on the tunnel broker, users have to know the IPv4 address of the tunnel broker (as described in [RFC3053], it may be IPv6 addressable but not mandatory). Regarding this operation, this option proposed in this document can allow users to obtain an available tunnel broker address (or addresses) without any manual operations. For this operation, a new option (called Tunnel Broker Configuration Option: option name is OPTION_TBCO and value is TBD) can be simply made by DHCPv4 option extension which may be the same format as TEP option. To increase secure exchange between users and tunnel endpoints (tunnel servers or dual routers) this extended usage can be applied for configuring IPv6-over-IPv4 tunnel instead of direct tunnel configuration between them. Specific method for secure exchange is beyond scope of this document. 8. IANA Considerations IANA is requested to an assign value for the IPv6-over-IPv4 Tunnel End Point option code in accordance with [RFC2939]. Option Name Value Described in OPTION_TEP TBD Section 3. OPTION_TBCO TBD Section 7. (if necessary) 9. Acknowledgements Special thanks to Pekka Savola, Vijayabhaskar A K, Eric Nordmark, Ralph Droms, Bernie Volz and Alain Durand for their many valuable Park & Kim Expires January 30, 2005 [Page 6] Internet-Draft DHCP Option for IPv6-over-IPv4 Tunnel August 2004 revisions and comments. In particular, Pekka Savola kindly clarified the multiple tunnel end point considerations with his good experience as well. Specially, authors would like to acknowledge the implementation contributions by Minho Lee of Samsung Electronics. 10. Impmenentation Experiences We have implemented TEP option using the Internet Systems Consortium DHCP source code (DHCP-3.0.1-rc13 version) on both DHCP server and client, particularly client is an IPv4/IPv6 dual stack based on Linux operating system. For the simple implementation, TCP/UDP port assigned both endpoints by operator in advance was used to verify the reachability in this document. 11. References 11.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. 11.2 Informative References [I-D.ietf-ipv6-host-load-sharing] Hinden, R., "IPv6 Host to Router Load Sharing", draft-ietf-ipv6-host-load-sharing-02 (work in progress), May 2004. [I-D.nielsen-v6ops-zeroconf-goals] Morelli, M., "Goals for Zero-Configuration Tunneling", draft-nielsen-v6ops-zeroconf-goals-01 (work in progress), September 2004. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Park & Kim Expires January 30, 2005 [Page 7] Internet-Draft DHCP Option for IPv6-over-IPv4 Tunnel August 2004 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RFC3053] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. Authors' Addresses Soohong Daniel Park Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon-si, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 4508 EMail: soohong.park@samsung.com Pyungsoo Kim Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon-si, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 4635 EMail: kimps@samsung.com Park & Kim Expires January 30, 2005 [Page 8] Internet-Draft DHCP Option for IPv6-over-IPv4 Tunnel August 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 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 (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. Park & Kim Expires January 30, 2005 [Page 9]