One document matched: draft-mrugalski-dhc-dhcpv6-4rd-00.xml
<?xml version='1.0' ?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?> <?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM 'rfc2629bis.dtd' [
]>
<rfc ipr="trust200902" category="std"
docName="draft-mrugalski-dhc-dhcpv6-4rd-00">
<front>
<title abbrev="4rd DHCPv6 Options">DHCPv6 Options for IPv4 Residual Deployment (4rd)</title>
<author fullname="Tomasz Mrugalski" initials="T" surname="Mrugalski">
<organization abbrev="ISC">Internet Systems Consortium, Inc.
</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>USA</country>
</postal>
<phone>+1 650 423 1345</phone>
<email>tomasz.mrugalski@gmail.com</email>
</address>
</author>
<date day="02" month="July" year="2011"/>
<area>Internet</area>
<workgroup>DHC</workgroup>
<keyword>DHCPv6</keyword>
<keyword>4rd</keyword>
<abstract>
<t>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 <xref target="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.</t>
</abstract>
</front>
<middle>
<section title="Requirements Language">
<t>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
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Introduction">
<t>IPv4 Residual Deployment across IPv6-Service networks (4rd)
<xref target="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 <xref
target="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.
</t>
</section>
<section title="DHCPv6 Options Format">
<t>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.</t>
<t>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 <xref target="I-D.ietf-dhc-option-guidelines"/>).</t>
<t>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.</t>
<section title="4rd Options Cardinality">
<t>To properly configure 4rd infrastructure, following
parameters are required:</t>
<list>
<t>Exactly one Anycast BR IPv6 Address.</t>
<t>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.</t>
</list>
</section>
<section anchor="option-mapping-rule" title="4rd Mapping Rule Option">
<t>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.</t>
<t>The format of the 4rd Mapping Rule Option is shown in <xref
target="figure-mapping-rule"/>.</t>
<figure align="center" anchor="figure-mapping-rule"
title="4rd Mapping Rule Option">
<artwork>
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
</artwork>
</figure>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>4rd Mapping Rule Option may contain additional options.</t>
<t>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.</t>
</section>
<section anchor="option-ce-prefix6" title="CE IPv6 Prefix Option">
<t>CE IPv6 Prefix Option conveys information about domain IPv6
prefix that is going to be used by requesting client (CE).</t>
<t>The format of the CE IPv6 Prefix Option is defined in <xref
target="figure-ce-prefix6"/>.</t>
<figure align="center" anchor="figure-ce-prefix6"
title="CE IPv6 Prefix Option">
<artwork>
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
</artwork>
</figure>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="option-ce-prefix-len" title="CE IPv6 Prefix Length Option">
<t>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
<xref target="option-ce-prefix6"/>.</t>
<t>The format of the CE Prefix Length Option is shown in <xref
target="figure-ce-prefix-len"/>.</t>
<figure align="center" anchor="figure-ce-prefix-len"
title="CE IPv6 Prefix Length Option">
<artwork>
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
</artwork>
</figure>
<t>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).</t>
<t>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.</t>
</section>
<section anchor="option-domain-prefix4" title="Domain 4rd Prefix Option">
<t>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.</t>
<t>The format of the Domain 4rd Prefix Option is shown in
Figure <xref target="figure-domain-prefix4"/>.</t>
<figure align="center" anchor="figure-domain-prefix4"
title="Domain 4rd Prefix Option">
<artwork>
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)
</artwork>
</figure>
<t>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.</t>
<t>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 <xref
target="I-D.despres-intarea-4rd"/>.</t>
</section>
<section title="Domain IPv6 Suffix Option">
<t>TODO: I don't understand what this suffix
is. <xref target="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.</t>
<t>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.</t>
</section>
<section anchor="option-br" title="BR Anycast Option">
<t>The BR Anycast Option specifies an IPv6 anycast
address that should be used to reach nearest Border
Relay.</t>
<t>The format of the BR Anycast Option is shown in <xref
target="figure-br"/>.</t>
<figure align="center" anchor="figure-br"
title="BR IPv6 Address Option">
<artwork>
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
</artwork>
</figure>
<t>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.</t>
<t>The BR Anycast Option SHOULD NOT appear in any other than the
following DHCPv6 messages: Solicit, Advertise, Request, Renew, Rebind,
Information-Request and Reply.</t>
<t>The BR Anycast Option MAY appear zero or one time in a
single message.</t>
</section>
</section> <!-- end of option formats section -->
<section title="4rd Options Example">
<t>TODO: Provide an example here. Possibly reuse example from Remi's
presentation from IETF80.</t>
</section>
<section title="DHCPv6 Server Behavior">
<t>Server conformant to this specification MUST allow
configuration of one or more Mapping Rule Options.</t>
<t>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.</t>
<t><xref target="RFC3315">RFC 3315 Section 17.2.2</xref>
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.</t>
</section>
<section title="DHCPv6 Client Behavior">
<t>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.</t>
<t>Client SHOULD request 4rd options in SOLICIT, REQUEST, RENEW,
REBIND and INFORMATION-REQUEST messages.</t>
<t>If the client receives OPTION_4RD_RULE option, it must verify
the option contents, as described in
<xref target="option-mapping-rule"/>. In case of failved
verification, client MUST discard invalid option and continue
processing any following options, including other instances of
4rd options.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>Section 23 of <xref target="RFC3315"/> discusses DHCPv6-related security issues.</t>
<t>Section 6 of <xref target="I-D.despres-intarea-4rd"/> discusses 4rd
related security issues.</t>
</section>
<section title="IANA Considerations">
<t>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.</t>
</section>
<section title="Acknowledgements">
<t>This document would not have been possible without support
from Remi Despres, Satoru Matsushima, Ole Troan and Tetsuya
Murakami.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.despres-intarea-4rd.xml'?>
</references>
<references title="Informative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-option-guidelines.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:18:15 |