[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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

                 <draft-ietf-ngtrans-hometun-01.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-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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/