One document matched: draft-ietf-mif-mpvd-dhcp-support-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc4122 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml">
<!ENTITY rfc3633 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY rfc4282 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY rfc6494 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6494.xml">
<!ENTITY rfc6495 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6495.xml">
<!ENTITY rfc6422 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6422.xml">
<!ENTITY I-D.ietf-mif-mpvd-arch PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mif-mpvd-arch-10.xml">
<!ENTITY I-D.ietf-mif-mpvd-ndp-support PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-ndp-support.xml">
<!ENTITY I-D.ietf-mif-mpvd-dhcp-support PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-dhcp-support.xml">
<!ENTITY I-D.ietf-mif-mpvd-id PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-id.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-mif-mpvd-dhcp-support-01" ipr="trust200902">
<front>
<title abbrev="DHCPv6 mPVD support">Support for multiple provisioning
domains in DHCPv6</title>
<author fullname="Suresh Krishnan" initials="S.K." surname="Krishnan">
<organization>Ericsson</organization>
<address>
<postal>
<street>8400 Decarie Blvd.</street>
<city>Town of Mount Royal</city>
<region>QC</region>
<country>Canada</country>
</postal>
<phone>+1 514 345 7900 x42871</phone>
<email>suresh.krishnan@ericsson.com</email>
</address>
</author>
<author fullname="Jouni Korhonen" initials="J.K." surname="Korhonen">
<organization abbrev="Broadcom Corporation">Broadcom Corporation</organization>
<address>
<postal>
<street>3151 Zanker Road</street>
<city>San Jose</city>
<code>95134</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author fullname="Shwetha Bhandari" initials="S.B." surname="Bhandari">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park, Sarjapura Marathalli Outer Ring
Road</street>
<city>Bangalore</city>
<region>KARNATAKA</region>
<code>560 087</code>
<country>India</country>
</postal>
<phone>+91 80 4426 0474</phone>
<email>shwethab@cisco.com</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>DHC Working Group</workgroup>
<abstract>
<t>The MIF working group is producing a solution to solve the issues
that are associated with nodes that can be attached to multiple
networks. One part of the solution requires associating configuration
information with provisioning domains. This document details how
configuration information provided through DHCPv6 can be associated with
provisioning domains.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The MIF working group is producing a solution to solve the issues
that are associated with nodes that can be attached to multiple networks
based on the Multiple Provisioning Domains (MPVD) architecture work
<xref target="I-D.ietf-mif-mpvd-arch"></xref>. One part of the
solution requires associating configuration information with
provisioning domains. This document describes a DHCPv6 mechanism for
explicitly indicating provisioning domain information along with any
configuration that will be provided. The proposed mechanism uses a
DHCPv6 option that indicates the identity of the provisioning domain and
encapsulates the options that contain the configuration information as
well as any accompanying authentication/authorization information.</t>
</section>
<section title="Terminology">
<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"></xref>.</t>
</section>
<section title="PVD Container option">
<t>The PVD container option is used to encapsulate and group together
all the configuration options that belong to the explicitly identified
provisioning domain. The PVD container option MUST encapsulate exactly
one OPTION_PVD_ID. The PVD container option MAY occur multiple times in
the same message, but each of these PVD container options MUST have a
different PVD identity specified under its PVD identity option. The PVD
container option SHOULD contain exactly one OPTION_PVD_AUTH.</t>
<figure anchor="Figure-1" title="PVD Container Option">
<artwork><![CDATA[
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_PVD | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ encapsulated-options (variable length) .
. .
+---------------------------------------------------------------+
]]></artwork>
</figure>
<figure title="">
<artwork><![CDATA[
o option-code: OPTION_PVD (TBA1)
o option-length: Length of encapsulated options
o encapsulated-options: options associated with this provisioning
domain.
]]></artwork>
</figure>
</section>
<section title="PVD Identity option">
<t>The PVD identity option is used to explicitly indicate the identity
of the provisioning domain that is associated with the configuration
information encapsulated by the PVD container option.</t>
<figure anchor="Figure-2" title="PVD ID Option">
<artwork><![CDATA[
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_PVD_ID | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PVD identity information |
+ (variable length) +
+ +
. .
+---------------------------------------------------------------+
]]></artwork>
</figure>
<figure title="">
<artwork><![CDATA[
o option-code: OPTION_PVD_ID (TBA2)
o option-length: Length of PVD identity information
o PVD identity information: The provisioning domain identity.
The contents of this field is defined in
a separate document [I-D.ietf-mif-mpvd-id].
]]></artwork>
</figure>
</section>
<section title="PVD Authentication and Authorization option">
<t>The PVD authentication and authorization option contains information
that could be used by the DHCPv6 client to verify whether the
configuration information provided was not tampered with by the DHCPv6
server as well as establishing that the DHCPv6 server was authorized to
advertise the information on behalf of the PVD per OPTION_PVD basis. The
contents of the authentication/authorization information is provided by
the owner of the provisioning domain and is completely opaque to the
DHCPv6 server that passes along the information unmodified. Every
OPTION_PVD option SHOULD contain at most one OPTION_PVD_AUTH option. The
OPTION_PVD_AUTH option MUST be the last option inside the OPTION_PVD
option.</t>
<figure anchor="Figure-3" title="PVD Auth Option">
<artwork><![CDATA[
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_PVD_AUTH | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
| name-type | key-hash : |
+-+-+-+-+-+-+-+-+ : |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth
: : info
: digital-signature : |
: : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
]]></artwork>
</figure>
<figure title="">
<artwork><![CDATA[
o option-code: OPTION_PVD_AUTH (TBA3)
o option-length: Length of the Auth info
o name-type: Names the algorithm used to identify a specific
X.509 certificate using the method defined for the Subject Key
Identifier (SKI) extension for the X.509 certificates. The
usage and the Name Type registry aligns with the mechanism
defined for SeND [RFC6494][RFC6495].
Name Type values starting
from 3 are supported and an implementation MUST at least support
SHA-1 (value 3).
o key-hash: A hash of the public key using the algorithm
identified by the Name Type. The procedure how the Key Hash is
calculated is defined in [RFC3971] and [RFC6495].
o digital-signature: A signature calculated over the encapsulating
OPTION_PVD including all option data from the beginning of the
option while setting the digital-signature field to zero. The
procedure of calculating the signature is identical to the one
defined for SeND [RFC3971].
]]></artwork>
</figure>
</section>
<section title="Set of allowable options">
<t>The PVD container option MAY be used to encapsulate any allocated
DHCPv6 options but MUST NOT be used to encapsulate another OPTION_PVD
option. [TODO: Should we add any other exclusions?]</t>
</section>
<section anchor="sec_prefix_delegation"
title="Behaviour of DHCPv6 entities">
<t>This section describes role of DHCPv6 entities involved in requesting
and receiving DHCPv6 configuration or prefix and address allocation.</t>
<section title="Client and Requesting Router Behavior" anchor="clientbehavior">
<t>DHCPv6 client or requesting router can request for configuration
from provisioning domain in the following ways:</t>
<t><list style="symbols">
<t>In the SOLICIT message it MAY include OPTION_PVD_ID requesting
configuration for the specific PVD ID indicated in the
OPTION_PVD_ID option. It can include multiple OPTION_PVD_ID
options to indicate its preference for more than one provisioning
domain. The PVD ID it requests is learnt via configuration or any
other out of band mechanism not defined in this document.</t>
<t>In the SOLICIT message include an OPTION_ORO option with the
OPTION_PVD option code to request configuration from all the PVDs
that the DHCPv6 server can provide.</t>
</list>The client or requesting router parses OPTION_PVD options in
the response message. The Client or Requesting router MUST then
include all or subset of the received OPTION_PVD options in the
REQUEST message so that it will be responsible for the configuration
information selected.</t>
<t>If DHCPv6 client or requesting router receives OPTION_PVD options
but does not support PVD, it SHOULD ignore the received option(s).</t>
</section>
<section title="Relay Agent Behavior" anchor="relaybehavior">
<t>If the relay agent supports both the Relay-Supplied DHCP Option (RSOO)
<xref target="RFC6422"/> and the PVD, and it is configured to request
configuration data for clients in one or more provisioning domains,
then the relay agent MAY include the RSOO in the Relay-Forward message.
The RSOO MAY contain zero or more OPTION_PVD options. The relay agent
MUST NOT include any OPTION_PVD options into the RSOO unless the client
has indicated support for the PVD as described in Section
<xref target="clientbehavior"/>.
</t>
</section>
<section title="Server and Delegating Router Behavior" anchor="serverbehavior">
<t>If the Server or Delegating router supports PVD and it is
configured to provide configuration data in one or more provisioning
domains, it selects configuration for the PVD based allocation in the
following way:</t>
<t><list style="symbols">
<t>If OPTION_PVD option code within OPTION_ORO is not present in
the request, it MUST NOT include provisioning domain based
configuration. It MAY select configuration and prefix allocation
from a default PVD defined.</t>
<t>If OPTION_PVD_ID is included, it selects information to be
offered from that specific PVD if available.</t>
<t>If OPTION_PVD option code within OPTION_ORO is included, then
based on its configuration and policy it MAY offer configuration
from the available PVD(s).</t>
</list>When PVD information and configuration are selected for
address and prefix allocation the server or delegating router responds
with an ADVERTISE message after populating OPTION_PVD.</t>
<t>If OPTION_PVD is not included, then the server or delegating router
MAY allocate the prefix and provide configuration as specified in
<xref target="RFC3315"></xref> and<xref target="RFC3633"></xref> and
MUST NOT include OPTION_PVD option in the response.</t>
<t>If OPTION_ORO option includes the OPTION_PVD option code but the
server or delegating router does not support PVD, then it SHOULD
ignore the OPTION_PVD and OPTION_PVD_ID options received.</t>
<t>If both client/requesting router and server/delegating router
support PVD but cannot offer configuration with PVD for any other
reason, it MUST respond to client/requesting router with appropriate
status code as specified in <xref target="RFC3315"></xref> <xref
target="RFC3633">and</xref>.</t>
<t>Similarly, if the OPTION_PVD is received in the RSOO from the
relay agent the above described procedures apply for including the
PVD specific configuration information back to the client.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>An attacker may attempt to modify the information provided inside the
PVD container option. These attacks can easily be prevented by using the
DHCPv6 AUTH option <xref target="RFC3315"></xref> that would detect any
form of tampering with the DHCPv6 message contents.</t>
<t>A compromised DHCPv6 server or relay agent may insert configuration
information related to PVDs it is not authorized to advertise. e.g. A
coffee shop DHCPv6 server may provide configuration information
purporting to be from an enterprise and may try to attract enterprise
related traffic. The only real way to avoid this is that the PVD
container contains embedded authentication and authorization information
from the owner of the PVD. Then, this attack can be detected by the
client by verifying the authentication and authorization information
provided inside the PVD container option after verifying its trust
towards the PVD owner (e.g. a certificate with a well-known/common trust
anchor).</t>
<t>A compromised configuration source or an on-link attacker may try to
capture advertised configuration information and replay it on a
different link or at a future point in time. This can be avoided by
including some replay protection mechanism such as a timestamp or a
nonce inside the PVD container to ensure freshness of the provided
information.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document defines three new DHCPv6 options to be allocated out of
the registry at http://www.iana.org/assignments/dhcpv6-parameters/</t>
<figure>
<artwork><![CDATA[
OPTION_PVD (TBA1)
OPTION_PVD_ID (TBA2)
OPTION_PVD_AUTH (TBA3)
]]></artwork>
</figure>
<t>This document also adds OPTION_PVD (TBA1) into the "Options Permitted
in the Relay-Supplied Options Option" registry at
http://www.iana.org/assignments/dhcpv6-parameters/
</t>
</section>
<section anchor="acks" title="Acknowledgements">
<t>The authors would like to thank the members of the MIF architecture
design team for their comments that led to the creation of this
draft. The authors would also thank Ian Farrer for his reviews and
comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3315;
&rfc3633;
&rfc4122;
&rfc4282;
&rfc6494;
&rfc6495;
&rfc6422;
</references>
<references title="Informative References">
&I-D.ietf-mif-mpvd-arch;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:25:16 |