idnits 2.17.1 draft-ietf-softwire-ds-lite-tunnel-option-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (September 27, 2010) is 4953 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: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwires D. Hankins 3 Internet-Draft ISC 4 Intended status: Standards Track T. Mrugalski 5 Expires: March 31, 2011 Gdansk University of Technology 6 September 27, 2010 8 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- 9 Stack Lite 10 draft-ietf-softwire-ds-lite-tunnel-option-05 12 Abstract 14 This document specifies single DHCPv6 option which is meant to be 15 used by a Dual-Stack Lite client (Basic Bridging BroadBand element, 16 B4) to discover its Address Family Transition Router (AFTR) address. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 31, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. The Dual-Stack Lite Address DHCPv6 Option . . . . . . . . . . . 3 55 4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 56 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 5 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 59 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 60 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 2. Introduction 71 Dual-Stack Lite [I-D.softwire-ds-lite] is a solution to offer both 72 IPv4 and IPv6 connectivity to customers which are addressed only with 73 an IPv6 prefix (no IPv4 address is assigned to the attachment 74 device). One of its key components is an IPv4-over-IPv6 tunnel, 75 commonly referred to as a Softwire. DS-Lite Basic Bridging BroadBand 76 (B4) will not know if the network it is attached to offers Dual-Stack 77 Lite support, and if it did would not know the remote end of the 78 tunnel to establish a connection. 80 To inform the B4 of the Address Family Transition Router's (AFTR) 81 location, an option containing a single IPv6 address may be used. 82 Once this information is conveyed, the presence of the configuration 83 indicating the AFTR's location also informs a host to initiate Dual- 84 Stack Lite (DS-Lite) service and become a Softwire Initiator. 86 To provide the conveyance of the configuration information, a single 87 DHCPv6 [RFC3315] option is used. 89 The details of how the B4 establishes an IPv4-in-IPv6 tunnel to the 90 AFTR are out of scope for this document. 92 3. The Dual-Stack Lite Address DHCPv6 Option 94 The Dual-Stack Lite Address option consists of option-code and 95 option-len fields (common for all DHCPv6 options), and a 128 bit 96 tunnel-endpoint-addr field, containing one IPv6 address. The tunnel- 97 endpoint-addr specifies the location of the remote tunnel endpoint, 98 expected to be located at an AFTR. 100 The DS-Lite Address option MAY appear in the root scope of a DHCPv6 101 packet. It MUST NOT appear inside any IA_NA, IA_TA, IA_PD, IAADDR, 102 or similar. Any DS-Lite Address option received inside any other 103 option MUST be ignored. 105 The DS-Lite Address option MUST NOT appear more than once in a 106 message. 108 The format of the Dual-Stack Lite Address option is shown in the 109 following figure: 111 0 1 2 3 112 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 113 +-------------------------------+-------------------------------+ 114 | OPTION_DS_LITE_ADDR (TBD) | option-len: 16 | 115 +-------------------------------+-------------------------------+ 116 | | 117 | tunnel-endpoint-addr (IPv6 Address) | 118 | | 119 | | 120 +---------------------------------------------------------------+ 122 option-code: OPTION_DS_LITE_ADDR (TBD) 124 option-len: Length of the tunnel-endpoint-addr field, 125 which is precisely 16 octets. 127 tunnel-endpoint-addr: A single IPv6 address in binary 128 representation of the remote tunnel 129 endpoint, located at the DS-Lite AFTR. 131 Figure 1: DS-Lite IPv6 Address DHCPv6 Option Format 133 The client validates the DS-Lite Address option by confirming the 134 option length is exactly 16 octets. The client MUST ignore any DS- 135 Lite Address option that has length other than 16 octets. 137 Because this option conveys the tunnel-endpoint-addr value, no 138 further processing is required of the client. 140 This option conveys a single IPv6 address, as the Dual-Stack Lite 141 specification [I-D.softwire-ds-lite] defines only one Softwire 142 connection between a B4 and any AFTR. Multiple connections or 143 endpoints are undefined. It is expected that Service Provider (SP) 144 will deal with load balancing and high availability, not the client. 145 For more information, see Section 12.3 "High Availability" of 146 [I-D.softwire-ds-lite]. 148 4. DHCPv6 Server Behavior 150 Following requirements are result of applying behaviors defined in 151 RFC 3315 Section 17.2.2 [RFC3315] to the DS-Lite Address option. 152 They do not change default DHCPv6 operation, but rather are 153 enumerated here as a convenience for the reader. 155 If configured to offer DS-Lite Address information, DHCPv6 server 156 will include the DS-Lite Address option if such option appears on the 157 client's Option Request Option (OPTION_ORO). RFC 3315 Section 17.2.2 158 [RFC3315] describes how a DHCPv6 client and server negotiate 159 configuration values using the ORO. 161 A DHCPv6 server MUST NOT send DS-Lite Address option if it has not 162 been explicitly requested by the client. 164 A DHCPv6 server MUST NOT send more than one DS-Lite Address option. 166 A DHCPv6 server MUST NOT send DS-Lite Address as suboption in other 167 options. 169 5. DHCPv6 Client Behavior 171 A client that supports B4 functionality of DS-Lite (defined in 172 [I-D.softwire-ds-lite]) and conforms to this specification MUST 173 include OPTION_DS_LITE_ADDR on its OPTION_ORO. 175 If the client receives DS-Lite Address option, it MUST verify the 176 option contents as described in Section 3. The client (B4) is 177 expected to establish a softwire tunnel to the tunnel-endpoint-addr 178 IPv6 address it determines from DS-Lite Address option. 180 Client that receives more than one DS-Lite Address option MUST 181 discard all instances of that option. 183 6. Security Considerations 185 This document does not present any new security issues, but as with 186 all DHCPv6-derived configuration state, it is completely possible 187 that the configuration is being delivered by a third party (Man In 188 The Middle). As such, there is no basis to trust that the access the 189 DS-Lite Softwire connection represents can be trusted, and it should 190 not therefore bypass any security mechanisms such as IP firewalls. 192 RFC 3315 [RFC3315] discusses DHCPv6-related security issues. 194 [I-D.softwire-ds-lite] discusses DS-Lite related security issues. 196 7. IANA Considerations 198 IANA is requested to allocate single DHCPv6 option code referencing 199 this document, delineating OPTION_DS_LITE_ADDR name. 201 8. Acknowledgements 203 Authors would like to thank Alain Durand, Rob Austein, Dave Thaler, 204 Paul Selkirk and Ralph Droms for their valuable feedback and 205 suggestions. 207 This work has been partially supported by the Polish Ministry of 208 Science and Higher Education under the European Regional Development 209 Fund, Grant No. POIG.01.01.02-00-045/09-00 (Future Internet 210 Engineering Project). 212 9. Normative References 214 [I-D.softwire-ds-lite] 215 Durand, A., Ed., "Dual-stack lite broadband deployments 216 post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite 217 (work in progress). 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 223 and M. Carney, "Dynamic Host Configuration Protocol for 224 IPv6 (DHCPv6)", RFC 3315, July 2003. 226 Authors' Addresses 228 David W. Hankins 229 Internet Systems Consortium, Inc. 230 950 Charter Street 231 Redwood City, CA 94063 232 US 234 Phone: +1 650 423 1307 235 Email: David_Hankins@isc.org 237 Tomasz Mrugalski 238 Gdansk University of Technology 239 Storczykowa 22B/12 240 Gdansk 80-177 241 Poland 243 Phone: +48 698 088 272 244 Email: tomasz.mrugalski@eti.pg.gda.pl