Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in May 2001 November 18. 2000 IPv6 over IPv4 tunnels for home to Internet access Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited. Abstract Many Internet access providers for residential customers provide only one dynamic IPv4 address to their clients. This document proposes in such cases to use an IPv6 over IPv4 tunnel with IPsec (this gives a static global routable address or prefix with security) and to implement the processing at the server end of unsolicited neighbor advertisements for overriding the IPv4 address at the client end when it changes. 1. Introduction With cable modem or ADSL technologies, more and more users get their Internet access through an Internet service provider that provides only one dynamic IPv4 address per client: - even a small set of addresses is very expensive or unavailable - periodically (every 24 hours for instance) the underlying connection is reset and the IP address is changed. A common way to solve this problem is to use a network address translator but it does not give a complete and long term solution, for instance users cannot easily run servers and are not first class Internet citizens. draft-ietf-ngtrans-hometun-01.txt [Page 1] INTERNET-DRAFT Tunnels for Internet access from home November 2000 This document describes a secure method to allocate a cheap and large address space for home networks. The assigned addresses are permanent and globally routable. The proposed solution deals with the IPv4 address changes at the customer side. 2. Neighbor Discovery The end of a configured bidirectional IPv6 over IPv4 tunnel [1] is an interface but supports only a subset of the neighbor discovery protocol [2] functions. The underlying link-layer of an IPv6 over IPv4 tunnel is IPv4, ie. source and destination link-layer address options in neighbor discovery messages carry the IPv4 addresses of the tunnel end points: the IPv4 cloud (the Internet) is considered as a link. This document proposes to send from the client to the server unsolicited neighbor advertisements [2, section 7.2.6] with the override flag set when the IPv4 address of the client changes. Upon the reception of these messages, the server will update the client IPv4 address in the tunnel configuration, IPv6 addresses of the tunnel end points will not be affected. Note that this method cannot be used when the IPv4 addresses at both end points change, this document assumes the server side has a static IPv4 address. 3. IPsec These neighbor advertisements must be protected against replay, be authenticated and optionally be encrypted. IPsec [3] fulfills these requirements, the best solution is to use ESP [4] in the tunnel mode with mixed IP versions, ie.: IPv4 header ESP header IPv6 packet +---------------+------------------+-------------- - - ----+ | | | | +---------------+------------------+-------------- - - ----+ protocol = 50 next header = 41 with replay protection, authentication and optionally confidentiality services selected. The needed security association can be established by a dialup tool (AAA service like RADIUS [5] or DIAMETER [6]), an extension to the tunnel broker [7] service, link-shared secrets for ND [8] (with replay prevention because tunnels are point-to-point), IKE [9], ... In order to survive to long periods without any traffic the lifetime of involved security associations should be expressed as a byte or packet counts, not as a time. draft-ietf-ngtrans-hometun-01.txt [Page 2] INTERNET-DRAFT Tunnels for Internet access from home November 2000 4. IPsec Revisited The previous draft recommended the transport mode over a tunnel interface but this can be very different from a real tunnel mode, for instance the inbound processing check for the source address is done in tunnel mode on the inner (IPv6 here) address according to [3] 5.1.2.1 note 3 and 5.2.1 step 2. An implementation for FreeBSD 4.1 revealed many practical problems with IPsec implementations: - mixed IP versions in tunnel mode is in [3] (5.1.2.1 note 5 for instance) but is not commonly implemented. - some implementations spuriously check the outer source address in tunnel mode. - when transport mode is used because mixed version tunnel mode is not available or does not provide some later points then many implementations bark if the source IPv4 address changes. - the tunnel interface lookup should use the Security Association, on some implementations the tunnel interface code and the IPsec code do not colaborate. - tunnels should be interfaces, not only policies. For instance a tunnel must have link-local addresses for neighbor discovery and routing protocols. - Security Association and Policy Database updates should be allowed. Today, many IPsec implementors do not understand the benefits to have tunnels as virtual interfaces for IPv6 then a standard tunnel interface and transport mode should be used. This near always raises the changing source address issue which cannot be solved if some strict ingress filtering [10] is done (then the old address is no more available). 5. Security Considerations Not authentic or replayed unsolicited neighbor advertisements must be dropped. Most of the services listed in the previous section can provide suitable shared secrets for IKE negotiation. draft-ietf-ngtrans-hometun-01.txt [Page 3] INTERNET-DRAFT Tunnels for Internet access from home November 2000 6. Changes from Previous Version of the Draft This appendix briefly lists some of the major changes in this draft relative to the previous version of this same draft, draft-ietf-ngtrans-hometun-00.txt: - Added Section 4 (IPsec Revisited) from implementation experience. 7. References [1] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [2] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6", RFC 2461, December 1998. [3] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [4] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [5] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [6] P. Calhoun, G. Zorn, P. Pan, "DIAMETER Framework Document", draft-calhoun-diameter-framework-06.txt, work in progress, March 2000. [7] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 Tunnel Broker", draft-ietf-ngtrans-broker-02.txt, work in progress, October 1999. [8] D. McDonald, "Link-shared secrets for ND", 47th IETF meeting, Adelaide, Australia, March 2000. [9] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [10] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827 and BCP 38, May 2000. draft-ietf-ngtrans-hometun-01.txt [Page 4] INTERNET-DRAFT Tunnels for Internet access from home November 2000 8. Author's Address Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie BP 78 35512 Cesson-Sevigne Cedex FRANCE Fax: +33 2 99 12 70 30 EMail: Francis.Dupont@enst-bretagne.fr Expire in 6 months (May 18, 2001) draft-ietf-ngtrans-hometun-01.txt [Page 5]