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]