draft-ietf-softwire-map-dhcp.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2131 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!--<!ENTITY rfc3633 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">-->
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2473 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml">
<!--<!ENTITY rfc5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">-->
<!--<!ENTITY rfc6335 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml">-->
<!ENTITY rfc6145 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6145.xml">
<!ENTITY rfc7227 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7227.xml">
<!ENTITY I-D.ietf-softwire-map SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-map.xml">
<!ENTITY I-D.ietf-softwire-map-t SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-map-t.xml">
<!ENTITY I-D.ietf-softwire-lw4over6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-lw4over6.xml">
<!--<!ENTITY I-D.mdt-softwire-map-deployment SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mdt-softwire-map-deployment.xml">-->
<!--<!ENTITY I-D.ietf-homenet-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-homenet-arch.xml">-->
<!--<!ENTITY I-D.ietf-dhc-option-guidelines SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-option-guidelines.xml">-->
<!ENTITY I-D.ietf-dhc-sedhcpv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-sedhcpv6.xml">
<!--<!ENTITY I-D.townsley-troan-ipv6-ce-transitioning SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.townsley-troan-ipv6-ce-transitioning.xml">-->
<!ENTITY I-D.ietf-softwire-unified-cpe SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-unified-cpe.xml">

]>


<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>


<rfc category="std" docName="draft-ietf-softwire-map-dhcp-12"
     ipr="trust200902">
  <front>
    <title abbrev="DHCPv6 for Softwire 46 CEs">DHCPv6 Options for
    configuration of Softwire Address and Port Mapped Clients</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>

    <author fullname="Ole Troan" initials="O" surname="Troan">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Philip Pedersens vei 1</street>
          <city>Lysaker</city>
          <code>1366</code>
          <country>Norway</country>
        </postal>
        <email>ot@cisco.com</email>
      </address>
    </author>


   
    <author fullname="Ian Farrer" initials="I." surname="Farrer">
      <organization>Deutsche Telekom AG</organization>
      <address>
      <postal>
      <street>CTO-ATI, Landgrabenweg 151</street>
      <city>Bonn</city>
      <region>NRW</region>
      <code>53227</code>
      <country>Germany</country>
      </postal>
          <phone></phone>
      <email>ian.farrer@telekom.de</email>
      </address>
    </author>

    <author fullname="Simon Perreault" initials="S." surname="Perreault">
      <organization>Viagenie</organization>
      <address>
      <postal>
      <street>246 Aberdeen</street>
                  <city>Quebec</city>
                  <region>QC</region>
      <code>G1R 2E1</code>
      <country>Canada</country>
      </postal>
          <phone>+1 418 656 9254</phone>
      <email>simon.perreault@viagenie.ca</email>
      </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>CNNIC</organization>
     <address>
       <postal>
         <street>4, South 4th Street, Zhong_Guan_Cun</street>
         <city> Beijing</city>
         <region></region>
         <code>100190</code>
         <country>P. R. China</country>
       </postal>
       <email>leaf.yeh.sdo@gmail.com</email>
     </address>
   </author>

   <author fullname="Xiaohong Deng" initials="X." surname="Deng">
     <organization></organization>
     <address>
       <postal>
         <street>6 Floor, C Block, DaCheng International Center Chaoyang District</street>
         <code>100124</code>
         <city>Beijing</city>
         <country>China</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, termed Softwire46
      options, for the provisioning of Softwire46 Customer Edge (CE)
      devices. Softwire46 is a collective term used to refer to
      architectures based on the notion of IPv4 Address+Port (A+P) for
      providing IPv4 connectivity across an IPv6 network.</t>
      <t></t>
    </abstract>
  </front>

  <middle>
    <!--  SECTION 1:  Introduction                  -->


    <section title="Introduction">
      <t>A number of architectural solution proposals discussed in the
      IETF Softwire Working Group use Address and Port (A+P) as their
      technology base for providing IPv4 connectivity to end users
      using CE devices across a Service Provider's IPv6 network, while
      allowing for shared or dedicated IPv4 addressing of CEs.</t>

      <t>An example is Mapping of Address and Port (MAP) defined in
      <xref target="I-D.ietf-softwire-map"></xref>. The MAP solution
      consists of one or more MAP Border Relay (BR) routers,
      responsible for stateless forwarding between a MAP IPv6 domain
      and an IPv4 network, and one or more MAP Customer Edge (CE)
      routers, responsible for forwarding between a user's IPv4
      network and the MAP IPv6 network domain. Collectively, the MAP
      CE and BR form a domain when configured with common service
      parameters. This characteristic is common to all of the
      Softwire46 mechanisms.</t>

      <t>To function in such a domain, a CE needs to be provisioned
      with the appropriate A+P service parameters for that
      domain. These consist primarily of the CE's IPv4 address and
      transport layer port-range(s). Furthermore, the IPv6 transport
      mode (i.e. encapsulation or translation) needs to be
      specified. Provisioning of other IPv4 configuration information
      not derived directly from the A+P service parameters is not
      covered in this document. It is expected that provisioning of
      other IPv4 configuration will continue to use DHCPv4 <xref
      target="RFC2131"/>.</t>

      <t>This memo specifies a set of DHCPv6 <xref target="RFC3315"/>
      options to provision Softwire46 information to CE
      routers. Although the focus is to deliver IPv4 service to an
      end-user network (such as a residential home network), it can
      equally be applied to an individual host acting as a
      CE. Configuration of the BR is out of scope of this
      document.</t>

    </section>

