Dynamic Host Configuration Working D. Hankins
Group ISC
Internet-Draft August 11, 2008
Intended status: Standards Track
Expires: February 12, 2009
Dynamic Host Configuration Protocol Option for Softwires
draft-dhankins-softwire-tunnel-option-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 12, 2009.
Abstract
This document describes how Softwires configuration can be obtained
via DHCPv6.
Hankins Expires February 12, 2009 [Page 1]
Internet-Draft Softwires Option August 2008
Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Softwires DHCPv6 Option . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . . . 6
Hankins Expires February 12, 2009 [Page 2]
Internet-Draft Softwires Option August 2008
1. Requirements Language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119].
2. Introduction
Softwires [draft-droms-softwires-snat-01] 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.
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?
These two questions can be answered with one DHCPv6 [RFC3315] option.
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.
3. Softwires DHCPv6 Option
The Softwires DHCPv6 Option is simply an IPv6 address.
The Softwires Option Format follows:
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for this option is TBD. The length is precisely 16. The
Hankins Expires February 12, 2009 [Page 3]
Internet-Draft Softwires Option August 2008
IPv6 Address field is an IPv6 address.
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.
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.
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.
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 DHCPv4 [RFC2131] 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.
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?
4. Security Considerations
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.
5. IANA Considerations
IANA is requested to allocate one DHCPv6 Option code, referencing
this document.
Hankins Expires February 12, 2009 [Page 4]
Internet-Draft Softwires Option August 2008
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[draft-droms-softwires-snat-01]
Droms, R. and B. Haberman, "Softwires Network Address
Translation", July 2008.
Author's Address
David W. Hankins
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
US
Phone: +1 650 423 1307
Email: David_Hankins@isc.org
Hankins Expires February 12, 2009 [Page 5]
Internet-Draft Softwires Option August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Hankins Expires February 12, 2009 [Page 6]