Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in October 2000 April 10. 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-00.txt [Page 1] INTERNET-DRAFT Tunnels for Internet access from home June 1999 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 transport mode at the IPv4 (ie. outer) level, 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-00.txt [Page 2] INTERNET-DRAFT Tunnels for Internet access from home June 1999 4. 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. 11. 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. 12. 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 (October 10, 2000) draft-ietf-ngtrans-hometun-00.txt [Page 3]