<!--
    <section title="Softwire46 approaches discussed">
      <t>***To be removed***</t>

      <t>The approach laid out in this document was taken after
      consideration of a couple of alternatives. The first alternative
      was to have everything in the single option. However, given that
      in practice some CPEs might not implement all of the mechanism,
      this means the single option would not work. The CPE would have
      to come up with the mechanism to signal its capabilities to
      DHCPv6 server. Thus, the conclusion was made that each mechanism
      requires its own option, containing the per-mechanism
      configuration. The container design was selected because the
      configuration elements are similar between the mechanisms and
      having the smaller building blocks within them should help to
      reuse the code, for the CPEs that implement multiple
      mechanisms. After the multi-container approach was taken, the
      choice was to keep everything in the single document or split
      into several documents - one per mechanism.</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 title="Softwire46 Overview">

     <t>This document describes a set of common DHCPv6 options for
     configuring the MAP-E <xref target="I-D.ietf-softwire-map"/>,
     MAP-T <xref target="I-D.ietf-softwire-map-t"/> and Lightweight
     4over6 <xref target="I-D.ietf-softwire-lw4over6"/>
     mechanisms. For definition of the terminology used in this
     document please see the relevant terminology sections in the
     above references.</t>

     <t>MAP-E, MAP-T and Lightweight 4over6 are essentially providing
     the same functionality: IPv4 service to a CE router over an IPv6
     only access network. MAP-E and MAP-T may embed parts of the IPv4
     address in IPv6 prefixes, thereby supporting many clients with a
     fixed set of mapping rules and mesh mode (direct CE to CE
     communication). MAP-E and MAP-T CEs may also be provisioned in
     hub and spoke mode, and in 1:1 mode (with no embedded address
     bits). The difference between MAP-E and MAP-T is that they use
     different means to connect to the IPv6 domain. MAP-E uses <xref target="RFC2473"/> IPv4 over IPv6 tunnelling, while MAP-T
     uses NAT64 <xref target="RFC6145"/> based
     translation. Lightweight 4over6 is a hub and spoke IPv4 over IPv6
     tunneling mechanism, with complete independence of IPv4 and IPv6
     addressing (zero embedded address bits).</t>

     <t>The DHCP options described here tie the provisioning
     parameters, and hence the IPv4 service itself, to the End-user
     IPv6 prefix lifetime. The validity of a Softwire46's IPv4
     address, prefix or shared IPv4 address, port set and any
     authorization and accounting are tied to the lifetime of its
     associated End-user IPv6 prefix.</t>

     <t>To support more than one mechanism at a time and to allow for
     a possibility of transition between them, the DHCPv6 Option
     Request Option <xref target="RFC3315"/> is used. Each mechanism
     has a corresponding DHCPv6 container option. A DHCPv6 client can
     request a particular mechanism by including the option code for a
     particular container option in its ORO option. The provisioning
     parameters for that mechanism are expressed by embedding the
     common format options within the respective container option.</t>

     <t>This approach implies that all of the provisioning options
     MUST appear only within the container options. The client MUST
     NOT request any of the provisioning options directly within an
     ORO. MAP-DHCP clients that receive provisioning options that are
     not encapsulated in container options MUST silently ignore these
     options.  DHCP server administrators are advised to ensure that
     DHCP servers are configured to send these options in the proper
     encapsulation.</t>

     <t>The document is organized with the common sub-options
     described first, followed by the three container options. Some
     sub-options are mandatory in some containers, some are optional
     and some are not permitted at all. This is shown in <xref
     target="table_options"></xref>.</t>

    </section>

    <section title="Common Softwire46 DHCPv6 Options">
      <t>The DHCPv6 protocol is used for Softwire46 CE provisioning
      following regular DHCPv6 notions, with the CE assuming the role
      of a DHCPv6 client, and the DHCPv6 server providing options
      following DHCPv6 server side policies. The format and usage of
      the options are defined in the following sub-sections.</t>

      <t>Each CE needs to be provisioned with enough information to
      calculate its IPv4 address, IPv4 prefix or shared IPv4
      address. MAP-E and MAP-T use the OPTION_S46_RULE, while
      Lightweight 4over6 uses the OPTION_S46_V4V6BIND option. A
      CE that needs to communicate outside of the A+P domain also
      needs the address or prefix of the BR. MAP-E and Lightweight
      4over6 use the OPTION_S46_BR option to communicate the IPv6
      address of the BR. MAP-T forms an IPv6 destination address by
      embedding an IPv4 destination address into the BR's IPv6 prefix
      conveyed via the OPTION_S46_DMR option. Optionally, all
      mechanisms can include OPTION_S46_PORTPARAMS to specify
      parameters and port sets for the port range algorithm.</t>

      <t>Softwire46 options use addresses rather than FQDNs. For
      rationale behind this design choice, see Section 8 of
      <xref target="RFC7227"/>.</t>
   
      <section title="S46 Rule Option">
        <t><xref target="img-option-rule"></xref> shows the format of
        the S46 Rule option (OPTION_S46_RULE) used for conveying the
        Basic Mapping Rule (BMR) and Forwarding Mapping Rule
        (FMR).</t>

        <t>This option follows behavior described in Sections 17.1.1
        and 18.1.1 of <xref target="RFC3315"/>. Clients can insert
	those options with specific values as hints for the
	server. Depending on the server configuration and policy,
	it may accept or ignore the hints. Client MUST be able
	to process received values that are different than the
	hints it sent earlier.</t>

        <figure align="center" anchor="img-option-rule"
                title="S46 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_S46_RULE        |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     flags     |     ea-len    |  prefix4-len  | ipv4-prefix   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  (continued)                  |  prefix6-len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ipv6-prefix                         |
