One document matched: draft-ietf-softwire-map-dhcp-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ietf-softwire-map-dhcp-03"
ipr="trust200902">
<front>
<title abbrev="MAP DHCPv6 Options">DHCPv6 Options for Mapping of Address
and Port</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>
<uri>http://www.isc.org/</uri>
</address>
</author>
<!-- Med and Xiaohong requested to be removed from the authors list
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@gmail.com</email>
<uri>http://www.francetelecom.com/</uri>
</address>
</author>-->
<author fullname="Ole Troan" initials="O" surname="Troan">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Telemarksvingen 20</street>
<city>Oslo</city>
<code>N-0655</code>
<country>Norway</country>
</postal>
<email>ot@cisco.com</email>
<uri>http://cisco.com</uri>
</address>
</author>
<author fullname="Wojciech Dec" initials="W" surname="Dec">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>The Netherlands</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>wdec@cisco.com</email>
<uri>http://cisco.com</uri>
</address>
</author>
<author fullname="Congxiao Bao" initials="C.X." surname="Bao">
<organization abbrev="Tsinghua University">CERNET Center/Tsinghua
University</organization>
<address>
<postal>
<street>Room 225, Main Building, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>CN</country>
</postal>
<phone>+86 10-62785983</phone>
<email>congxiao@cernet.edu.cn</email>
</address>
</author>
<author fullname="Leaf Y. Yeh" initials="L." surname="Yeh">
<organization>Freelancer Technologies</organization>
<address>
<postal>
<street></street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code></code>
<country>P. R. China</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>leaf.yeh.sdo@gmail.com</email>
<uri></uri>
</address>
</author>
<author fullname="Xiaohong Deng" initials="X." surname="Deng">
<!-- <organization></organization> -->
<address>
<postal>
<street>6 Cordelia St.</street>
<code>QLD 4101</code>
<city>South Brisbane</city>
<country>Australia</country>
</postal>
<phone>+61 3858 3128</phone>
<email>dxhbupt@gmail.com</email>
</address>
</author>
<!-- Qiong Sun requested joining author team as well (22.10.2011 12:10) -->
<date />
<area>Internet</area>
<workgroup>Softwire WG</workgroup>
<keyword>MAP</keyword>
<keyword>DHCPv6</keyword>
<!-- SECTION 0: Abstract -->
<abstract>
<t>This document specifies DHCPv6 options for the provisioning of
Mapping of Address and Port (MAP) Customer Edge (CE) devices, based on
the MAP paramaters defined in <xref
target="I-D.ietf-softwire-map"></xref>.</t>
<t></t>
</abstract>
</front>
<middle>
<!-- SECTION 1: Introduction -->
<section title="Introduction">
<t>Mapping of Address and Port (MAP) defined in <xref
target="I-D.ietf-softwire-map"></xref> is a mechanism for providing IPv4
connectivity service to end users over a service provider's IPv6
network, allowing for shared or dedicated IPv4 addressing. It consists
of a set of one or more MAP Border Relay (BR) routers, responsible for
stateless forwarding, and one or more MAP Customer Edge (CE) routers,
that collectively form a MAP Domain when configured with common MAP
rule-sets. In a residential broadband deployment the CE is sometimes
referred to as a Residential Gateway (RG) or Customer Premises Equipment
(CPE).</t>
<t>A typical MAP CE will serve its end-user with one WAN side interface
connected to an operator domain providing a MAP service. To function in
the MAP domain, the CE requires to be provisioned with the appropriate
MAP service paramaters for that domain. Particularly in larger networks
it is not feasible to configure such parameters manually, which forms
the requirement for a dynamic MAP provisioning mechanism that is defined
in this document based on the existing DHCPv6 <xref
target="RFC3315"></xref> protocol. The configuration of the MAP BR is
outside of scope of this document.</t>
<t>This document specifies the DHCPv6 options that allow MAP CE
provisioning, based on the definitions of parameters provided in <xref
target="I-D.ietf-softwire-map"></xref>, and is applicable to both MAP-E
and MAP-T transport variants. The definition of DHCPv6 options for MAP
CE provisioning does not preclude the definition of other dynamic
methods for configuring MAP devices, or supplementing such
configuration, nor is the use of DHCPv6 provisioning mandatory for MAP
operation.</t>
<t>Since specification of MAP architecture is still expected to evolve,
DHCPv6 options may have to evolve too to fit the revised MAP
specification.</t>
<t>Defined proposal is not a dynamic port allocation mechanism.</t>
<t>Readers interested in deployment considerations are encouraged to
read <xref target="I-D.mdt-softwire-map-deployment"></xref>.</t>
</section>
<!-- SECTION 2: REQUIREMENTS LANGUAGE -->
<section anchor="conventions" title="Conventions">
<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 RFC 2119 <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="description" title="MAP Information">
<t>The following presents the information parameters that are used to
configure a MAP CE:</t>
<t><list style="symbols">
<t>A Default Mapping Rule (DMR). This rule governs the default
forwarding/mapping behaviour of the MAP CE, ie it informs the CE of
the BR router's address or prefix that is typically used as a
default. The DMR is a mandatory parameter for a MAP CE.</t>
<t>A Basic Mapping Rule (BMR). This rule governs the MAP
configuration of the CE, including that of completing the CE's MAP
IPv6 address, as well as deriving the CEs IPv4 parameters. Key
parameters of a BMR include: i) The IPv4 Prefix - Used to derive the
CE's IPv4 address; ii) The Embedded Address bit length - Used to
derive how many, if any, of the CE's IPv6 address is mapped to the
IPv4 address. iii) The IPv6 prefix - used to determine the CE's IPv6
MAP domain prefix that is to form the base for the CE's MAP address.
The BMR is an optional rule for a MAP CE.</t>
<t>A Forward Mapping Rule (FMR). This rule governs the MAP CE-CE
forwarding behaviour for IPv4 destinations covered by the rule. The
FMR is effectively a special type of an BMR, given that it shares
exactly the same configuration parameters, except that these
parameters are only applied for setting up forwarding. Its presence
enables a given CE to communicate directly in "mesh mode" with other
CEs. The FMR is an optional rule, and the absence of such a rule
indicates that the CE is to simply use its default mapping rule for
all destinations.</t>
<t>Transport mode; encapsulation (MAP-E, <xref
target="I-D.ietf-softwire-map"/>) or translation (MAP-T, <xref
target="I-D.ietf-softwire-map-t"/>) modes to be used for the MAP CE
Domain.</t>
<t>Additional parameters. The MAP specification allows great
flexibility in the level of automation a CE uses to derive its IPv4
address and port-sharing (PSID), ranging from full derivation of
these parameters from the CE's IPv6 prefix, to full parametrization
of MAP configuration independent of the CE's IPv6 prefix. Optional
parameters such as the PSID allow this flexibility.</t>
</list></t>
<!--
<t>Discussion: Qiong Sun also proposed to add deployment mode
here. Jacni Qin recommends against it. Deployment mode is to
notify whether CE is in Hub and spoke mode or mesh. In Hub and
spoke mode, only the first default MAP mapping rule is needed
in the following MAP procedure. While in mesh mode, all MAP
mapping rules are included to achieve CE-CE traffic
optimization. Tomek: I believe that hub and spoke or mesh
affects number of rules, so server will provision one (hub and
spoke) or many (mesh) rules. CE does not need to explicitly be
information about this. It can derive this information in a
simple manner: if (number of rules>1) then mode=mesh else
mode=hub_and_spoke.</t> -->
<!-- Tomek: Discussion resolved: see additional comment in "MAP
Container Option" section. Algo for detecting mode: In th hub
and spoke mode, all traffic should be forwarded using
DMR. Hub and spoke mode is achieved with a BMR IPv4 rule
prefix length of 32 and no further FMR. -->
</section>
<!-- conventions -->
<!-- SECTION 3: DESCRIPTION -->
<section title="DHCPv6 MAP Options">
<t>The DHCPv6 protocol is used for MAP CE provisioning following regular
DHCPv6 notions, with the MAP CE assuming a DHCPv6 client role, and the
MAP parameters provided by the DHCPv6 server following typical DHCPv6
server side policies. The format and usage of the MAP options is defined
in the following sections.</t>
<t>Discussion: As the exact parameters required to configure MAP rules
and MAP in general are expected to change, this section is expected to
be updated and follow changes in the <xref
target="I-D.ietf-softwire-map"></xref>.</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. </t> -->
<t>Discussion: It should be noted that initial concept of 4rd/MAP
provisioning was presented in DHC working group meeting. It used one
complex option to convey all required parameters. Strong suggestion from
DHC WG was to use several simpler options. Options (possibly nested) are
preferred over conditional option formatting. See DHCP option guidelines
document <xref target="I-D.ietf-dhc-option-guidelines"></xref>).</t>
<t>Server that supports MAP configuration and is configured to provision
requesting CE MUST include exactly one OPTION_MAP option in a REPLY
message for each MAP domain. It is envisaged that in typical network,
there will be only one MAP domain deployed.</t>
<section anchor="what-where" title="MAP Options Cardinality">
<t>Server configured to provision MAP configuration SHOULD return one
MAP Container Option for each MAP domain, when requested by clients.
As there will typically be only one MAP Domain configured, server will
typically return a single instance of MAP Container Option.</t>
<t>Returned MAP Container Option MUST include exactly one MAP DMR Rule
option. It also MAY include zero or more MAP Rule Options. It also MAY
include MAP Port Parameters option. It MAY include additional options
that may be defined in the future.</t>
</section>
<section anchor="option-map" title="MAP Container Option">
<t>This MAP Container Option specifies the container used to group all
rules and optional port parameters for a specified MAP domain.</t>
<figure align="center" anchor="img-map-option"
title="MAP Container Option">
<preamble></preamble>
<artwork align="center"><![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_MAP | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | .
+-+-+-+-+-+-+-+-+ encapsulated-options (variable length) .
. .
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t><list style="symbols">
<t>option-code: OPTION_MAP (TBD1)</t>
<t>option-length: 1 + Length of encapsulated options</t>
<t>flags: This 8-bits long conveys the MAP Flags that apply to all
encapsulated options. The meaning of specific bits is explained in
<xref target="img-map-option-flag"></xref>.</t>
<t>encapsulated-options: options associatied with this MAP
domain.</t>
</list></t>
<t>The encapsulated options field encapsulates those options that are
specific to this MAP Option. Currently there are three options that
MAY appear here: OPTION_MAP_RULE, OPTION_MAP_DMR and
OPTION_MAP_PORTPARAMS. Other options suitable for a MAP domain may be
defined in the future. A DHCP message MAY include multiple MAP
Container Options (representing multiple MAP domains), but typically
it will have only one.</t>
<t>The Format of the MAP flags field is:</t>
<t><figure align="center" anchor="img-map-option-flag"
title="MAP Option Flags">
<preamble></preamble>
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |T|
+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure><list style="symbols">
<t>Reserved: 7-bits reserved for future use.</t>
<t>T: 1 bit field that specifies transport mode to use:
translation (0) or encapsulation (1).</t>
</list></t>
<t>Discussion: It was suggested to also provision information whether
MAP network is working in hub and spoke or mesh mode. That is not
necessary, as mesh mode is assumed when there is at least one FMR
present.</t>
</section>
<section title="MAP Rule Option">
<t>Figure <xref target="img-option-rule"></xref> shows the format of
the MAP Rule option used for conveying the BMR and FMR.</t>
<t>Server includes zero or more MAP Rule Options in MAP Container
Option.</t>
<t>Server MAY send more than one MAP Rule Option, if it is configured
to do so. Clients MUST NOT send MAP Rule Option.</t>
<figure align="center" anchor="img-option-rule"
title="MAP Rule Option">
<preamble></preamble>
<artwork align="center"><![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_MAP_RULE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix4-len | rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (continued) | ea-len | rule-flags | prefix6-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv6-prefix |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. encapsulated-options (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="symbols">
<t>option-code: OPTION_MAP_RULE (TBD2)</t>
<t>option-length: length of the option, excluding option-code and
option-length fields, including length of all encapsulated
options, expressed in bytes.</t>
<t>prefix4-len: 8 bits long field expressing the bit mask length
of the IPv4 prefix specified in the rule-ipv4-prefix field.</t>
<!-- tomek todo: Do we want to restrict values to 0-32 here? -->
<t>rule-ipv4-prefix: a fixed length 32 bit field that specifies
the IPv4 prefix for the MAP rule.</t>
<t>ea-len: 8 bits long field that specifies the Embedded-Address
(EA) bit length. Values allowed range from 0 to 48.</t>
<t>rule-flags: 8 bits long field carrying flags applicable to the
rule. The meaning of specific bits is explained in <xref
target="img-rule-flags"></xref>.</t>
<t>prefix6-len: 8 bits long field expressing the bit mask length
of the IPv6 prefix specified in the rule-ipv6-prefix field.</t>
<t>rule-ipv6-prefix: a variable length field that specifies the
IPv6 domain prefix for the MAP rule. The field is padded with
follow up zero bits up to the nearest octet boundary when
prefix6-len is not divisible by 8.</t>
<t>encapsulated options: a variable field that may contain zero or
more options that specify additional parameters for this MAP
BMR/FMR rule. Currently there are no such options defined, but
they may be defined in the future.</t>
</list></t>
<t>The value of the EA-len and prefix4-len SHOULD be equal to or
greater than 32.</t>
<t>The Format of the MAP Rule Flags field is:<figure align="center"
anchor="img-rule-flags" title="MAP Rule Flags">
<preamble></preamble>
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |F|
+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t><list style="symbols">
<t>Reserved: 7-bits reserved for future use as flags.</t>
<t>F-Flag: 1 bit field that specifies whether the rule is to be
used for forwarding (FMR). 0x0 = This rule is NOT used as a FMR.
0x1 = This rule is also a FMR.</t>
<t>Note: BMR rules can be also FMR rules by setting the F flag.
BMR rules are determined by a match of the Rule-IPv6-prefix
against the CPE's prefix(es).</t>
</list></t>
<t>It is expected that in a typical MAP deployment scenarios, there
will be a single DMR and a single BMR, which could also be designated
as an FMR using the F-Flag.</t>
<t>Discussion: This option format attempts to use option formats
recommended by <xref target="I-D.ietf-dhc-option-guidelines"></xref>,
namely variable length prefix formats. It should be noted that this
format follows prefix length + prefix notation. Reasons for using
variable IPv6 prefix field, but fixed IPv4 prefix are given in <xref
target="I-D.ietf-dhc-option-guidelines"></xref>, Section 5.9.</t>
</section>
<section title="MAP DMR Option">
<t>MAP DMR Option is used to convey values for Default Mapping Rule.
MAP DMR Option MUST appear in each MAP Container Option exactly once.
It MUST NOT appear in the DHCP message directly. Figure <xref
target="img-option-dmr"></xref> shows the format of the MAP Rule
option used for conveying a DMR.</t>
<t><figure align="center" anchor="img-option-dmr"
title="MAP DMR Option">
<preamble></preamble>
<artwork align="center"><![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_MAP_DMR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dmr-prefix6-len| dmr-ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. encapsulated-options (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list style="symbols">
<t>option-code: OPTION_MAP_DMR (TBD3)</t>
<t>option-length: 1 + length of dmr-ipv6-prefix + encapsulated
options, specified in bytes.</t>
<t>dmr-prefix6-len: 8 bits long field expressing the bit mask
length of the IPv6 prefix specified in the dmr-ipv6-prefix
field.</t>
<t>dmr-ipv6-prefix: a variable length field that specifies the
IPv6 prefix or address for the MAP BR. This field is padded with
follow up zeros to the nearest octet boundary when dmr-prefix6-len
is not divisible by 8.</t>
<t>encapsulated options: nested options associatied to this MAP
DMR option. Currently there are no such options defined, but they
may be defined in the future.</t>
</list></t>
</section>
<section anchor="option-portparams" title="MAP Port Parameters Option">
<t>Port Parameters Option specifies optional Rule Port Parameters that
MAY be provided as part of the Mapping Rule. It MAY appear as
encapsulated option in OPTION_MAP option. It MUST NOT appear directly
in a message. It MUST NOT appear in OPTION_MAP_RULE nor OPTION_MAP_DMR
options.</t>
<t>See <xref target="I-D.ietf-softwire-map"></xref>, Section 5.1 for
detailed description of MAP algorithm that explains meaning of all
parameters.</t>
<figure align="center" anchor="img-option-portparams"
title="MAP Port Parameters Option">
<preamble></preamble>
<artwork align="center"><![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_MAP_PORTPARAMS | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset | PSID-len | PSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><list style="symbols">
<t>option-code: OPTION_MAP_PORTPARAMS (TBD4)</t>
<t>option-length: 4</t>
<t>offset: (PSID offset) 8 bits long field that specifies the
numeric value for the MAP algorithm's excluded port range/offset
bits (A-bits), as per section 5.1.1 in <xref
target="I-D.ietf-softwire-map"></xref>. Allowed values are between
0 and 16, with the default value being 4.</t>
<t>PSID-len: Bit length value of the number of significant bits in
the PSID field. (also known as 'k'). When set to 0, the PSID field
is to be ignored. After the first 'a' bits, there are k bits in
the port number representing valid of PSID. Subsequently, the
address sharing ratio would be 2^k.</t>
<t>PSID: Explicit 16-bit (unsigned word) PSID value. The PSID
value algorithmically identifies a set of ports assigned to a CE.
The first k-bits on the left of this 2-octets field is the PSID
value. The remaining (16-k) bits on the right are padding
zeros.</t>
</list></t>
<t>When receiveing the Port Parameters option with an explicit PSID,
the client MUST use this explicit PSID in configuring its MAP
interface.</t>
</section>
</section>
<section title="DHCPv6 Server Behavior">
<t><xref target="RFC3315">RFC 3315 Section 17.2.2</xref> describes how a
DHCPv6 client and server negotiate configuration values using the ORO.
As a convenience to the reader, we mention here that a server will by
default not reply with a MAP Rule Option if the client has not
explicitly enumerated it on its Option Request Option.</t>
<t>A Server following this specification MUST allow the configuration of
one or more MAP Rule Options, exactly one DMR Option and optional Port
Parameters Option and SHOULD send such options grouped under a single
MAP Container Option.</t>
<t>Server MUST include a MAP Container Option (which encapsulates all
MAP Rule, MAP DMR, and MAP Port parameters Options) in its responses if
client requested it using OPTION_MAP in client's Option Request Option
(ORO).</t>
<t>Server MAY include more than one MAP Container Options only in the
unlikely case of having more than one MAP Domain configured.</t>
<!-- sadly, with introduction of OPTION_PORTPARAMS that is no longer true.
<t>Rules assignment is a stateless process from the server's
perspective. Server does not need to maintain a state of rules
provisioned to clients, track lifetimes, expire outdated rules
etc. Server SHOULDs assign the same set of rules to all CEs in
one MAP Domain, unless there are several classes of CEs defined,
e.g. regular and premium users. In such case, each class of CEs
is expected to get the same set of rules. Server is not expected
to track MAP rules on a per CE basis. Exact assignment of
specific rules to a specific CEs is outside of scope of this
document.</t> -->
<t>The server SHOULD be capable of following per client assignment rules
when assigning MAP options.</t>
</section>
<section title="DHCPv6 Client Behavior">
<t>A MAP CE acting as DHCPv6 client will request MAP configuration to be
assigned by the DHCPv6 server located in the ISP network. A client
supporting MAP functionality SHOULD request OPTION_MAP option in its ORO
in SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages.</t>
<t>When processing received MAP options the following behaviour is
expected:<list style="symbols">
<t>A client MUST support processing multiple received
OPTION_MAP_RULE options in a OPTION_MAP option</t>
<t>A client receiving an unsupported MAP option, or an unrecognized
parameter value SHOULD discard the entire OPTION_MAP.</t>
<t>Exactly one OPTION_MAP_DMR is allowed per OPTION_MAP option.
Client MUST ignore entire OPTION_MAP if there is zero or more than
one MAP DMR Option.</t>
</list></t>
<t>The client MUST be capable of applying the received MAP option
parameters for the configuration of the local MAP instance.</t>
<t>Note that system implementing MAP CE functionality may have multiple
network interfaces, and these interfaces may be configured differently;
some may be connected to networks that call for MAP, and some may be
connected to networks that are using normal dual stack or other means.
The MAP 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 MAP Mapping Rule Option, then the
CE system MUST configure a MAP connection (i.e. a translation or
encapsulation) for each interface separately as each MAP provides IPv4
connectivity for each distinct interface. Means to bind a MAP
configuration to a given interface in a multiple interfaces device are
out of scope of this document.</t>
</section>
<section title="Usage of flags and paramaters">
<t>The defined MAP options contain a number of flags and parameters that
are intended to provide full flexibility in the configuration of a MAP
CE. Some usage examples are:</t>
<t><list style="symbols">
<t>A MAP CE receiving an OPTION_MAP option with the T flag set to 1
will assume a MAP-E (encapsulation) mode of operation for the domain
and all associated rules. Conversely, when the received option has
the T flag set to 0, the CE will assume a MAP-T (stateless NAT46
translation) mode of operation.</t>
<t>The presence of a OPTION_MAP_RULE option, along with IPv4 prefix
parameters, indicates to the MAP CE that NAPT44 mode of operation is
expected, following the address mapping rules defined in <xref
target="I-D.ietf-softwire-map"></xref>. Conversely, the absence of
an OPTION_MAP_RULE option indicates that NAT44 mode is not required,
and that the MAP CE is to plainly encapsulate (MAP-E mode) or
statelessly translate using NAT64 (MAP-T mode) any IPv4 traffic sent
following the DMR.</t>
<t>The MAP domain ipv6-prefix in the BMR should correspond to a
service prefix assigned to the CPE by the operator, with the latter
being assigned using regular IPv6 means, e.g. DHCP PD <xref
target="RFC3633"></xref> or SLAAC. This parameter allows the CPE to
select the prefix for MAP operation.</t>
<t>The EA_LEN parameter, along with the length of the IPv4 prefix in
the BMR option, allows the MAP CE to determine whether address
sharing is in effect, and what is the address sharing ratio. Eg: A
prefix4-len of 16 bits, and EA-len of 18 combines to a 32 bit IPv4
address with a sharing ratio of 4.</t>
<t>The use of the F(orward) flag in the BMR allows a CE to apply a
received BMR as an FMR, thereby enabling mesh-mode for the domain
covered by the BMR rule.</t>
<t>In the absence of a BMR, the presence of the mandatory DMR
indicates to the CPE the address or prefix of a BR, and makes the
MAP CE fully compatible with DS-Lite and stateful or stateless NAT64
core nodes. Eg a MAP CE configured in MAP-E mode, with just a DMR
and a BR IPv6 address equivalent to that of the AFTR, effectively
acts as a DS-Lite B4 element. For more discussion about MAP
deployment considerations, see <xref
target="I-D.mdt-softwire-map-deployment"></xref>.</t>
</list></t>
</section>
<section title="Deployment considerations">
<t>Usage of PSID Option should be avoided if possible and PSID embedded
in the delegated prefix should be used instead. This allows MAP
deployment to not introduce any additional state in DHCP server. Port
Parameters Option must be assigned on a per CE basis, thus requiring
more complicated server configuration.</t>
<t>In a typical environment, there will be only one MAP domain, so
server will provide only a single instance of MAP Container Option that
acts a container for MAP Rules and other options that are specific to
that MAP domain.</t>
<t>In case of multiple provisioning domains, as defined in <xref
target="I-D.ietf-homenet-arch"></xref>, one server may be required to
provide information about more than one MAP domain. In such case it is
envisaged that the server will provide two or more instances of MAP
Container Options, each with its own set of encapsulated options that
define MAP rules for each specific MAP domain. Details of mulitple
provisioning domains are discussed in Section 4.1 of <xref
target="I-D.mdt-softwire-map-deployment"></xref>. Such a deployment is
outside of scope for this document.</t>
</section>
<section title="IANA Considerations">
<t>IANA is kindly requested to allocate the following DHCPv6 option
codes: TBD1 for OPTION_MAP, TBD2 for OPTION_MAP_RULE, TBD3 for
OPTION_MAP_DMR, and TBD4 for OPTION_MAP_PORTPARAMS. All values should be
added to the DHCPv6 option code space defined in Section 24.3 of <xref
target="RFC3315"></xref>.</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 over the MAP can be trusted, and it should not therefore bypass
any security mechanisms such as IP firewalls.</t>
<t>Readers concerned with security of MAP provisioning over DHCPv6 are
encouraged to read <xref
target="I-D.ietf-dhc-secure-dhcpv6"></xref>.</t>
<t>Section XX of <xref target="I-D.ietf-softwire-map"></xref> discusses
security issues of the MAP mechanism.</t>
<t>Section 23 of <xref target="RFC3315"></xref> discusses DHCPv6-related
security issues.</t>
</section>
<section title="Acknowledgements">
<t>This document was created as a product of a MAP design team.
Following people were members of that team: Congxiao Bao, Mohamed
Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni
Korhonen, Xing Li, Satoru Matsushima, Tomasz Mrugalski, Tetsuya
Murakami, Jacni Qin, Necj Scoberne, Qiong Sun, Tina Tsou, Dan Wing, Leaf
Yeh and Jan Zorz.</t>
<t>Former MAP design team members are: Remi Despres.</t>
<t>Authors would like to thank Bernie Volz for his insightful comments
and suggestions.</t>
<t>This work draws ideas from previous drafts:
<xref target="I-D.boucadair-dhcpv6-shared-address-option"/>,
<xref target="I-D.mrugalski-dhc-dhcpv6-4rd"/>,
<xref target="I-D.murakami-softwire-4rd"/> and others.</t>
</section>
</middle>
<back>
<!-- SECTION 8.1: Normative References -->
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-map.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119" ?>
</references>
<!-- SECTION 8.2: Informative References -->
<references title="Informative References">
<!-- MAP-T is experimental, it must not be put as normative reference -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-map-t.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mdt-softwire-map-deployment.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-homenet-arch"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-option-guidelines.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrugalski-dhc-dhcpv6-4rd.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boucadair-dhcpv6-shared-address-option.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-secure-dhcpv6.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.murakami-softwire-4rd.xml" ?>
</references>
<section anchor="example" title="MAP Options Examples">
<t>DHCPv6 server provisioning a single MAP Rule to a CE (DHCPv6 client) will
convey the following MAP options in its messages:</t>
<section title="Example 1: BMR Option">
<!-- contributed by Xiaohong -->
<t>
Given the MAP domain information and an IPv6 address of an endpoint:
</t>
<t>
<list style="symbols">
<t>
IPv6 prefix assigned to the end user: 2001:db8:0012:3400::/56
</t>
<t>
Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix),
192.0.2.0/24 (Rule IPv4 prefix), 16 (Rule EA-bits length)}
<!-- Sharing ratio: 256 (16 - (32 - 24) = 8. 2^8 = 256) -->
</t>
<t>
PSID offset: 4
</t>
</list>
</t>
<t>This configuration example includes one MAP Container Option
(OPTION_MAP) that has two nested options: one MAP Rule Option
(OPTION_MAP_RULE) and one MAP Port Parameters Option
(OPTION_MAP_PORTPARAMS).</t>
<figure align="center" anchor="img-bmr-example"
title="BMR Option Example">
<preamble></preamble>
<artwork align="center"><![CDATA[
OPTION_MAP=TBD1
option-length=26 # (i.e. 1(OPTION_MAP) + suboptions: 17
# (OPTION_MAP_RULE) and 8 (OPTION_MAP_PORT_PARAMS)
flags=0x01 # encapsulation
encapsulated-options: 2 options specified below
OPTION_MAP_RULE=TBD2
option-length=17
prefix4-len=24
rule-ipv4-prefix=192.0.2.0 # rules-ipv4-prefix length is always
# 4 bytes
ea-len=16
rule-flags=0x01 # BMR and FMR
prefix6-length=40 # prefix-length implies rule-ipv6-
# prefix is a 5 bytes(40bits)
rule-ipv6-prefix=2001:db8:0000:: # long field.
encapsulated-options: none # no nested options in MAP_RULE
OPTION_MAP_PORTPARAMS=TBD4
option-length=4
offset=4
PSID-len=8
PSID=52]]></artwork>
</figure>
</section>
<section title="Example 2: DMR Option">
<!-- contributed by Xiaohong -->
<t>
<!-- it used to be 1.2.3.4 IPv4 address. Changed to 203.0.113.1 as
203.0.113.0/24 is a TEST-NET-3, as specified in RFC5735 -->
An IPv4 host behind the MAP CE (addressed as per the previous examples)
corresponding with IPv4 host 203.0.113.1 will have its packets converted
into IPv6 using the DMR configured on the MAP CE as follows:
</t>
<t>
<list style="symbols">
<t>
Default Mapping Rule: {2001:db8:ffff::1/128
(Rule IPv6 prefix), 0.0.0.0/0 (Rule IPv4 prefix), null (BR IPv4
address)}
</t>
</list>
</t>
<t>
This configuration example uses one MAP Container Option (OPTION_MAP)
with a single MAP DMR Option (OPTION_MAP_DMR) in it.
</t>
<figure align="center" anchor="img-dmr-example"
title="DMR Option Examples">
<preamble></preamble>
<artwork align="center"><![CDATA[
OPTION_MAP=TBD1
option-length=22 # 1 + nested option (MAP_DMR, 21 bytes)
flags=0x01 # encapsulation
encapsulated-options=one MAP_DMR option specified below
OPTION_MAP_DMR=TDB3
option-length=17
dmr-prefix6-len=128 #dmr-ipv6-prefix is 16bytes(128 bits) long
dmr-ipv6-prefix=2001:db8:ffff::1
encapsulated-options: none]]></artwork>
</figure>
</section>
<section title="Example 3: 1:1 Rule with No Address Sharing">
<!-- contributed by Congxiao -->
<t>
Given the MAP domain information and an IPv6 address of an endpoint:
</t>
<t>
<list style="symbols">
<t>
IPv6 prefix assigned to the end user: 2001:db8:0012:3400::/56
</t>
<t>
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.1/32 (Rule IPv4 prefix), 0 (Rule EA-bits length)}
<!-- Sharing ratio: 1 -->
</t>
<t>
PSID offset: n/a
</t>
</list>
</t>
<t>
This configuration uses one MAP Container Option (OPTION_MAP)
that includes one nested MAP Rule Option (OPTION_MAP_RULE).
</t>
<figure align="center" anchor="img-11-nosharing-example"
title="1:1 Rule with No Address Sharing Examples">
<preamble></preamble>
<artwork align="center"><![CDATA[
OPTION_MAP=TBD1
option-length=20 # 1 for OPTION_MAP and 19 for (OPTION_MAP_RULE)
flags=0x00 # just for BMR, not for FMR
encapsulated-options: one MAP Rule option, specified below
OPTION_MAP_RULE=TBD2
option-length=15
prefix4-len=32
rule-ipv4-prefix=192.0.2.1
ea-len=0
rule-flags=0x00 # for BMR only
prefix6-length=56 # length of the rule-ipv6-prefix
# is 7 bytes (56bits)
rule-ipv6-prefix=2001:db8:0012:3400::
encapsulated-options: none
]]></artwork>
</figure>
</section>
<section title="Example 4: 1:1 Rule with Address Sharing">
<t>
Given the MAP domain information and an IPv6 address of an endpoint:
</t>
<t>
<list style="symbols">
<t>
IPv6 prefix assigned to the end user: 2001:db8:0012:3400::/56
</t>
<t>
Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
192.0.2.1/32 (Rule IPv4 prefix), 0 (Rule EA-bits length)
PSID-len 8, PSID 11 }
<!-- Sharing ratio: 256 (16 - (32 - 24) = 8. 2^8 = 256) -->
</t>
<t>
PSID offset: 4
</t>
</list>
</t>
<t>
This configuration example features one MAP Container Option (OPTION_MAP)
that includes two nested options: one MAP Rule Option (OPTION_MAP_RULE)
and one MAP Port Parameters Option (OPTION_MAP_PORTPARAMS).
</t>
<figure align="center" anchor="img-11-sharing-example"
title="1:1 Rule with no Address Sharing Examples">
<preamble></preamble>
<artwork align="center"><![CDATA[
OPTION_MAP=TBD1
option-length=28
flags=0x01
encapsulated-options: includes two options specified below
OPTION_MAP_RULE=TBD2
option-length=15
rule-ipv4-prefix=192.0.2.1
rule-flags=0x00 # for BMR only
ea-len=0
prefix4-len=32
prefix6-length=56 # rule-ipv6-prefix length is 7 bytes(56 bits)
rule-ipv6-prefix=2001:db8:0012:3400::
encapsulated-options: none
OPTION_MAP_PORTPARAMS=TDB4
option-length=4
offset=4
PSID-len=8
PSID=11]]></artwork>
</figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:46 |