draft-ietf-softwire-ds-lite-tunnel-option-07.txt   draft-ietf-softwire-ds-lite-tunnel-option-08.txt 
Softwire D. Hankins Softwire D. Hankins
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track T. Mrugalski Intended status: Standards Track T. Mrugalski
Expires: June 13, 2011 Gdansk University of Technology Expires: July 25, 2011 Gdansk University of Technology
December 10, 2010 January 21, 2011
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-
Stack Lite Stack Lite
draft-ietf-softwire-ds-lite-tunnel-option-07 draft-ietf-softwire-ds-lite-tunnel-option-08
Abstract Abstract
This document specifies a DHCPv6 option which is meant to be used by This document specifies a DHCPv6 option which is meant to be used by
a Dual-Stack Lite Basic Bridging Broadband (B4) element to discover a Dual-Stack Lite Basic Bridging Broadband (B4) element to discover
the IPv6 address of its corresponding Address Family Transition the IPv6 address of its corresponding Address Family Transition
Router (AFTR). Router (AFTR).
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2011. This Internet-Draft will expire on July 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The AFTR-Name DHCPv6 Option . . . . . . . . . . . . . . . . . . 3 3. The AFTR-Name DHCPv6 Option . . . . . . . . . . . . . . . . . . 3
4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5 4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5
5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 5 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
skipping to change at page 5, line 8 skipping to change at page 5, line 8
The option is validated by confirming that the option-len is greater The option is validated by confirming that the option-len is greater
than 3, that the option data can be contained by the option length than 3, that the option data can be contained by the option length
(that the option length does not run off the end of the packet), that (that the option length does not run off the end of the packet), that
individual label lengths do not exceed the option length, and that individual label lengths do not exceed the option length, and that
the tunnel-endpoint-name is of valid format as described in DHCPv6 the tunnel-endpoint-name is of valid format as described in DHCPv6
Section 8 [RFC3315]; there are no compression tags, there is at least Section 8 [RFC3315]; there are no compression tags, there is at least
one label of nonzero length. one label of nonzero length.
4. DHCPv6 Server Behavior 4. DHCPv6 Server Behavior
A DHCPv6 server MUST NOT send more than one AFTR-Name option. It A DHCPv6 server SHOULD NOT send more than one AFTR-Name option. It
SHOULD NOT permit the configuration of multiple names within one SHOULD NOT permit the configuration of multiple names within one
AFTR-Name option. AFTR-Name option. Both of these conditions are handled exceptionally
by the client, so an operator using software that does not perform
these validations should be careful not to configure multiple domain
names.
RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and
server negotiate configuration values using the Option Request Option server negotiate configuration values using the Option Request Option
(OPTION_ORO). As a convenience to the reader, we mention here that a (OPTION_ORO). As a convenience to the reader, we mention here that a
server will not reply with a AFTR-Name option if the client has not server will not reply with a AFTR-Name option if the client has not
explicitly enumerated it on its Option Request Option. explicitly enumerated it on its Option Request Option.
5. DHCPv6 Client Behavior 5. DHCPv6 Client Behavior
A client that supports the B4 functionality of DS-Lite (defined in A client that supports the B4 functionality of DS-Lite (defined in
[I-D.softwire-ds-lite]) and conforms to this specification MUST [I-D.softwire-ds-lite]) and conforms to this specification MUST
include OPTION_AFTR_NAME on its OPTION_ORO. include OPTION_AFTR_NAME on its OPTION_ORO.
Because it requires DNS name to address resolution, the client MAY Because it requires DNS name to address resolution, the client MAY
also wish to include the OPTION_DNS_SERVERS [RFC3646] option on its also wish to include the OPTION_DNS_SERVERS [RFC3646] option on its
OPTION_ORO. OPTION_ORO.
If the client receives the AFTR-Name option, it MUST verify the If the client receives the AFTR-Name option, it MUST verify the
option contents as described in Section 3. option contents as described in Section 3.
If the client receives more than one AFTR-Name option, it MUST use Note that in different environments, the B4 element and DHCPv6 client
may be integrated, joined, or separated by a third pieces of
software. For the purpose of this specification, we refer to the "B4
system" when specifying implementation steps that may be processed at
any stage of integration between the DHCPv6 client software and the
B4 element it is configuring.
If the B4 system receives more than one AFTR-Name option, it MUST use
only the first instance of that option. only the first instance of that option.
If the AFTR-Name option contains more than one FQDN, as distinguished If the AFTR-Name option contains more than one FQDN, as distinguished
by the presence of multiple root labels, the client MUST use only the by the presence of multiple root labels, the B4 system MUST use only
first FQDN listed in configuration. the first FQDN listed in configuration.
The client performs standard DNS resolution using the provided FQDN The B4 system performs standard DNS resolution using the provided
to resolve a AAAA Resource Record, as defined in [RFC3596] and STD 13 FQDN to resolve a AAAA Resource Record, as defined in [RFC3596] and
[RFC1034] [RFC1035]. STD 13 [RFC1034] [RFC1035].
If any DNS response contains more than one IPv6 address, the client If any DNS response contains more than one IPv6 address, the B4
picks only one IPv6 address and uses it as a remote tunnel endpoint system picks only one IPv6 address and uses it as a remote tunnel
for the interface being configured in the current message exchange. endpoint for the interface being configured in the current message
The client MUST NOT establish more than one DS-Lite tunnel at the exchange. The B4 system MUST NOT establish more than one DS-Lite
same time per interface. For a redundancy and high availability tunnel at the same time per interface. For a redundancy and high
discussion, see Section 7.2 "High availability" of availability discussion, see Section 7.2 "High availability" of
[I-D.softwire-ds-lite]. [I-D.softwire-ds-lite].
Note that a client may have multiple network interfaces, and these Note that a B4 system may have multiple network interfaces, and these
interfaces may be configured differently; some may be connected to interfaces may be configured differently; some may be connected to
networks that call for DS-Lite, and some may be connected to networks networks that call for DS-Lite, and some may be connected to networks
that are using normal dual stack or other means. The client should that are using normal dual stack or other means. The B4 system
consider the above on an interface-by-interface basis. For example, should approach this specification on an interface-by-interface
if the client is attached to multiple networks that provide the AFTR basis. For example, if the B4 system is attached to multiple
Name option, then the client MUST configure a tunnel for each networks that provide the AFTR Name option, then the B4 system MUST
interface separately as each DS-Lite tunnel provides IPv4 configure a tunnel for each interface separately as each DS-Lite
connectivity for each distinct interface. tunnel provides IPv4 connectivity for each distinct interface.
6. Security Considerations 6. Security Considerations
This document does not present any new security issues, but as with This document does not present any new security issues, but as with
all DHCPv6-derived configuration state, it is completely possible all DHCPv6-derived configuration state, it is completely possible
that the configuration is being delivered by a third party (Man In 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 The Middle). As such, there is no basis to trust that the access the
DS-Lite Softwire connection represents can be trusted, and it should DS-Lite Softwire connection represents can be trusted, and it should
not therefore bypass any security mechanisms such as IP firewalls. not therefore bypass any security mechanisms such as IP firewalls.
 End of changes. 13 change blocks. 
27 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/