|                       (variable length)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                        S46_RULE-options                       .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>option-code: OPTION_S46_RULE (TBD1)</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>flags: 8 bits long field carrying flags applicable to the
            rule. The meaning of specific bits are explained in <xref
            target="img-rule-flags"></xref>.</t>

            <t>ea-len: 8 bits long field that specifies the Embedded-Address
            (EA) bit length. Allowed values range from 0 to 48.</t>

            <t>prefix4-len: 8 bits long field expressing the prefix
            length of the IPv4 prefix specified in the
            rule-ipv4-prefix field. Valid values 0 to 32.</t>

            <t>ipv4-prefix: a fixed length 32 bit field that specifies
            the IPv4 prefix for the S46 rule. The bits in the prefix
            after prefix4-len number of bits are reserved and MUST be
            initialized to zero by the sender and ignored by the
            receiver.</t>

            <t>prefix6-len: 8 bits long field expressing the length
            of the IPv6 prefix specified in the rule-ipv6-prefix field.</t>

	    <t>ipv6-prefix: a variable length field that specifies the
	    IPv6 domain prefix for the S46 rule.  The field is padded
	    on the right with zero bits up to the nearest octet
	    boundary when prefix6-len is not evenly divisible by
	    8.</t>

	    <t>S46_RULE-options: a variable field that may contain
	    zero or more options that specify additional parameters
	    for this S46 rule. This document specifies one such
	    option, OPTION_S46_PORTPARAMS.</t>
          </list></t>

        <t>The Format of the S46 Rule Flags field is:<figure align="center"
            anchor="img-rule-flags" title="S46 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). If set, this rule is used
	    as a FMR, if not set this rule is a BMR only and MUST NOT
	    be used for forwarding. Note: A BMR can also be used as
	    an FMR for forwarding if the F-flag is set. The BMR rule
	    is determined by a longest-prefix match of the
	    Rule-IPv6-prefix against the End-User IPv6 prefix(es).</t>
          </list></t>

        <t>It is expected that in a typical mesh deployment scenario,
        there will be a single BMR, which could also be designated as
        an FMR using the F-Flag.</t>
      </section>

      <section title="S46 BR Option">
        <t>The S46 BR Option (OPTION_S46_BR) is used to convey the
        IPv6 address of the Border Relay. <xref
        target="img-option-dmr"></xref> shows the format of the
        OPTION_S46_BR option.</t>

        <t><figure align="center" anchor="img-option-br"
            title="S46 BR 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_S46_BR         |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      br-ipv6-address                          |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>option-code: OPTION_S46_BR (TBD2)</t>
            <t>option-length: 16</t>
            <t>br-ipv6-address: a fixed length field of 16 octets that specifies the
            IPv6 address for the S46 BR.</t>
          </list></t>

	  <t>BR redundancy can be implemented by using an anycast
	  address for the BR IPv6 address. Multiple OPTION_S46_BR
	  options MAY be included in the container; this document does
	  not further explore the use of multiple BR IPv6
	  addresses.</t>
      </section>

      <section title="S46 DMR Option">
        <t>The S46 DMR Option (OPTION_S46_DMR) is used to convey
        values for the Default Mapping Rule (DMR). <xref
        target="img-option-dmr"></xref> shows the format of the
        OPTION_S46_DMR option used for conveying a DMR.</t>

        <t><figure align="center" anchor="img-option-dmr"
            title="S46 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_S46_DMR         |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dmr-prefix6-len|            dmr-ipv6-prefix                    |
