Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET Expires: May 1, 2004 Nov 2003 A Simple IPv6-in-IPv4 Configured Tunnel Set-Up Procedure draft-savola-v6ops-conftun-setup-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 May 1, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo describes a set of operational procedures and one implementation mechanism to provide a very simple and straightforward way to easily manage IPv6-over-IPv4 configured tunnels between an ISP and a customer. The configured tunnels work even if the IPv4 addresses change dynamically, or are private addresses; the procedure provides at least a /64 prefix per customer and requires no administrative set-up. Support for NAT Traversal is currently out of scope. Savola Expires May 1, 2004 [Page 1] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the Procedure . . . . . . . . . . . . . . . . . 3 4. Customer-side Procedures . . . . . . . . . . . . . . . . . . 4 4.1 Possible Prior Agreement with the ISP . . . . . . . . . . . 4 4.2 Learning and Configuring the Tunnel Endpoint . . . . . . . . 4 4.3 Tunnel Activation . . . . . . . . . . . . . . . . . . . . . 5 4.4 Providing Connectivity to Other Nodes . . . . . . . . . . . 5 5. ISP-side Procedures . . . . . . . . . . . . . . . . . . . . 5 5.1 Possible Prior Agreements with the Customers . . . . . . . . 6 5.2 Learning the Customers' Tunnel Endpoint Addresses . . . . . 6 5.3 Prefix Advertisement or Delegation . . . . . . . . . . . . . 7 5.4 Tunnel Activation and Maintenance . . . . . . . . . . . . . 7 5.5 Secure Operations for Tunnel Service . . . . . . . . . . . . 8 5.5.1 Sufficient Tunnel Service Provisioning . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . 9 Informative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 Savola Expires May 1, 2004 [Page 2] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 1. Introduction A need for a simple mechanism to set up IPv6-over-IPv4 configured tunnels between a customer and the ISP seems to have been demonstrated in 3GPP analysis [10] as well as Unmanaged [11] and ISP analysis [12]. Most currently proposed mechanisms (like 6to4 [7] or ISATAP [8]) appear to be unnecessarily complex or otherwise problematic in these particular scenarios. This memo documents a set of operational procedures which require no additional protocol specification to provide a very simple and suitably elegant solution to these problems. The second section gives a brief problem statement which also describes the applicability of the solution. The third section explains the overview of the procedure. The fourth and the fifth sections describe the customer- and ISP-side procedures in more detail. 2. Problem Statement There are ISPs which are willing to provide IPv6 connectivity to their customers, but may not be able to do it natively due to a number of reasons. Such ISPs want to find a method to help in providing IPv6-over-IPv4 tunnels to the customers. The IPv4 address of the customer may be either static or dynamic, and may be a private address [6] as well, but not NAT'ed between the path from the customer to the ISP. The ISP may want to offer the tunnel service either requiring prior agreement with the user, or to every customer who wishes to try it. The customer may have one or more nodes which should obtain IPv6 connectivity. The solution should be as simple as possible, requiring no new protocols or substantial modifications to IPv6 or IPv4 implementations either at the ISP or customer side. [XXX NOTE: a UDP encapsulation would be rather straightforward to add if necessary for NAT traversal, might cause a problem with an IPv6 prefix size though.] 3. Overview of the Procedure The procedure can be summarized as follows: 1. If the ISP requires prior agreement ("managed mode"), the customer contacts the ISP off-band and registers as an IPv6 user. 2. The customer discovers (using one of a number of mechanisms) the IPv4 tunnel end-point address of the ISP, and creates a configured, protocol-41 tunnel [1] to the address, and sends a Savola Expires May 1, 2004 [Page 3] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 normal Neighbor Discovery [2] (ND) Route Solicitation (RS) or a DHCPv6 [4] SOLICIT or prefix delegation request [5] message over the tunnel. 3. The ISP's tunnel router sets up a configured tunnel towards the customer's IPv4 address; the address may be obtained using a number of mechanisms, or created ad-hoc ("ad-hoc mode") when tunnel packets arrive. In the former case, the configured tunnel interface is typically pre-configured prior to receiving any packets from the customer. 4. The ISP's tunnel router sends a normal ND Route Advertisement (RA) or a further DHCPv6 message over the tunnel to the customer; the prefix advertised is obtained using one of a number of mechanisms. The customer automatically configures the prefix and the addresses and uses them normally. No new protocols are needed. Both in the managed and ad-hoc modes, the customer can learn the tunnel address off-band. In the managed mode, the ISP has to know the IPv4 address assigned to the customer, configure a new IPv6 tunnel interface for the customer, and reserve the IPv6 prefix that will be assigned; these have to be configured on the tunnel router using operator-specific management techniques. In the ad-hoc mode, on the other hand, the tunnel router has to implement a simple mechanism to allocate a new configured tunnel for tunnel packets received from different customers, and select an IPv6 prefix to be assigned to the customer. 4. Customer-side Procedures 4.1 Possible Prior Agreement with the ISP The ISP may require prior agreement or notification before a customer is allowed to use their tunnel service. In that case, the customer must contact the ISP using off-band mechanisms. Even if not required, special requirements (e.g., a static IPv6 prefix when IPv4 address is dynamic) may be easier to fulfill if the user has contacted the ISP beforehand and the ISP has made arrangements. 4.2 Learning and Configuring the Tunnel Endpoint To get started, the customer has to learn the IPv4 address of the ISP's tunnel router somehow. Possibilities include, for example: o Using off-band mechanisms, e.g., from the ISP's web page. Savola Expires May 1, 2004 [Page 4] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 o Using DNS to look up a service name by appending it to the DNS search path (e.g. "tunnel-service.example.com"). o Using a (yet unspecified) DHCPv4 option. o Using a pre-configured IPv4 anycast address, either in the private address space, or a public, non-routable address. o Using other, unspecified methods. This memo does not (at least yet) take a stance on the selection of the mechanism even though some are more problematic than others, but it is assumed that the first or the second option should be enough for everyone considering that the customer's own ISP is providing IPv6 service. Once the IPv4 address has been learned, it is configured as the tunnel end-point for the configured IPv6-over-IPv4 tunnel. Note that this configuration can even be done transparently to the user, with very little or no configuration. 4.3 Tunnel Activation Next, IPv6 is activated over the tunnel as normal; this could be done either by a Neighbor Discovery RS, DHCPv6 Solicitation message, DHCPv6 Prefix Delegation request message, or by simple manual configuration (note: manual configuration does not work in the "ad-hoc" operation, because there is no trigger to bring up the ISP's interface). The tunnel router responds to this query as normal by sending a Route Advertisement or continuing with DHCP message exchanges. 4.4 Providing Connectivity to Other Nodes If the customer has multiple nodes, they can each obtain their own tunnel in the same manner. However, this is unoptimal especially if such nodes have internal communications. Instead, the customer may want to set up one node to as a Neighbor Discovery proxy [9] for the /64 route advertisement received, or if a less specific prefix (e.g., a /48) is being used, as a router for the internal network(s). This does not need to be any more complicated than just setting up the tunnel on one node. 5. ISP-side Procedures Savola Expires May 1, 2004 [Page 5] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 5.1 Possible Prior Agreements with the Customers The ISP may operate in either or both "managed" and "ad-hoc" modes. In only the managed mode, a prior agreement with the customer is needed to allow the customer to use IPv6 using this procedure. In only the ad-hoc mode, no agreements with the customers are needed. In both modes, "basic service" can be offered in ad-hoc mode, but more advanced services (e.g., prefix delegation or a static prefix) are offered to those with a prior agreement. ISPs which operate in managed mode must configure (e.g., manually or using a script or configuration tool) the configured tunnels on the tunnel router; also, they may want to create a link between the stable customer identification and their IPv6 properties (e.g., a prefix) especially if the IPv4 address is dynamic, to maintain the stability of IPv6 properties even when the IPv4 address may change. 5.2 Learning the Customers' Tunnel Endpoint Addresses The ISP must somehow obtain the tunnel endpoint address to be configured for a configured tunnel. Every active customer has its own configured tunnel interface on the tunnel router. When operating in the managed mode, this could be done from e.g. DHCPv4 leases, RADIUS or Diameter databases, other databases or some other means. This information will be used to update the tunnel end-point address on the configured tunnel interface when changing or as appropriate; the updates can be done e.g. using management tools, scripting, etc. -- because a change of IPv4 address must be reflected without delay to the tunnel end-point address, this configuration update should be immediately triggered by changes in the used database or lease. When operating in the ad-hoc mode, the tunnel server should create a new configured tunnel interface for each IPv6-over-IPv4 tunnel with a different IPv4 source address. The ISP should be aware of a potential for a resource exhaustion if the number of customers rises too high, but actual DoS attacks are not possible if the ISP has secured its network as described in Section 5.5. Automatical creation of configured tunnel interfaces requires only rather trivial implementation [XXX: does this need elaboration?]. Performing "garbage collection" on such tunnels, e.g. in a Least-Recently-Used (LRU) manner may be called for if the number of tunnels rises too high. However, this should only be done after sufficiently long period has passed, as not to disturb the existing (but maybe dormant) IPv6 connections over the tunnels. Savola Expires May 1, 2004 [Page 6] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 5.3 Prefix Advertisement or Delegation Each customer should be provided with at least a /64 prefix; this is both practical (because /64 is required by Stateless Address Autoconfiguration [3]), and architecturally correct (providing the possibility to connect more than one node without a NAT). In the managed mode, the ISP may advertise a static or dynamic IPv6 /64 prefix using RAs, provide a prefix delegation, or something else (e.g., manual configuration if the IPv4 address is static). In the ad-hoc mode, the ISP must ensure that a sufficiently large pool of /64 prefixes are available. The prefixes can be allocated either in a sequential fashion and advertised in RA's, or automatically calculated, with some assumptions, from the used IPv4 addresses. For example, if the ISP uses IPv4 network 10.0.0.0/8 for its customers, it needs 24 bits to uniquely identify each customer -- this calls for assigning an IPv6 /40 prefix to be used for advertising /64's; in this example, a customer with address "10.1.2.3" might get advertised an IPv6 prefix "2001:db8:FF01:0203::/ 64", where "01:0203" corresponds to the client address and "2001:db8:FF::" the /40 allocated to the ad-hoc tunneling operations by the ISP. Mapping the most interesting bits (for the ISP) of an IPv4 address to the IPv6 prefix allows even large ISPs to easily give each user an algorithmically derived IPv6 prefix. 5.4 Tunnel Activation and Maintenance When the router receives e.g. ND RS, DHCPv6 SOLICIT or prefix delegation request from the configured tunnel, it responds normally, as on any other interface. (When in ad-hoc mode, setting up the tunnel from the received IPv6-over-IPv4 packet may take a while, but the processing continues when set up.) The ISP should avoid sending periodic messages (e.g., unsolicited route advertisements) to the tunnel, or decrease the interval used for sending them: if the customer disconnects for some time, and someone else gets the same address, it might be disturbing to the new, potentially non-IPv6 aware customer to receive "weird" protocol 41 packets meant to the previous customer. The similar effect occurs if someone in the Internet is trying to communicate with an IPv6 user, but the user has changed its address in the meantime, and packets may go to someone else, but this is no different to the situation with IPv4, except that the packets are not necessarily recognized. Savola Expires May 1, 2004 [Page 7] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 5.5 Secure Operations for Tunnel Service The ISP should perform IPv4 ingress filtering at its borders towards peers and upstreams, by disallowing packets with the source addresses belonging to its own site or its customers. In particular, the ISP must block the tunnel router's address from being used as a source address from the outside; blocking the use of the customer prefixes would be preferred as well. The ISP must perform IPv4 ingress filtering towards the customers, in particular those that use the tunnel service, so that they will not be able to forge the IPv4 source address of the packets. In particular, they must not be able to spoof the address of the tunnel router to the other customers. Both of these are very simple operations especially in the minimal case of blocking only the abuse of the tunnel router address. Naturally, the ISP should perform IPv6 ingress filtering as well, but that is orthogonal to the security of this procedure. In addition, the ISP must ensure, especially if in ad-hoc mode, that only a selected subset of source addresses is able to communicate with the tunnel router's designated tunnel address. For example, creating dynamic interfaces with packets from outside of the ISP's network could easily be used in a resource exhaustion attack. In addition, to curtail internal resource exhaustion attacks, it makes very much sense to ingress filter all the customers which are allowed to use the ad-hoc tunnel service. With these precautions, resources may only be exhausted by a real resource starvation, not through an attack; on the other hand, if the ISP does not bother to add such checks, it only harms itself for being susceptible to various forms of attacks! 5.5.1 Sufficient Tunnel Service Provisioning The ISP must naturally ensure that the tunnel router is capable to handle the amount of users and the traffic that goes through it. It should also be noted that all the traffic between the users of the ISP go through the same router; "shortcuts" routes are not deemed necessary. The increases in the latency are not significant as the tunnel router is deployed close to the IPv4 access router (or even co-located with it) topology-wise. Typically, these are not believed to be a problem. If the number of users or the amount of traffic generated increases, starting deploying native IPv6 access instead eliminates the problem. Savola Expires May 1, 2004 [Page 8] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 6. Acknowledgements This procedure was inspired by a need to severely simplify ISATAP [8]. Credit available for anyone inventing a good name + acronym for this procedure! :-) 7. Security Considerations The requirements for reasonably secure operations within an ISP are described in Section 5.5; with these in place, it is difficult to imagine a case where stronger mechanisms such as IPsec for IPv6-over-IPv4 tunnels would be needed. A particular case occurs when an IPv4 address of the user changes, and the user's IPv6 prefix changes as well; this may be allocated to a different IPv6 user. However, this is no different than IPv4 address re-use threats. [XXX: can be considered more if really needed.] When the ISP operates in the ad-hoc mode, and there is an event where all the IPv4 addresses change simultaneously, there may be a large number of simultaneous updates to update the tunnel point addresses in the tunnel router. This situation should be taken into consideration e.g. if renumbering. Normative References [1] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in progress), October 2003. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [5] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in progress), October 2003. Informative References Savola Expires May 1, 2004 [Page 9] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 [6] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [7] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [8] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-16 (work in progress), October 2003. [9] Thaler, D. and M. Talwar, "Bridge-like Neighbor Discovery Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy-01 (work in progress), October 2003. [10] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", draft-ietf-v6ops-3gpp-analysis-07 (work in progress), October 2003. [11] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged Networks", draft-ietf-v6ops-unmaneval-00 (work in progress), June 2003. [12] Ksinant, V., "Analysis of Transition Mechanisms for Introducing IPv6 into ISP Networks", draft-ksinant-v6ops-isp-analysis-00 (work in progress), October 2003. Author's Address Pekka Savola CSC/FUNET Espoo Finland EMail: psavola@funet.fi Savola Expires May 1, 2004 [Page 10] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Savola Expires May 1, 2004 [Page 11] Internet-Draft Configured Tunnel Set-Up Procedure Nov 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Savola Expires May 1, 2004 [Page 12]