One document matched: draft-dhankins-softwire-tunnel-option-01.xml

<?xml version='1.0' ?>

<!-- $id: $ -->

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>

<?rfc compact="yes"?> <?rfc subcompact="no"?>

<?rfc symrefs="yes"?>

<!DOCTYPE rfc SYSTEM 'rfc2629bis.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'>
]>
<rfc ipr="full3978" category="std"
     docName="draft-dhankins-softwire-tunnel-option-01">
  <front>
    <title abbrev="Softwires Option">Dynamic Host Configuration Protocol
	Option for Softwires</title>

    <author initials="D." surname="Hankins" fullname="David W. Hankins">
	<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>US</country>
	  </postal>

	  <phone>+1 650 423 1307</phone>
	  <email>David_Hankins@isc.org</email>
	</address>
    </author>

    <date month="August" year="2008"/>

    <area>Internet</area>
    <workgroup>Dynamic Host Configuration Working Group</workgroup>
    <keyword>DHCPv6 Softwires</keyword>

    <abstract>
      <t>This document describes how Softwires configuration can be obtained
	via DHCPv6.</t>
    </abstract>
  </front>

  <middle>
    <section title="Requirements Language">
      <t>In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
	"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
	described in <xref target="RFC2119">BCP 14, RFC 2119</xref>.</t>
    </section>

    <section title="Introduction">
      <t><xref target='draft-droms-softwires-snat-01'>Softwires</xref> is a
	method to extend IPv4 access to an IPv6-only addressed host.  One of
	its key components is an IPv4-over-IPv6 tunnel, but a host will not
	know if the network it is attached to offers Softwires support, and
	if it did would not know the remote end of the tunnel to establish a
	connection.</t>

      <t>These are two separate pieces of information; 1) Should I shut down
	my dual-stack IPv4 side, and use the Softwires tunnel exclusively?
	2) At what IPv6 address will I find the softwires service?</t>

      <t>These two questions can be answered with one
	<xref target='RFC3315'>DHCPv6</xref> option.</t>

      <t>DISCUSSION: It can be argued that if you inform a client it should
	perform Softwires, but fail to deliver an IPv6 tunnel endpoint, then
	its IPv4 access is certainly broken.  If you give the client an IPv6
	tunnel endpoint but fail to inform it that it must use Softwires
	support, then again its access is likely broken, or at least it isn't
	using Softwires as intended by the operator.  So the presence of a
	tunnel address also indicates the intent to use it.</t>
    </section>

    <section title='Softwires DHCPv6 Option'>
      <t>The Softwires DHCPv6 Option is simply an IPv6 address.</t>

      <figure>
	<preamble>The Softwires Option Format follows:
	</preamble>
	<artwork>
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      OPTION_SOFTWIRES (TBD)    |           length (16)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           IPv6 Address                        |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	</artwork>
	<postamble>The code for this option is TBD.  The length is precisely
		16.  The IPv6 Address field is an IPv6 address.</postamble>
      </figure>

      <t>The Softwires option MAY appear in the root scope of a DHCPv6
	packet.  It MUST NOT appear inside any IA_NA, IA_TA, IA_PD,
	IAADDR, or similar.</t>

      <t>If configured with a value, DHCPv6 servers MUST include the Softwires
	option if it appears on the client's OPTION_ORO.  A server SHOULD NOT
	include the option otherwise.</t>

      <t>A client that supports Softwires MUST include OPTION_SOFTWIRES on
	its OPTION_ORO.  There is no reasonable expectation that a server will
	reply with the Softwires option if it has not been requested.</t>

      <t>If the client receives a Softwires Option, it MUST verify the
	option length is precisely 16 octets, and ignore the option otherwise.
	Provided it is of valid length, the client SHOULD terminate or withdraw
	any <xref target='RFC2131'>DHCPv4</xref> configuration on the same
	interface.  If DHCPv4 configuration has concluded, the client SHOULD
	perform a DHCPRELEASE as it tears down its IPv4 configuration.  The
	client SHOULD establish a Softwires tunnel to the included address.</t>

      <t>DISCUSSION: The author's best understanding of the current
	epistemology on IPv6 multihoming is that the client will have IPv6
	addresses on multiple different IPv6 prefixes.  If a host is
	multihomed, then, it is strange enough to wonder how DHCPv6
	configuration will work as most DHCPv6 clients will attach to only one
	DHCPv6 server.  It is even stranger to wonder how the client would
	react if all of its multiple homes wished to provide IPv4 access via
	Softwires.  Would a client establish more than one tunnel?  Perhaps
	this option should permit multiple IPv6 addresses?</t>
    </section>

    <section title="Security Considerations">
      <t>This document does not present any new security issues, but as with
	all DHCPv6-derived configuration state, it is completely possible that
	the configuration is being delivered by a third party (Man In The
	Middle).  As such, there is no basis to trust that the access the
	Softwires connection represents can be trusted, and it should not
	therefore bypass any security mechanisms such as IP firewalls.</t>
    </section>

    <section title="IANA Considerations">
      <t>IANA is requested to allocate one DHCPv6 Option code, referencing this
	document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc2131;
      &rfc3315;

      <reference anchor='draft-droms-softwires-snat-01'>
	<front>
	  <title>Softwires Network Address Translation</title>

	  <author initials='R.' surname='Droms' fullname='Ralph Droms'>
	    <organization abbrev='CSCO'>Cisco</organization>
	  </author>
	  <author initials='B.' surname='Haberman' fullname='Brian Haberman'>
	    <organization abbrev='Unk'>Unknown</organization>
	  </author>

	  <date month='July' year='2008'/>
	</front>
      </reference>
    </references>
  </back>
</rfc>