One document matched: draft-mrugalski-softwire-dhcpv4-over-v6-option-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-softwire-dhcpv4-over-v6-option-00">
<front>
<title abbrev="DHCPv4 over IPv6 DHCPv6 Option">Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) Option for DHCPv4 over
IPv6 Transport</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>
<author initials="P." surname="Wu" fullname="Peng Wu">
<organization>Tsinghua University</organization>
<address>
<postal>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<email>pengwu.thu@gmail.com</email>
</address>
</author>
<date month="April" year="2012"/>
<area>Internet</area>
<workgroup>Softwire</workgroup>
<keyword>DHCPv6</keyword>
<keyword>Softwire</keyword>
<keyword>DHCPv4 over IPv6</keyword>
<abstract>
<t><xref target="I-D.ietf-dhc-dhcpv4-over-ipv6"/>
defines a way for communication between legacy DHCPv4 clients
with DHCPv4 servers over IPv6-only transport. It requires the
deployment of Client Relay Agent (CRA) that transmits messages
to IPv6-Transport Server (TSV) or IPv6-Transport Relay Agent
(TRA). The deployed CRA must know the address of a TSV or TRA to
forward incoming client's messages. This document defines an
DHCPv6 option that may be used to provision the TSV or TRA location
to CRAs.</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><xref target="I-D.ietf-dhc-dhcpv4-over-ipv6"/> defines a way
for communication between legacy DHCPv4 clients with DHCPv4
servers (defined in <xref target="RFC2131"/>) over IPv6-only
transport. It requires the deployment of Client Relay Agent (CRA)
that transmits messages to IPv6-Transport Server (TSV) or
IPv6-Transport Relay Agent (TRA). There are several
scenarios envisaged, all of them assume that CRA needs to know
the recipient address of the DHCPv4-over-IPv6 traffic.</t>
<t>Depending on the scenario discussed, the DHCPv4 over IPv6
transport endpoint could be either an IPv6-Transport Server (TSV)
or an IPv6-Transport Relay Agent (TRA). Both cases are
indistinguishable from the CRA's perspective. CRA needs to know TSV's
or TRA's IPv6 address in advance to relay traffic.</t>
<t>As the CRA uplink is IPv6-only (otherwise there would be no need
to deploy DHCPv4 over IPv6), the only feasible way to provision
information to CRA is over DHCPv6. Therefore this document specifies
a DHCPv6 option that conveys the necessary information to CRA. To be
more specific, a single <xref target="RFC3315">DHCPv6</xref> option
is used, expressing the TRA's or TSV's Fully Qualified Domain Name
(FQDN) to the CRA.</t>
</section>
<section title='The DHCPv4-Over-IPv6 DHCPv6 Option' anchor='option-name'>
<t>The DHCPv4-over-IPv6 option is a DHCPv6 option. It consists
of an option-code and option-len fields (as all DHCPv6 options
have), and a variable length dhcpv4-over-ipv6-endpoint-name
field containing a fully qualified domain name that refers to
the DHCPv4 over IPv6 transport endpoint to which the CRA MAY
transport DHCPv4 traffic. This name represents a TRA or TSV,
depending on deployment scenario.</t>
<t>The DHCPv4-over-IPv6 option SHOULD NOT appear in any other
than the following DHCPv6 messages: Solicit, Advertise, Request,
Renew, Rebind, Information-Request and Reply.</t>
<t>The format of the DHCPv4 over IPv6 option is shown in the
following figure:</t>
<figure align="center" anchor="option-format-name"
title="AFTR-Name DHCPv6 Option Format">
<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_DHCP4_OVER_V6: (TBD) | option-len |
+-------------------------------+-------------------------------+
| |
| dhcpv4-over-ipv6-endpoint-name (FQDN) |
| |
+---------------------------------------------------------------+
OPTION_DHCP4_OVER_V6: (TBD)
option-len: Length of the dhcpv4-over-ipv6-endpoint-name
field, expressed in octets.
dhcpv4-over-ipv6-endpoint-name: A fully qualified domain name
of the DHCPv4-over-IPv6 transport endpoint.
</artwork>
</figure>
<t>The dhcpv4-over-ipv6-endpoint-name field is formatted as
required in <xref target="RFC3315">DHCPv6</xref> Section 8
("Representation and Use of Domain Names"). Briefly, the
format described uses a single octet noting the length of one
DNS label (limited to at most 63 octets), followed by the label
contents. This repeats until all labels in the FQDN are exhausted,
including a terminating zero-length label. Any updates to Section 8
of <xref target="RFC3315">DHCPv6</xref> also apply to encoding of this
field. An example format for this option is shown in
<xref target="fqdn-example"/>, which conveys the FQDN
"dhcp.example.com.".</t>
<figure align="center" anchor="fqdn-example"
title="Example dhcpv4-over-ipv6-endpoint-name.">
<artwork>+------+------+------+------+------+------+------+------+------+
| 0x04 | d | h | c | p | 0x07 | e | x | a |
+------+------+------+------+------+------+------+------+------+
| m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+</artwork>
</figure>
<t>Note that in the specific case of the
<xref target="fqdn-example">example</xref>,
the length of the dhcpv4-over-ipv6-endpoint-name is 18 octets, and so an
option-len field value of 18 would be used.</t>
<t>The option is validated by confirming that all of the
following conditions are met:
<list style="numbers">
<t>the option-len is greater than 3;</t>
<t>the option data can be contained by the option length, and
the option length does not run off the end of the packet;</t>
<t>the individual label lengths do not exceed the option length;</t>
<t>the dhcpv4-over-ipv6-endpoint-name is of valid format as described
in DHCPv6 Section 8 <xref target="RFC3315"/>;</t>
<t>there are no compression tags;</t>
<t>there is at least one label of nonzero length.</t>
</list>
</t>
</section>
<section title="DHCPv6 Server Behavior">
<t>A DHCPv6 server SHOULD NOT send more than one DHCPv4-over-IPv6
option. It SHOULD NOT permit the configuration of multiple
names within one DHCPv4-over-IPv6 option. Both of these
conditions are handled as exception by the client, so an
operator using software that does not perform these validations
should be careful not to configure multiple domain names.</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 DHCPv4-over-IPv6 option if the client has not
explicitly enumerated it in its Option Request Option. In other
words, server SHOULD send this option only if client explicitly
requested it in ORO.</t>
</section>
<section title="DHCPv6 Client Behavior">
<t>A client that supports the DHCPv4 over IPv6 functionality
and conforms to this specification MUST include OPTION_DHCP4_OVER_V6
on its OPTION_ORO.</t>
<t>Because it requires DNS name to address resolution, the client SHOULD
also wish to include the <xref target="RFC3646">OPTION_DNS_SERVERS</xref>
option on its OPTION_ORO.</t>
<t>If the client receives the DHCPv4-over-IPv6 option, it MUST verify the
option contents as described in <xref target="option-name"/>.</t>
<t>If the CRA entity receives more than one DHCPv4-over-IPv6 option, it
MUST use only one instance of that option.</t>
<t>If the DHCPv4-over-IPv6 option contains more than one FQDN,
as distinguished by the presence of multiple root labels, the CRA entity
system MUST use only the first FQDN listed in configuration. It SHOULD
warn its operator about such condition.</t>
<t>The CRA entity performs standard DNS resolution using the provided FQDN
to resolve a AAAA Resource Record, as defined in
<xref target="RFC3596"/> and STD 13 <xref target="RFC1034"/>
<xref target="RFC1035"/>.</t>
<t>If any DNS response contains more than one IPv6 address (probably for
redundancy and high availability consideration), the CRA entity picks
only one IPv6 address and uses it as a DHCPv4-over-IPv6 transport
endpoint for the interface being configured in the current message
exchange. The CRA system MUST NOT establish more than one transport
at the same time per interface.</t>
<t>Note that a CRA system may have multiple network interfaces,
and these interfaces may be configured differently; some may be
connected to networks that call for DHCPv4-over-IPv6, and some
may be connected to networks that are using normal dual stack or
other means. The CRA entity should approach this specification
on an interface-by-interface basis. For example, if the CRA
entity is attached to multiple networks that provide the
DHCPv4-over-IPv6 option, then the CRA entity MUST configure a
DHCPv4 over IPv6 transport for each interface separately as each
transport provides IPv4 connectivity for each distinct
interface. Means to bind a DHCPv4-over-IPv6 transport
configuration to a given interface in a multiple interfaces
device are out of scope of this document.
</t>
</section>
<section title="Security Considerations">
<t>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 the access the address of
which is provisioned following this specification, and it should
not therefore bypass any security mechanisms such as IP firewalls.</t>
<t>It should be noted that DHCPv4 over IPv6 traffic may bypass
existing firewalls that are typically configured to drop
incoming outside DHCPv4 over IPv4 and DHCPv6 over IPv6 traffic.</t>
<t><xref target="RFC3315">RFC 3315</xref> discusses DHCPv6-related
security issues.</t>
<t><xref target="RFC6333"></xref> discusses DS-Lite related
security issues.</t>
</section>
<section title="IANA Considerations">
<t>IANA is kindly requested to allocate DHCPv6 option code TBD
to the OPTION_DHCP4_OVER_V6. The value should be added to the
DHCPv6 option code space defined in Section 24.3 of <xref
target="RFC3315"/>.</t>
</section>
<section title="Acknowledgements">
<t>Authors would like to thank nobody so far, as we have not received
any comments yet.</t>
<t>This work has been partially supported by the Polish Ministry
of Science and Higher Education under the European Regional Development
Fund, Grant No. POIG.01.01.02-00-045/09-00 (Future Internet Engineering
Project).</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1034"?>
<?rfc include="reference.RFC.1035"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3315"?>
<?rfc include="reference.RFC.3596"?>
<?rfc include="reference.RFC.3646"?>
<?rfc include="reference.RFC.2131"?>
<?rfc include="reference.RFC.6333"?>
<?rfc include="reference.I-D.ietf-dhc-dhcpv4-over-ipv6"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:16:44 |