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]
