idnits 2.17.1 draft-dhankins-softwire-tunnel-option-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (March 23, 2009) is 5505 days in the past. Is this intentional? 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 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working D. Hankins 3 Group ISC 4 Internet-Draft March 23, 2009 5 Intended status: Standards Track 6 Expires: September 24, 2009 8 Dynamic Host Configuration Protocol Option for Dual-Stack Lite 9 draft-dhankins-softwire-tunnel-option-03 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 24, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes how Dual-Stack Lite configuration (the 48 Softwire Concentrator (SC)'s address) can be obtained by a Softwire 49 Initiator (SI) via DHCPv6. 51 Table of Contents 53 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The Dual-Stack Lite DHCPv6 Option . . . . . . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Requirements Language 63 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 64 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 65 described in BCP 14, RFC 2119 [RFC2119]. 67 2. Introduction 69 Dual-Stack Lite [draft-ietf-softwire-dual-stack-lite-00] is a method 70 to extend IPv4 access to an IPv6-only addressed host. One of its key 71 components is an IPv4-over-IPv6 tunnel, commonly referred to as a 72 Softwire, but a host will not know if the network it is attached to 73 offers Dual-Stack Lite support, and if it did would not know the 74 remote end of the tunnel to establish a connection. 76 These are two separate pieces of information; 1) Should I shut down 77 my dual-stack IPv4 side, and use the softwire exclusively for IPv4 78 access? 2) At what IPv6 address should I establish a softwire 79 connection? 81 These two questions can be answered with one DHCPv6 [RFC3315] option. 83 DISCUSSION: It can be argued that if you inform a client it should 84 perform Dual-Stack Lite, but fail to deliver an IPv6 tunnel endpoint, 85 then its IPv4 access is certainly broken. If you give the client an 86 IPv6 tunnel endpoint but fail to inform it that it must use Dual- 87 Stack Lite for IPv4 access, then again its access is likely broken, 88 or is operating in a degraded mode of service (if an operator offers 89 a Dual-Stack Lite method of access, there either isn't any native 90 IPv4 access, or the Dual-Stack Lite method works better than native 91 access - if a network had better native IPv4 access than Dual-Stack 92 Lite access, there would be no reason to extend the service). So the 93 presence of a tunnel address also indicates the intent to use it. 95 3. The Dual-Stack Lite DHCPv6 Option 97 The Dual-Stack Lite DHCPv6 Option is simply an IPv6 address. 99 The Dual-Stack Lite Option Format follows: 101 0 1 2 3 102 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | OPTION_DS_LITE (TBD) | length (16) | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | | 107 | IPv6 Address | 108 | | 109 | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 The code for this option is TBD. The length is precisely 16. The 113 IPv6 Address field is an IPv6 address. 115 The DS Lite option MAY appear in the root scope of a DHCPv6 packet. 116 It MUST NOT appear inside any IA_NA, IA_TA, IA_PD, IAADDR, or 117 similar. 119 If configured with a value, DHCPv6 servers will include the Softwires 120 option if it appears on the client's Option Request Option 121 (OPTION_ORO). RFC 3315 Section 17.2.2 [RFC3315] describes how a 122 DHCPv6 client and server negotiate configuration values using the 123 ORO. 125 A client that supports DS Lite MUST include OPTION_DS_LITE on its 126 OPTION_ORO. There is no reasonable expectation that a server will 127 reply with the DS Lite option if it has not been requested. 129 If the client receives a DS Lite Option, it MUST verify the option 130 length is precisely 16 octets, and ignore the option otherwise. 131 Provided it is of valid length, the client SHOULD terminate or 132 withdraw any DHCPv4 [RFC2131] configuration on the same interface. 133 If DHCPv4 configuration has concluded, the client SHOULD perform a 134 DHCPRELEASE as it tears down its IPv4 configuration. The client 135 SHOULD establish a softwire tunnel to the included IPv6 address. 137 DISCUSSION: The author's best understanding of the current 138 epistemology on IPv6 multihoming is that the client will have IPv6 139 addresses on multiple different IPv6 prefixes. If a host is 140 multihomed, then, it is strange enough to wonder how DHCPv6 141 configuration will work as most DHCPv6 clients will attach to only 142 one DHCPv6 server. It is even stranger to wonder how the client 143 would react if all of its multiple homes wished to provide IPv4 144 access via DS Lite. Would a client establish more than one tunnel? 145 Perhaps this option should permit multiple IPv6 addresses? 147 4. Security Considerations 149 This document does not present any new security issues, but as with 150 all DHCPv6-derived configuration state, it is completely possible 151 that the configuration is being delivered by a third party (Man In 152 The Middle). As such, there is no basis to trust that the access the 153 DS-Lite softwire connection represents can be trusted, and it should 154 not therefore bypass any security mechanisms such as IP firewalls. 156 RFC 3315 [RFC3315] discusses DHCPv6 related security issues. 158 5. IANA Considerations 160 IANA is requested to allocate one DHCPv6 Option code, referencing 161 this document. 163 6. Normative References 165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, March 1997. 168 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 169 RFC 2131, March 1997. 171 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 172 and M. Carney, "Dynamic Host Configuration Protocol for 173 IPv6 (DHCPv6)", RFC 3315, July 2003. 175 [draft-ietf-softwire-dual-stack-lite-00] 176 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 177 "Dual-stack lite broadband deployments post IPv4 178 exhaustion", March 2009. 180 Author's Address 182 David W. Hankins 183 Internet Systems Consortium, Inc. 184 950 Charter Street 185 Redwood City, CA 94063 186 US 188 Phone: +1 650 423 1307 189 Email: David_Hankins@isc.org