+-+-+-+-+-+-+-+-+           (variable length)                   |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>option-code: OPTION_S46_DMR (TBD3)</t>
            <t>option-length: 1 + length of dmr-ipv6-prefix 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 specifying the
            IPv6 prefix or address for the BR. This field is right padded
            with zeros to the nearest octet boundary when dmr-prefix6-len
            is not divisible by 8.</t>

          </list></t>
      </section>

      <section anchor="option-v4v6bind"
               title="S46 IPv4/IPv6 Address Binding Option">
        <t>The IPv4 address Option (OPTION_S46_V4V6BIND) MAY be used
        to specify the full or shared IPv4 address of the CE. The IPv6
        prefix field is used by the CE to identify the correct prefix
        to use for the tunnel source.</t>

        <figure align="center" anchor="img-option-v4v6bind"
                title="S46 IPv4/IPv6 Address Binding 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_S46_V4V6BIND      |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         ipv4-address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|bindprefix6-len|             bind-ipv6-prefix                  |
+-+-+-+-+-+-+-+-+             (variable length)                 |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                      S46_V4V6BIND-options                     .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

        </figure>

        <t><list style="symbols">
            <t>option-code: OPTION_S46_V4V6BIND (TBD4)</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>ipv4-address: A fixed field of 4 octets specifying an IPv4
            address.</t>
            <t>bindprefix6-len: 8 bits long field expressing the bit mask
            length of the IPv6 prefix specified in the bind-ipv6-prefix
            field.</t>
            <t>bind-ipv6-prefix: a variable length field specifying the
            IPv6 prefix or address for the S46 CE. This field is right padded with
            zeros to the nearest octet boundary when bindprefix6-len
            is not divisible by 8.</t>
	    <t>S46_V4V6BIND-options: a variable field that may contain
	    zero or more options that specify additional
	    parameters. This document specifies one such option,
	    OPTION_S46_PORTPARAMS.</t>
	</list></t>
      </section>

      <section anchor="option-portparams"
               title="S46 Port Parameters Option">
        <t>The Port Parameters Option (OPTION_S46_PORTPARAMS)
        specifies optional Port Set information that MAY be provided
        to CEs.</t>

        <t>See <xref target="I-D.ietf-softwire-map"></xref>, Section 5.1 for
        a description of MAP algorithm, explaining all of the parameters in
        detail.</t>

        <figure align="center" anchor="img-option-portparams"
                title="S46 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_S46_PORTPARAMS     |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   offset      |    PSID-len   |              PSID             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>option-code: OPTION_S46_PORTPARAMS (TBD5)</t>

            <t>option-length: 4</t>

            <t>offset: (PSID offset) 8 bits long field that specifies
            the numeric value for the S46 algorithm's excluded port
            range/offset bits (a-bits), as per section 5.1.1 of <xref
            target="I-D.ietf-softwire-map"></xref>. Allowed values are
            between 0 and 15. Default values for this field are
            specific to the softwire mechanism being implemented and
            are defined in the relevant specification document.</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 the
            value of the Port Set Identifier (PSID). Consequently, 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 field contain the PSID
            value. The remaining (16-k) bits on the right are padding
            zeros.</t>
          </list></t>

	  <t>When receiving the OPTION_S46_PORTPARAMS option with an
	  explicit PSID, the client MUST use this explicit PSID in
	  configuring its softwire interface. The
	  OPTION_S46_PORTPARAMS option with an explicit PSID MUST be
	  discarded if the S46 CE isn't configured with a full
	  IPv4 address (e.g. IPv4 prefix).</t>

	  <t>The OPTION_S46_PORTPARAMS option with an explicit PSID
	  MUST be discarded if the S46 CE isn't configured with a full
	  IPv4 address (e.g. IPv4 prefix).</t>

	  <!--<t>On receipt of the Port
	  Parameters option with an explicit PSID, clients MUST
	  configure their softwire interface with the received
	  explicit PSID. If the conveyed IPv4 address is not 32
	  bits-long, the option MUST be discarded. The formula for
	  this check is "prefix4-len + ea-len = 32" and serves to
	  ensure that the explicit PSID is only applied to
	  configurations with a completely formed IPv4 address.</t>-->

	<t>The OPTION_S46_PORTPARAMS option is contained within an
	OPTION_S46_RULE option or an OPTION_S46_V4V6BIND option.</t>

      </section>
    </section>

    <section title="Softwire46 Containers">
      <section anchor="option-mape" title="Softwire46 MAP-E Container Option">
        <t>The MAP-E Container Option (OPTION_S46_CONT_MAPE) specifies
        the container used to group all rules and optional port
        parameters for a specified domain.</t>

        <figure align="center" anchor="img-mape-option"
                title="MAP-E 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_S46_CONT_MAPE   |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.            encapsulated-options (variable length)             .
