DHC T. Mrugalski Internet-Draft ISC Intended status: Standards Track July 02, 2011 Expires: January 3, 2012 DHCPv6 Options for IPv4 Residual Deployment (4rd) draft-mrugalski-dhc-dhcpv6-4rd-00 Abstract This document specifies DHCPv6 options which are meant to be used by 4rd Customer Edge (CE) to obtain necessary parameters to configure their 4rd automatic tunnels. The 4rd architecture is defined in [I-D.despres-intarea-4rd]. Since specification of 4rd is still expected to evolve, DHCPv6 options may have to evolve too to fit the revised 4rd specification. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Mrugalski Expires January 3, 2012 [Page 1] Internet-Draft 4rd DHCPv6 Options July 2011 described in the Simplified BSD License. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DHCPv6 Options Format . . . . . . . . . . . . . . . . . . . . 3 3.1. 4rd Options Cardinality . . . . . . . . . . . . . . . . . 4 3.2. 4rd Mapping Rule Option . . . . . . . . . . . . . . . . . 4 3.3. CE IPv6 Prefix Option . . . . . . . . . . . . . . . . . . 5 3.4. CE IPv6 Prefix Length Option . . . . . . . . . . . . . . . 6 3.5. Domain 4rd Prefix Option . . . . . . . . . . . . . . . . . 6 3.6. Domain IPv6 Suffix Option . . . . . . . . . . . . . . . . 7 3.7. BR Anycast Option . . . . . . . . . . . . . . . . . . . . 8 4. 4rd Options Example . . . . . . . . . . . . . . . . . . . . . 8 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 8 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Mrugalski Expires January 3, 2012 [Page 2] Internet-Draft 4rd DHCPv6 Options July 2011 1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction IPv4 Residual Deployment across IPv6-Service networks (4rd) [I-D.despres-intarea-4rd] is an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network. To operate properly, 4rd Customer Edge (CE) requires one or more mapping rules configured. One mapping rule constists of the following parameters: Length of CE IPv6 Prefix, Domain IPv6 Prefix, Domain 4rd Prefix, and optionally Domain IPv6 suffix. Also, Anycast BR IPv6 address must be configured for proper operation. This document defines several DHCPv6 options that allow delivery of required information to configure CE. Definitions of enumerated parameters are provided in [I-D.despres-intarea-4rd]. Since specification of 4rd is still expected to evolve, DHCPv6 options may have to evolve too to fit the revised 4rd specification. 3. DHCPv6 Options Format To configure CE equipment remotely, DHCPv6 should be used. Several new options are defined for that purpose. Their format and usage is defined in the following sections. Discussion: Proposed layout assumes that several simple options are used. Such approach simplifies implementation as it is much easier for implementors to reuse existing code handling such options. This design choice comes at a cost, however. Clients must perform checks if provided set of options is complete. Alternatively, it would be possible to define one complex option that contains all mandatory parameters. Nevertheless, since postfix parameter is optional, it would still require sub-options (or conditional formatting that is strongly not recommended [I-D.ietf-dhc-option-guidelines]). Discussion: It has also been proposed that since 3 mandatory parameters - Domain IPv6 Prefix, Length of the CE IPv6 Prefix (note: these are different prefixes), and Domain 4rd prefix - are always present, they may be grouped together. Mrugalski Expires January 3, 2012 [Page 3] Internet-Draft 4rd DHCPv6 Options July 2011 3.1. 4rd Options Cardinality To properly configure 4rd infrastructure, following parameters are required: Exactly one Anycast BR IPv6 Address. One or more 4rd mapping rules. Each 4rd mapping rule consists of exactly one 4rd CE prefix, exactly one CE IPv6 prefix length, and exactly one 4rd prefix. Each mapping rule may contain zero or one Domain IPv6 Suffix. 3.2. 4rd Mapping Rule Option The 4rd Mapping Rule Option does not convey any information on its own, but rather is used to group options that represent parameteres of a single mapping rule. 4rd architecture allows more than one mapping rules, therefore the 4rd Mapping Rule Option MAY appear more than once in a DHCPv6 message. The format of the 4rd Mapping Rule Option is shown in Figure 1. 0 1 2 3 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 +-------------------------------+-------------------------------+ | OPTION_4RD_RULE (TBD) | option-len | +-------------------------------+-------------------------------+ | | | sub-options | | | +---------------------------------------------------------------+ option-code: OPTION_4RD_RULE (TBD) option-len: Length of all sub-options. sub-options: options defining Mapping Rule parameters Figure 1: 4rd Mapping Rule Option The 4rd Mapping Rule Option consists of option-code and option-len fields (as all DHCPv6 options do), and a variable length sub-options field that contains rule parameters. The 4rd Mapping Rule Option SHOULD NOT appear in any other than the following DHCPv6 messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request and Reply. The 4rd Rule Option may appear more than once in each message. Mrugalski Expires January 3, 2012 [Page 4] Internet-Draft 4rd DHCPv6 Options July 2011 Each 4rd Mapping Rule Option MUST contain exactly one 4rd CE Prefix Option, exactly one CE IPv6 Prefix Length Option, exactly one 4rd Prefix Option and zero or one Domain IPv6 Suffix Option. Option that does not meet this criteria is invalid and MUST be ignored. 4rd Mapping Rule Option may contain additional options. Discussion: Defined format does not allow referencing rules, i.e. if there are several rules, there is no rule 1, rule 2 etc. DHCPv6 protocol does not allow leveraging order in which options appear in the message. If rule indentification is useful, a small ID field may be added to the 4rd Mapping Rule Option. 3.3. CE IPv6 Prefix Option CE IPv6 Prefix Option conveys information about domain IPv6 prefix that is going to be used by requesting client (CE). The format of the CE IPv6 Prefix Option is defined in Figure 2. 0 1 2 3 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 +-------------------------------+-------------------------------+ | OPTION_4RD_PREFIX6 | option-len | +-------------------------------+-------------------------------+ | | | domain-ipv6-prefix | | | | | +---------------------------------------------------------------+ option-code: OPTION_4RD_PREFIX6 (TBD) option-len: Length of Domain IPv6 Prefix in octets (16) domain-ipv6-prefix: 4rd Domain IPv6 Prefix Figure 2: CE IPv6 Prefix Option The CE IPv6 Prefix Option consists of option-code and option-len fields (as all DHCPv6 options do), and 16 octets long Domain IPv6 Prefix field. The CE IPv6 Prefix Option MUST NOT appear in DHCPv6 message directly. It MUST NOT appear in any option other than 4rd Mapping Rule Option. Mrugalski Expires January 3, 2012 [Page 5] Internet-Draft 4rd DHCPv6 Options July 2011 3.4. CE IPv6 Prefix Length Option The CE IPv6 Prefix Length Option defines length of the prefix assigned to specific CE. It is expected to be used together with CE IPv6 Prefix Option, defined in Section Section 3.3. The format of the CE Prefix Length Option is shown in Figure 3. 0 1 2 3 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 +-------------------------------+-------------------------------+ | OPTION_4RD_PREFIX6_LEN | option-len | +-------------------------------+-------------------------------+ | prefix len | +---------------+ option-code: OPTION_4RD_PREFIX6_LEN: (TBD) option-len: Length of the prefix-len field in octets (1) prefix-len: Length of Domain IPv6 Prefix Figure 3: CE IPv6 Prefix Length Option The CE IPv6 Prefix Length Option consists of option-code and option- len fields (as all DHCPv6 options do), and 1 octet long Domain IPv6 Prefix Length field that specifies length in bits (0-64). The CE IPv6 Prefix Length Option MUST NOT appear in DHCPv6 message directly. It MUST NOT appear in any option other than 4rd Mapping Rule Option. 3.5. Domain 4rd Prefix Option The Domain 4rd Prefix Option contains IPv4 address. Depending on its length it is IPv4 prefix, an IPv4 address, or a shared IPv4 address followed by Port-set ID. The format of the Domain 4rd Prefix Option is shown in Figure Figure 4. Mrugalski Expires January 3, 2012 [Page 6] Internet-Draft 4rd DHCPv6 Options July 2011 0 1 2 3 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 +-------------------------------+-------------------------------+ | OPTION_4RD_PREFIX4 | option-len | +-------------------------------+-------------------------------+ | domain-4rd-prefix | +-------------------------------+-------------------------------+ | 4rd-prefix-len| +---------------+ OPTION_4RD_PREFIX: (TBD) option-len: 7 domain-4rd-prefix: Domain 4rd Prefix (an IPv4 address) 4rd-prefix-len: Length of Domain IPv6 Prefix (in bits) Figure 4: Domain 4rd Prefix Option The Domain 4rd Prefix Option consists of option-code and option-len fields (as all DHCPv6 options do), four octets long domain-4rd-prefix field that contains IPv4 address and one octect long 4rd-prefix-len. Depending on 4rd-prefix-len value, actual 4rd Prefix may be range of IPv4 addresses (part of domain-4rd-prefix), a single IPv4 address (specified by domain-4rd-prefix) or IPv4 address+port range (specified by domain-4rd-prefix and Port-set ID). Port-Set ID is derived from CE Index, as explained in see Section 4.3.3 in [I-D.despres-intarea-4rd]. 3.6. Domain IPv6 Suffix Option TODO: I don't understand what this suffix is. [I-D.despres-intarea-4rd] is unclear. My understanding is that suffix are bits that are appended to Domain IPv6 Prefix + CE Index and they together form CE IPv6 Prefix. It is only used when Domain IPv6 Prefix and CE Index are short enough. On the other hand, slide 4 of http://tools.ietf.org/agenda/80/slides/dhc-6.pdf suggests that suffix defines something that is appended after CE IPv6 Prefix. Discussion: Wouldn't it be better to just use Domain IPv6 Prefix as a template with CE Index inserted at appropriate offset? This would make configuration simpler (one less option) and also validation of received option would be much more straightforward. Mrugalski Expires January 3, 2012 [Page 7] Internet-Draft 4rd DHCPv6 Options July 2011 3.7. BR Anycast Option The BR Anycast Option specifies an IPv6 anycast address that should be used to reach nearest Border Relay. The format of the BR Anycast Option is shown in Figure 5. 0 1 2 3 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 +-------------------------------+-------------------------------+ | OPTION_4RD_BR | option-len | +-------------------------------+-------------------------------+ | | | br-anycast-addr | | | | | +---------------------------------------------------------------+ option-code: OPTION_4RD_BR (TBD) option-len: Length of BR IPv6 Anycast Prefix (16) br-anycast-addr: Border Relay IPv6 Anycast Address Figure 5: BR IPv6 Address Option The BR IPv6 Address Option consists of option-code and option-len fields (as all DHCPv6 options do), and a 16 octets long br-anycast- addr field that specifies Border Relay IPv6 Anycast address. The BR Anycast Option SHOULD NOT appear in any other than the following DHCPv6 messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request and Reply. The BR Anycast Option MAY appear zero or one time in a single message. 4. 4rd Options Example TODO: Provide an example here. Possibly reuse example from Remi's presentation from IETF80. 5. DHCPv6 Server Behavior Server conformant to this specification MUST allow configuration of one or more Mapping Rule Options. Mrugalski Expires January 3, 2012 [Page 8] Internet-Draft 4rd DHCPv6 Options July 2011 Server MUST transmist all configured instances of the Mapping Rule Options with all sub-options, if client requested it using OPTION_4RD_RULE in ORO. RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and server negotiate configuration values using the Option Request Option (OPTION_ORO). As a convenience to the reader, we mention here that a server will not reply with a 4rd Mapping Rule Option if the client has not explicitly enumerated it on its Option Request Option. 6. DHCPv6 Client Behavior Although other use cases are allowed, in typical use case CE will act as DHCPv6 client and will request 4rd configuration to be assigned by the DHCPv6 server located in the ISP network. A client that supports 4rd CE functionality and conforms to this specfication MUST include OPTION_4RD_RULE in its ORO. Client SHOULD request 4rd options in SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages. If the client receives OPTION_4RD_RULE option, it must verify the option contents, as described in Section 3.2. In case of failved verification, client MUST discard invalid option and continue processing any following options, including other instances of 4rd options. If client receives more than one OPTION_4RD_RULE, it MUST use all received instances. It MUST NOT use only the first one, while discarding remaining ones. Note that system implementing 4rd CE functionality may have multiple network interfaces, and these interfaces may be configured differently; some may be connected to networks that call for 4rd, and some may be connected to networks that are using normal dual stack or other means. The 4rd CE system should approach this specification on an interface-by-interface basis. For example, if the CE system is attached to multiple networks that provide the 4rd Mapping Rule Option, then the CE system MUST configure a 4rd tunnel for each interface separately as each 4rd provides IPv4 connectivity for each distinct interface. Means to bind a 4rd configuration to a given interface in a multiple interfaces device are out of scope of this document. Mrugalski Expires January 3, 2012 [Page 9] Internet-Draft 4rd DHCPv6 Options July 2011 7. Security Considerations Implementation of this document does not present any new security issues, but as with all DHCPv6-derived configuration state, it is completely possible that the configuration is being delivered by a third party (Man In The Middle). As such, there is no basis to trust that the access the 4rd can be trusted, and it should not therefore bypass any security mechanisms such as IP firewalls. Section 23 of [RFC3315] discusses DHCPv6-related security issues. Section 6 of [I-D.despres-intarea-4rd] discusses 4rd related security issues. 8. IANA Considerations IANA is requested to allocate DHCPv6 option codes referencing this document, delineating OPTION_4RD_RULE, OPTION_4RD_PREFIX6, OPTION_4RD_PREFIX6_LEN, OPTION_4RD_PREFIX and OPTION_4RD_BR option names. 9. Acknowledgements This document would not have been possible without support from Remi Despres, Satoru Matsushima, Ole Troan and Tetsuya Murakami. 10. References 10.1. Normative References [I-D.despres-intarea-4rd] Despres, R., Matsushima, S., Murakami, T., and O. Troan, "IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional", draft-despres-intarea-4rd-01 (work in progress), March 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Mrugalski Expires January 3, 2012 [Page 10] Internet-Draft 4rd DHCPv6 Options July 2011 10.2. Informative References [I-D.ietf-dhc-option-guidelines] Hankins, D., "Guidelines for Creating New DHCP Options", draft-ietf-dhc-option-guidelines-06 (work in progress), March 2010. Author's Address Tomasz Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA Phone: +1 650 423 1345 Email: tomasz.mrugalski@gmail.com Mrugalski Expires January 3, 2012 [Page 11]