One document matched: draft-ietf-ngtrans-hometun-00.txt

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

                 <draft-ietf-ngtrans-hometun-00.txt>

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]