.                                                               .
+---------------------------------------------------------------+
	]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>option-code: OPTION_S46_CONT_MAPE (TBD6)</t>
            <t>option-length: Length of encapsulated options</t>
            <t>encapsulated-options: options associated with this Softwire46
            MAP-E domain.</t>
          </list></t>

        <t>The encapsulated options field conveys options specific to
        the OPTION_S46_CONT_MAPE. Currently there are two
        sub-options specified, OPTION_S46_RULE and
        OPTION_S46_BR. There MUST be at least one OPTION_S46_RULE
        option and at least one OPTION_S46_BR option.</t>

	<t>Other options applicable to a domain may be defined in the
	future. A DHCP message MAY include multiple
	OPTION_S46_CONT_MAPE options (representing multiple
	domains).</t>
      </section>

      <section anchor="option-mapt" title="Softwire46 MAP-T Container Option">
        <t>The MAP-T Container option (OPTION_S46_CONT_MAPT) specifies
        the container used to group all rules and optional port
        parameters for a specified domain.</t>

        <figure align="center" anchor="img-mapt-option"
                title="MAP-E 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_S46_CONT_MAPT      |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.            encapsulated-options (variable length)             .
.                                                               .
+---------------------------------------------------------------+
	]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>option-code: OPTION_S46_CONT_MAPT (TBD7)</t>
            <t>option-length: Length of encapsulated options</t>
            <t>encapsulated-options: options associated with this
            Softwire46 MAP-T domain.</t>
          </list></t>

        <t>The encapsulated options field conveys options specific to
        the OPTION_S46_CONT_MAPT option. Currently there are two
        options specified, the OPTION_S46_RULE and OPTION_S46_DMR
        options. There MUST be at least one OPTION_S46_RULE option and
        exactly one OPTION_S46_DMR option.</t>

      </section>


      <section anchor="option-lw46" title="Softwire46 LightWeight 46 Container Option">
        <t>The LW46 Container option (OPTION_S46_CONT_LW) specifies
        the container used to group all rules and optional port
        parameters for a specified domain.</t>

        <figure align="center" anchor="img-lw-option"
                title="LW46 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_S46_CONT_LW       |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+            encapsulated-options (variable length)             .
