idnits 2.17.1 draft-ietf-ngtrans-hometun-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1933 (ref. '1') (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2401 (ref. '3') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '4') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2138 (ref. '5') (Obsoleted by RFC 2865) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-06 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-05) exists of draft-ietf-ngtrans-broker-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ngtrans-broker (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2409 (ref. '9') (Obsoleted by RFC 4306) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Francis Dupont 2 INTERNET DRAFT ENST Bretagne 3 Expires in May 2001 November 18. 2000 5 IPv6 over IPv4 tunnels for home to Internet access 7 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Abstract 35 Many Internet access providers for residential customers provide 36 only one dynamic IPv4 address to their clients. This document 37 proposes in such cases to use an IPv6 over IPv4 tunnel with IPsec 38 (this gives a static global routable address or prefix with security) 39 and to implement the processing at the server end of unsolicited 40 neighbor advertisements for overriding the IPv4 address at the 41 client end when it changes. 43 1. Introduction 45 With cable modem or ADSL technologies, more and more users get 46 their Internet access through an Internet service provider that 47 provides only one dynamic IPv4 address per client: 48 - even a small set of addresses is very expensive or unavailable 49 - periodically (every 24 hours for instance) the underlying 50 connection is reset and the IP address is changed. 51 A common way to solve this problem is to use a network address 52 translator but it does not give a complete and long term solution, 53 for instance users cannot easily run servers and are not first 54 class Internet citizens. 56 This document describes a secure method to allocate a cheap and 57 large address space for home networks. The assigned addresses are 58 permanent and globally routable. The proposed solution deals with 59 the IPv4 address changes at the customer side. 61 2. Neighbor Discovery 63 The end of a configured bidirectional IPv6 over IPv4 tunnel [1] 64 is an interface but supports only a subset of the neighbor 65 discovery protocol [2] functions. The underlying link-layer of 66 an IPv6 over IPv4 tunnel is IPv4, ie. source and destination 67 link-layer address options in neighbor discovery messages carry 68 the IPv4 addresses of the tunnel end points: the IPv4 cloud (the 69 Internet) is considered as a link. 71 This document proposes to send from the client to the server 72 unsolicited neighbor advertisements [2, section 7.2.6] with 73 the override flag set when the IPv4 address of the client changes. 74 Upon the reception of these messages, the server will update 75 the client IPv4 address in the tunnel configuration, IPv6 76 addresses of the tunnel end points will not be affected. 78 Note that this method cannot be used when the IPv4 addresses 79 at both end points change, this document assumes the server side 80 has a static IPv4 address. 82 3. IPsec 84 These neighbor advertisements must be protected against replay, 85 be authenticated and optionally be encrypted. IPsec [3] fulfills 86 these requirements, the best solution is to use ESP [4] in the 87 tunnel mode with mixed IP versions, ie.: 89 IPv4 header ESP header IPv6 packet 90 +---------------+------------------+-------------- - - ----+ 91 | | | | 92 +---------------+------------------+-------------- - - ----+ 93 protocol = 50 94 next header = 41 96 with replay protection, authentication and optionally 97 confidentiality services selected. 99 The needed security association can be established by a dialup tool 100 (AAA service like RADIUS [5] or DIAMETER [6]), an extension to the 101 tunnel broker [7] service, link-shared secrets for ND [8] (with 102 replay prevention because tunnels are point-to-point), IKE [9], ... 103 In order to survive to long periods without any traffic the 104 lifetime of involved security associations should be expressed as 105 a byte or packet counts, not as a time. 107 4. IPsec Revisited 109 The previous draft recommended the transport mode over a tunnel 110 interface but this can be very different from a real tunnel mode, for 111 instance the inbound processing check for the source address is done 112 in tunnel mode on the inner (IPv6 here) address according to [3] 113 5.1.2.1 note 3 and 5.2.1 step 2. 115 An implementation for FreeBSD 4.1 revealed many practical problems 116 with IPsec implementations: 118 - mixed IP versions in tunnel mode is in [3] (5.1.2.1 note 5 119 for instance) but is not commonly implemented. 121 - some implementations spuriously check the outer source 122 address in tunnel mode. 124 - when transport mode is used because mixed version tunnel mode 125 is not available or does not provide some later points then 126 many implementations bark if the source IPv4 address changes. 128 - the tunnel interface lookup should use the Security 129 Association, on some implementations the tunnel interface code 130 and the IPsec code do not colaborate. 132 - tunnels should be interfaces, not only policies. For instance 133 a tunnel must have link-local addresses for neighbor 134 discovery and routing protocols. 136 - Security Association and Policy Database updates should be 137 allowed. 139 Today, many IPsec implementors do not understand the benefits to 140 have tunnels as virtual interfaces for IPv6 then a standard tunnel 141 interface and transport mode should be used. This near always raises 142 the changing source address issue which cannot be solved if some 143 strict ingress filtering [10] is done (then the old address is no 144 more available). 146 5. Security Considerations 148 Not authentic or replayed unsolicited neighbor advertisements 149 must be dropped. Most of the services listed in the previous 150 section can provide suitable shared secrets for IKE negotiation. 152 6. Changes from Previous Version of the Draft 154 This appendix briefly lists some of the major changes in this 155 draft relative to the previous version of this same draft, 156 draft-ietf-ngtrans-hometun-00.txt: 158 - Added Section 4 (IPsec Revisited) from implementation 159 experience. 161 7. References 163 [1] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 164 Hosts and Routers", RFC 1933, April 1996. 166 [2] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for 167 IP Version 6", RFC 2461, December 1998. 169 [3] S. Kent, R. Atkinson, "Security Architecture for the Internet 170 Protocol", RFC 2401, November 1998. 172 [4] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", 173 RFC 2406, November 1998. 175 [5] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 176 Authentication Dial In User Service (RADIUS)", RFC 2138, 177 April 1997. 179 [6] P. Calhoun, G. Zorn, P. Pan, "DIAMETER Framework Document", 180 draft-calhoun-diameter-framework-06.txt, work in progress, 181 March 2000. 183 [7] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 Tunnel 184 Broker", draft-ietf-ngtrans-broker-02.txt, work in progress, 185 October 1999. 187 [8] D. McDonald, "Link-shared secrets for ND", 47th IETF meeting, 188 Adelaide, Australia, March 2000. 190 [9] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 191 RFC 2409, November 1998. 193 [10] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating 194 Denial of Service Attacks which employ IP Source Address 195 Spoofing", RFC 2827 and BCP 38, May 2000. 197 8. Author's Address 199 Francis Dupont 200 ENST Bretagne 201 Campus de Rennes 202 2, rue de la Chataigneraie 203 BP 78 204 35512 Cesson-Sevigne Cedex 205 FRANCE 207 Fax: +33 2 99 12 70 30 208 EMail: Francis.Dupont@enst-bretagne.fr 210 Expire in 6 months (May 18, 2001)