One document matched: draft-mdt-softwire-map-dhcp-option-02.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-mdt-softwire-map-dhcp-option-02"
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" role="editor">
<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://isc.org/</uri>
</address>
</author>
<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 initials="X." surname="Deng" fullname="Xiaohong Deng">
<organization>France Telecom</organization>
<address>
<postal>
<street>Haidian district</street>
<code>100190</code>
<city>Beijing</city>
<country>China</country>
</postal>
<email>xiaohong.deng@orange.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 initials="C.X." surname="Bao" fullname="Congxiao 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>
<!-- Qiong Sun requested joining author team as well (22.10.2011 12:10) -->
<date day="24" month="January" year="2012" />
<area>Internet</area>
<workgroup>Softwire WG</workgroup>
<keyword>MAP</keyword>
<keyword>DHCPv6</keyword>
<!-- SECTION 0: Abstract -->
<abstract>
<t>Generic mechanism for mapping between an IPv4 prefix, address
or parts of thereof, and transport layer ports and an
IPv6 prefix or address is specified in <xref
target="I-D.mdt-softwire-mapping-address-and-port"/>. This is a companion document that
specifies provisioning mechanism of MAP rules. It defines DHCPv6
options which are meant to be used between Customer Edge (CE)
devices and DHCPv6 server to obtain necessary parameters to
configure MAP rules. 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></t>
</abstract>
</front>
<middle>
<!-- SECTION 1: Introduction -->
<section title="Introduction">
<t>Mapping of Address and Port (MAP) defined in <xref
target="I-D.mdt-softwire-mapping-address-and-port" /> is a mechanism for providing
IPv4 connectivity service to end users over a service provider's
IPv6 network. It defines both MAP Border Relay (BR) router that is located at the edge
of a MAP domain and MAP Customer Edge (CE) that typically deployed at
customers' location. In a residential broadband deployment, CE
is sometimes referred to as a Residential Gateway (RG) or
Customer Premises Equipment (CPE). A MAP CE may also be referred
to simply as a "CE" within the context of MAP.</t>
<t>A typical CE adopting MAP rules will serve a residential
site with one WAN side interface and one or more LAN side
interfaces. To operate properly, it requires one or more MAP
rules and additional informations. In larger networks it is
infeasible to configure such parameters manually. Therefore
provisioning mechanism is required. Such mechanism is defined in
this document. It leverages existing DHCPv6 <xref
target="RFC3315"/> protocol to deliver necessary parameters to
CE.</t>
<t>This document defines several DHCPv6 options that allow
delivery of required information to configure CE. Configuration
of the BR is outside of scope of this document. Definitions of
used parameters are provided in <xref target="I-D.mdt-softwire-mapping-address-and-port" />.</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>Described proposal is not a dynamic port allocation mechanism.
</t>
<t>Reader interested in deployment considerations is encouraged
to read <xref target="map-d"/>.</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>
<!-- conventions -->
<!-- SECTION 3: DESCRIPTION -->
<section anchor="description" title="Provisioning mechanism">
<t>A typical MAP CE usually acts as a DHCPv6 client and requests
options that are being provided by a DHCPv6 server located
somewhere in ISP network. This server provides typical
information to configured nodes: namely IPv6 address (in IA_NA
option) and delegates a prefix (in IA_PD option). Server also
provides additional parameters that are MAP specific. In
particular, it provides the following information:</t>
<t>
<list style="symbols">
<t>One or more MAP rules. MAP mapping rules are defined in Section 4 of <xref
target="I-D.mdt-softwire-mapping-address-and-port"/>. There are
several mapping rule types defined: Basic Mapping Rule (BMR), Forwarding
Mapping Rule (FMR) and Default Mapping Rule (DMR).
Depending on rule type, number
of exact useful parameters may be different. Rule parameters may contain
Rule IPv6 prefix (including prefix length), Rule IPv4 prefix (including
prefix length), and additional values that
define Rule Port Parameters. One MAP CE can receive
one or more MAP mapping rules from the DHCPv6 server. Exactly one of those
rules MUST be the default MAP mapping rule for the
initiated CE of its own, possibly accompanied with additional mapping rules
within the MAP domain if necessary.</t>
<t>Transport mode indicates encapsulation or translation mode for MAP
approach. It should be conducted on interface-by-interface
basis.</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
Flags 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>
<section title="DHCPv6 Options Format">
<t>DHCPv6 protocol is used for CE provisioning. Several new
options are defined for conveying MAP-specific parameters. Their
format and usage 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 or even rewritten completely.</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
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"/>).</t>
<section title="Options Cardinality">
<t>MAP rule is defined in <xref target="I-D.mdt-softwire-mapping-address-and-port"/>, Section 4.</t>
<t>Discussion: If you want additional parameter added to the
OPTION_MAP_RULE option (or any other option), please update <xref
target="I-D.mdt-softwire-mapping-address-and-port"/> first.</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>
<t>OPTION_MAP option MUST include one or more OPTION_MAP_RULE options.</t>
</section>
<section anchor="option-flags" title="MAP Flags Option">
<t>This option specifies MAP flags and is used to group all rules for
specified MAP domain. Currently the only
defined flag is T that describes transport mode. Other flags that affect
all mapping rules or the whole MAP domain may be specified
here at a later date.</t>
<t>Each OPTION_MAP option MUST contain one or more MAP Rule
Options.</t>
<figure align="center" anchor="img-option-flags" title="MAP Flags 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |T| .
+-+-+-+-+-+-+-+-+ .
. sub-options (variable length) .
+---------------------------------------------------------------+]]>
</artwork>
</figure>
<t>
<list style="symbols">
<t>option-code: OPTION_MAP (TBD1)</t>
<t>option-length: 1</t>
<t>reserved: This 7-bits long reserved field is not used
and MUST be set to 0 by server. Its value MUST be ignored
by clients.</t>
<t>T: 1 bit field that specifies transport mode:
translation (0) or encapsulation (1).</t>
<t>suboptions: sub-options specific to this MAP
domain. MUST contain one or more MAP_RULE options.</t>
</list>
</t>
<t>It was suggested to also provision information whether MAP
network is working in hub and spoke or full mesh mode. That is
not necessary, as this information can be derived from
provisioned MAP rules. In the 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.
</t>
</section>
<section title="MAP Rule Option">
<t>MAP Rule Option option represents a single MAP
Rule. Depending on deployment mode, each CE may require one or
more MAP Rules to operate properly.</t>
<t>Server includes one or more MAP Rule Options in MAP Flags 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 | ea-len | prefix6-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| rule-ipv6-prefix |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. rule sub-options (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>Explicit parameters are:
<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 sub-options.</t>
<t>prefix4-len: 8 bits long field expressing length of the
IPv4 prefix, specified in the rule-ipv4-prefix field,
expressed in bits.</t>
<t>ea-len: 8-bits long field that specifies
Embedded-Address (EA) - length, expressed in bits. This
field is meaningful only for FMR. For other rules types,
it MUST be set to zero by the server and its content MUST
be ignored by the clients.</t>
<t>prefix6-len: 8 bits long length of the IPv6 prefix,
specified in the rule-ipv6-prefix field, expressed in
bits.</t>
<t>rule-ipv6-prefix: a variable size field that specifies
Rule IPv6 prefix. Length of the
field is defined by prefix6-len field and is rounded up to
the nearest octet boundary (if case when prefix6-len is
not divisible by 8). In such case additional padding bits
must be zeroed.</t>
<t>rule-ipv4-prefix: a 32-bits long field that specifies
an IPv4 prefix that appears in a MAP rule.</t>
<t>rule sub-options: a variable field that may contains
zero or more options that specify additional parameters
for this rule. Those options follow standard DHCPv6 option
format, as defined in <xref target="RFC3315"/>, Section
22.1. Currently there is only one option defined that may
appear in rule sub-options field. This option is
OPTION_MAP_PORTPARAMS, defined in section <xref
target="option-portparams"/>. Other options may be defined
at a later date.</t>
</list>
</t>
<t>There are also number of implicit parameters that may be
derived from content of MAP and other options. In particular,
End-User IPv6 Prefix (or Delegated prefix, specified in IA_PD
option, see <xref target="RFC3633"/>) and assigned IPv6
address (specified in IA_NA option, see <xref
target="RFC3315"/>) are needed. Even though these values are
not provided explicitely, they are required for proper MAP
rule configuration. Following implicit parameters may be
calculated:
<list style="symbols">
<t>rule type: Depending on rule content, it can be Basic
Mapping Rule (BMR), Forwarding Mapping Rule (FMR) or
Default Mapping Rule (DMR). See Sections 4.2, 4.3 and 4.4
in <xref
target="I-D.mdt-softwire-mapping-address-and-port"/> for
detailed description of those rules. A CE node can
determine, which received rule is the basic rule based on
the longest match between End-User IPv6 prefix (received
in IAPREFIX option in IA_PD) and the Rule IPv6 prefix
(received in Map Rule Option). A Default rule can be
determined by the fact that it has Rule IPv4 prefix of
0.0.0.0/0.</t>
<!--
<t>L parameter. It is equal to a length of a prefix
delegated to CE, conveyed in OPTION_IA_PD and IAPREFIX, as
defined in <xref target="RFC3633"/>.</t> -->
<t>Embedded Address bits (EA-bits) length can be derived
as a length of the delegated prefix (specified in
prefix-length field in IAPREFIX option) decreased by MAP
Domain IPv6 prefix length (specified in prefix6-len of the
DMR).</t>
</list>
</t>
<t>It is expected that in a typical simple scenarios, there
will be a single BMR with a single DMR (that will also work as
FMR). For detailed discussion about MAP deployment
considerations, see <xref target="map-d"/>.</t>
<t>Note that the DMR is a simplified version of BMR. While it
reuses the same DHCPv6 option format, DMR uses only Rule IPv6
prefix, Rule IPv6 Prefix Length and IPv4 address that denotes
BR IPv4 address. All other parameters are ignored for Default
Mapping Rule. Client MUST ignore those parameters for DMR and
server MUST set those parameters to zero.</t>
<!--
<t>Discussion: Remi Despres pointed out that not all of
prefix4len + prefix6-len + ea-len + excluded ports + off are
needed. Only 4 of these are independent, so one of them will be removed.</t>-->
<!-- tomek: the one that had to go is ea-len -->
</section>
<section anchor="option-portparams" title="Port Parameters Option">
<t>Port Parameters Option specifies optional Rule Port
Paramters that MAY be provided as part of the Mapping Rule. It
MAY appear as sub-option in OPTION_MAP_RULE option. It MUST
NOT appear directly in a message.</t>
<t>See <xref target="I-D.mdt-softwire-mapping-address-and-port"/>, Section 4.1
for detailed description of Port mapping algorithm.</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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| excluded-ports | rsv | off |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<list style="symbols">
<t>option-code: OPTION_MAP_PORTPARAMS (TBD3)</t>
<t>option-length: 3</t>
<t>excluded-ports: defines upper bound for range of
excluded ports. The lower range is 0. For example a
value 1023 means that excluded range is 0-1023 ports. Value of 0
(range 0-0) means that no ports are excluded.</t>
<t>rsvd: This 5-bits long field is currently not used and
MUST be set to 0 by server. Its value MUST be ingored
by clients.</t>
<t>off: 3 bits long field that specifies offset bits. It
is referred to as 'a' value and specifies length of a A
field, as presented in Fig. 1 in <xref
target="I-D.mdt-softwire-mapping-address-and-port"/>,
Section 4.1.1.</t>
</list>
</t>
<t>TODO: Ole pointed out that excluded-ports are related to the offset.
with a = 6, j > 0 you exclude 0-1023;
with a = 4, j > 0 you exclude 0-4095;
with a = 0, no ports excluded and number of systems ports per user given by PSID/PSID length
the flag would allow j = 0.</t>
<t>Map Port Parameters Option is optional. If it is not present,
the following default values are assumed:
<list style="numbers">
<t>Excluded ports: 0-4095 (excluded-ports field value is 4095)</t>
<t>Offset bits: 4 (off field value is 4)</t>
</list>
If administrator wants to provision only one of those
parameters, remaining fields SHOULD be set to their default
value.
</t>
</section>
<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="BMR Option Example">
<figure align="center" anchor="img-bmr-example" title="BMR Option Example">
<preamble></preamble>
<artwork align="center"><![CDATA[
TODO: Reflect example in section 4.2 of MAP draft
]]></artwork>
</figure>
</section>
<section title="FMR Option Example">
<figure align="center" anchor="img-fmr-example" title="FMR Option Example">
<preamble></preamble>
<artwork align="center"><![CDATA[
TODO: Reflect example in section 4.3 of MAP draft
]]></artwork>
</figure>
</section>
<section title="DMR Option Example">
<figure align="center" anchor="img-dmr-example" title="DMR Option Examples">
<preamble></preamble>
<artwork align="center"><![CDATA[
TODO: Reflect example in section 4.4 of MAP draft
]]></artwork>
</figure>
</section>
</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 not reply with a MAP Rule Option
if the client has not explicitly enumerated it on its Option
Request Option.</t>
<t>Server conformant to this specification MUST allow
configuration of one or more MAP Rule Options.</t>
<t>Server MUST transmit all configured instances of the Mapping
Rule Options with all sub-options, if client requested it using
OPTION_MAP_RULE in its Option Request Option (ORO). Server MUST
transmit MAP Flags Option if client requested OPTION_MAP
in its ORO.</t>
<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>
</section>
<section title="DHCPv6 Client Behavior">
<t>Although other use cases are allowed, in a typical use case CE
will act as DHCPv6 client and will request MAP configuration to
be assigned by the DHCPv6 server located in the ISP network. A
client that supports MAP CE functionality and conforms to this
specfication MUST include OPTION_MAP_RULE and OPTION_MAP
in its ORO.</t>
<t>For proper operation, MAP CE client MUST also request IPv6
address (OPTION_IA_NA, defined in <xref target="RFC3315"/>) and
prefix delegation (OPTION_IA_PD, defined in <xref
target="RFC3633"/>). MAP CE client SHOULD NOT initiate DHCPv4
configuration for the purpose of MAP configuration as all
parameters are delivered over DHCPv6.</t>
<t>Client supporting MAP functionality SHOULD request
OPTION_MAP_RULE and OPTION_MAP options in SOLICIT,
REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages.</t>
<t>If client receives more than one OPTION_MAP_RULE option, it
MUST use all received instances. It MUST NOT use only the first
one, while discarding remaining ones.</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="IANA Considerations">
<t>IANA is kindly requested to allocate DHCPv6 option code TBD1 to the
OPTION_MAP,TBD2 to OPTION_MAP_RULE and TBD3 to
OPTION_MAP_PORTPARAMS. All three values should be added to the
DHCPv6 option code space defined in Section 24.3 of <xref
target="RFC3315"/>.</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 familiarize with <xref
target="I-D.ietf-dhc-secure-dhcpv6"/>.</t>
<t>Section XX of <xref target="I-D.mdt-softwire-mapping-address-and-port"/> discusses
security issues of the MAP mechanism.</t>
<t>Section 23 of <xref target="RFC3315"/> discusses
DHCPv6-related security issues.</t>
<t>Section 6 of <xref target="I-D.murakami-softwire-4rd"/> discusses 4rd
related security issues that are partially applicable to MAP mechanism.</t>
</section>
<section title="Contributors">
<t>The current members of the MAP design team are:
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>
</section>
<section title="Acknowledgements">
<t>Authors would like to thank Jacni Qin, Qiong Sun and Remi
Despres for their comments and suggestions.</t>
</section>
</middle>
<back>
<!-- SECTION 8.1: Normative References -->
<references title="Normative References">
&rfc2119;
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mdt-softwire-mapping-address-and-port.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"?>
</references>
<references title="Informative References">
<reference anchor="map-d" target="">
<front>
<title>Mapping of Address and Port (MAP) - Deployment Considerations</title>
<author fullname="Maoke Chen" initials="M" surname="Chen">
<organization abbrev="FreeBit">FreeBit Co., Ltd.</organization>
</author>
<author fullname="Qiong Sun" initials="Q" surname="Sun">
<organization>China Telecom</organization>
</author>
<author fullname="Gang Chen" initials="G" surname="Chen">
<organization abbrev="">China Mobile</organization>
</author>
<date day="23" month="12" year="2012" />
</front>
<seriesInfo name="draft-mdt-softwire-map-deployment" value="00" />
</reference>
<?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" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226" ?>
</references>
<!-- SECTION 8.2: Informative References -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:27:20 |