.                                                               .
+---------------------------------------------------------------+
	]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>option-code: OPTION_S46_CONT_LW (TBD8)</t>
            <t>option-length: Length of encapsulated options</t>
            <t>encapsulated-options: options associated with this Softwire46
            domain.</t>
          </list></t>

        <t>The encapsulated options field conveys options specific to
        the OPTION_S46_CONT_LW option. Currently there are two options
        specified, OPTION_S46_V4V6BIND and OPTION_S46_BR. There MUST
        be at most one OPTION_S46_V4V6BIND option and at least one
        OPTION_S46_BR option.</t>

      </section>

    </section>

    <section title="Softwire46 Options Formatting">

      <t>The below table shows which sub-options are mandatory,
      optional or not permitted for each defined container option.</t>


      <texttable anchor="table_options" title="Option to Container Mappings">
    <ttcol align='left'>Option</ttcol>
    <ttcol align='center'>MAP-E</ttcol>
    <ttcol align='center'>MAP-T</ttcol>
    <ttcol align='center'>Lightweight 4over6</ttcol>

    <c>OPTION_S46_RULE</c><c>M</c><c>M</c><c>N/A</c>
    <c>OPTION_S46_BR</c><c>M</c><c>N/A</c><c>M</c>
    <c>OPTION_S46_PORTPARAMS</c><c>O</c><c>O</c><c>O</c>
    <c>OPTION_S46_DMR</c><c>N/A</c><c>M</c><c>N/A</c>
    <c>OPTION_S46_V4V6BIND</c><c>N/A</c><c>N/A</c><c>O</c>

    <postamble>M - Mandatory, O - Optional, N/A - Not Applicable</postamble>
      </texttable>

      <t>MAP-DHCP clients that receive container options that violate
      any of the above rules MUST silently ignore such container
      options.</t>

    </section>
    <section title="DHCPv6 Server Behavior">
      <t><xref target="RFC3315"/> Section 17.2.2
      describes how a DHCPv6 client and server negotiate configuration
      values using the ORO.  As a convenience to the reader, we
      mention here that by default, a server will not reply with a
      Softwire46 Container Option if the client has not explicitly
      enumerated one in its Option Request Option.</t>

      <t>A CE router may support several (or all) of the mechanisms
      mentioned here.  In the case where a client requests multiple
      mechanisms in its ORO option, the server will reply with the
      corresponding Softwire46 Container options for which it has
      configuration information.</t>
    </section>

    <section title="DHCPv6 Client Behavior">
      <t>An S46 CE acting as DHCPv6 client will request S46
      configuration parameters from the DHCPv6 server located in the
      IPv6 network. Such a client MUST request the S46 Container
      option(s) that it is configured for in its ORO in SOLICIT,
      REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages.</t>

      <t>When processing received S46 container options the following
      behaviour is expected:<list style="symbols">
          <t>A client MUST support processing multiple received
          OPTION_S46_RULE options in a container OPTION_S46_CONT_MAPE or
          OPTION_S46_CONT_MAPT option</t>

          <t>A client receiving an unsupported S46 option, or an
          invalid parameter value SHOULD discard that S46 Container
          option and log the event.</t>
      </list></t>

      <t>The behavior of a client supporting multiple Softwire46
      mechanisms, is out of scope of this document. <xref
      target="I-D.ietf-softwire-unified-cpe"/> describes client behaviour
      for the prioritization and handling of multiple mechanisms
      simultaneously.</t>


<!--      
      <t>DISCUSS: There are many ways of delivering IPv4 to a CE
      router. Native IPv4 with global addressing, native IPv4 with
      private addressing, DS-lite, 464XLAT, 4rd, MAP-E, MAP-T,
      Lightweight 4over6. Should a CPE prefer a single option (per
      interface), should it configure multiple, and handle a smooth
      transition between them? <xref
      target="I-D.townsley-troan-ipv6-ce-transitioning"/> proposes one
      of the approaches to handle this scenario by having an implicit
      order. Other approaches are possible and should be discussed,
      however, this is out of scope for this particular document.</t>
-->

      <t>Note that system implementing CE functionality may have
      multiple network interfaces, and these interfaces may be
      configured differently; some may be connected to networks using
      a Softwire46 mechanism, and some may be connected to networks
      that are using normal dual stack or other means. The CE should
      approach this specification on an interface-by-interface
      basis. For example, if the CE system is MAP-E capable and is
      attached to multiple networks that provide the
      OPTION_S46_CONT_MAPE option, then the CE MUST configure MAP-E
      for each interface separately.</t>

      <t>Failure modes are out of scope for this document. Failure
      recovery mechanisms may be defined in the future. See Section 5 of
      <xref target="I-D.ietf-softwire-map" /> for discussion on valid
      MAP rule combinations. See Section 11 of <xref target="RFC7227" />,
      Sections 18.1.3, 18.1.4 and 19.1 of <xref target="RFC3315"/> for
      parameters update mechanisms in DHCPv6 that can be leveraged to
      update configuration after a failure.</t>
    </section>

    <section title="Security Considerations">
      <t>Section 23 of <xref target="RFC3315"></xref> discusses DHCPv6-related
      security issues.</t>

      <t>As with all DHCPv6-derived configuration state, it is
      possible that configuration is actually being delivered by a third
      party (Man In The Middle). As such, there is no basis on which
      access over MAP or lw4o6 can be trusted. Therefore, softwires should not
      bypass any security mechanisms such as IP firewalls.</t>

      <t>In IPv6-only networks that lack any IPv4 firewalls, a device
      supporting MAP could be tricked into enabling its IPv4 stack and
      direct IPv4 traffic to the attacker, thus exposing itself to
      previously infeasible IPv4 attack vectors.</t>

      <t>Section 11 of <xref target="I-D.ietf-softwire-map"></xref> discusses
      security issues of the MAP mechanism.</t>

      <t>Readers concerned with security of MAP provisioning over DHCPv6 are
      encouraged to read <xref target="I-D.ietf-dhc-sedhcpv6"/>.</t>

    </section>

    <section title="IANA Considerations">
      <t>IANA is kindly requested to allocate the following DHCPv6
      option codes:<list>
      <t>TBD1 for OPTION_S46_RULE</t>
      <t>TBD2 for OPTION_S46_BR</t>
      <t>TBD3 for OPTION_S46_DMR</t>
      <t>TBD4 for OPTION_S46_V4V6BIND</t>
      <t>TBD5 for OPTION_S46_PORTPARAMS</t>
      <t>TBD6 for OPTION_S46_CONT_MAPE</t>
      <t>TBD7 for OPTION_S46_CONT_MAPT</t>
      <t>TBD8 for OPTION_S46_CONT_LW</t>
    </list>
      All values should be added to the DHCPv6 option code space
      defined in Section 24.3 of <xref target="RFC3315"/>.</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>The authors would like to thank Bernie Volz and Tom Taylor for
      their insightful comments and suggestions.</t>
    </section>
  </middle>

  <back>
    <!--  SECTION 8.1:  Normative References		-->

    <references title="Normative References">
      &rfc3315;
<!--      &rfc3633;-->
      &rfc2119;

    </references>

    <!--  SECTION 8.2:  Informative References		-->

    <references title="Informative References">
      &rfc2473;
      &rfc2131;
      &rfc7227;
<!--      &rfc5226;-->
<!--      &rfc6335;-->
<!--      &I-D.mdt-softwire-map-deployment;-->
<!--      &I-D.ietf-homenet-arch;-->
<!--      &I-D.ietf-dhc-option-guidelines;-->
      &I-D.ietf-softwire-map;
      &I-D.ietf-softwire-lw4over6;
      &I-D.ietf-softwire-map-t;
      &I-D.ietf-dhc-sedhcpv6;
<!--      &I-D.townsley-troan-ipv6-ce-transitioning;-->
      &I-D.ietf-softwire-unified-cpe;
      &rfc6145;
    </references>
  </back>
</rfc>