draft-ietf-softwire-ds-lite-tunnel-option-08.txt   draft-ietf-softwire-ds-lite-tunnel-option-09.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: July 25, 2011 Gdansk University of Technology Expires: September 4, 2011 Gdansk University of Technology
January 21, 2011 March 3, 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-08 draft-ietf-softwire-ds-lite-tunnel-option-09
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 July 25, 2011. This Internet-Draft will expire on September 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 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 3, line 42 skipping to change at page 3, line 42
The details of how the B4 establishes an IPv4-in-IPv6 softwire to the The details of how the B4 establishes an IPv4-in-IPv6 softwire to the
AFTR are out of scope for this document. AFTR are out of scope for this document.
3. The AFTR-Name DHCPv6 Option 3. The AFTR-Name DHCPv6 Option
The AFTR-Name option consists of option-code and option-len fields The AFTR-Name option consists of option-code and option-len fields
(as all DHCPv6 options have), and a variable length tunnel-endpoint- (as all DHCPv6 options have), and a variable length tunnel-endpoint-
name field containing a fully qualified domain name that refers to name field containing a fully qualified domain name that refers to
the AFTR which the client MAY connect to. the AFTR which the client MAY connect to.
The AFTR-Name option MUST NOT appear in any other than the following The AFTR-Name option SHOULD NOT appear in any other than the
DHCPv6 messages: Solicit, Advertise, Request, Renew, Rebind, following DHCPv6 messages: Solicit, Advertise, Request, Renew,
Information-Request and Reply. Rebind, Information-Request and Reply.
The format of the AFTR-Name option is shown in the following figure: The format of the AFTR-Name option is shown in the following figure:
0 1 2 3 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 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_AFTR_NAME: (TBD) | option-len | | OPTION_AFTR_NAME: (TBD) | option-len |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| | | |
| tunnel-endpoint-name (FQDN) | | tunnel-endpoint-name (FQDN) |
skipping to change at page 4, line 47 skipping to change at page 4, line 47
+------+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+------+
| m | p | l | e | 0x03 | c | o | m | 0x00 | | m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+------+
Figure 2: Example tunnel-endpoint-name. Figure 2: Example tunnel-endpoint-name.
Note that in the specific case of the example tunnel-endpoint-name Note that in the specific case of the example tunnel-endpoint-name
(Figure 2), the length of the tunnel-endpoint-name is 18 octets, and (Figure 2), the length of the tunnel-endpoint-name is 18 octets, and
so an option-len field value of 18 would be used. so an option-len field value of 18 would be used.
The option is validated by confirming that the option-len is greater The option is validated by confirming that all of the following
than 3, that the option data can be contained by the option length conditions are met:
(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 1. the option-len is greater than 3;
the tunnel-endpoint-name is of valid format as described in DHCPv6 2. the option data can be contained by the option length (that the
Section 8 [RFC3315]; there are no compression tags, there is at least option length does not run off the end of the packet);
one label of nonzero length.
3. the individual label lengths do not exceed the option length;
4. the tunnel-endpoint-name is of valid format as described in
DHCPv6 Section 8 [RFC3315];
5. there are no compression tags;
6. there is at least one label of nonzero length.
4. DHCPv6 Server Behavior 4. DHCPv6 Server Behavior
A DHCPv6 server SHOULD 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. Both of these conditions are handled exceptionally AFTR-Name option. Both of these conditions are handled exceptionally
by the client, so an operator using software that does not perform by the client, so an operator using software that does not perform
these validations should be careful not to configure multiple domain these validations should be careful not to configure multiple domain
names. names.
skipping to change at page 6, line 11 skipping to change at page 6, line 21
The B4 system performs standard DNS resolution using the provided The B4 system performs standard DNS resolution using the provided
FQDN to resolve a AAAA Resource Record, as defined in [RFC3596] and FQDN to resolve a AAAA Resource Record, as defined in [RFC3596] and
STD 13 [RFC1034] [RFC1035]. STD 13 [RFC1034] [RFC1035].
If any DNS response contains more than one IPv6 address, the B4 If any DNS response contains more than one IPv6 address, the B4
system picks only one IPv6 address and uses it as a remote tunnel system picks only one IPv6 address and uses it as a remote tunnel
endpoint for the interface being configured in the current message endpoint for the interface being configured in the current message
exchange. The B4 system MUST NOT establish more than one DS-Lite exchange. The B4 system MUST NOT establish more than one DS-Lite
tunnel at the same time per interface. For a redundancy and high tunnel at the same time per interface. For a redundancy and high
availability discussion, see Section 7.2 "High availability" of availability discussion, see Section 12.3 "High availability" of
[I-D.softwire-ds-lite]. [I-D.softwire-ds-lite].
Note that a B4 system 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 B4 system that are using normal dual stack or other means. The B4 system
should approach this specification on an interface-by-interface should approach this specification on an interface-by-interface
basis. For example, if the B4 system is attached to multiple basis. For example, if the B4 system is attached to multiple
networks that provide the AFTR Name option, then the B4 system MUST networks that provide the AFTR Name option, then the B4 system MUST
configure a tunnel for each interface separately as each DS-Lite configure a tunnel for each interface separately as each DS-Lite
skipping to change at page 6, line 45 skipping to change at page 7, line 8
[I-D.softwire-ds-lite] discusses DS-Lite related security issues. [I-D.softwire-ds-lite] discusses DS-Lite related security issues.
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate single DHCPv6 option code referencing IANA is requested to allocate single DHCPv6 option code referencing
this document, delineating OPTION_AFTR_NAME. this document, delineating OPTION_AFTR_NAME.
8. Acknowledgements 8. Acknowledgements
Authors would like to thank Alain Durand, Rob Austein, Dave Thaler, Authors would like to thank Alain Durand, Rob Austein, Dave Thaler,
Paul Selkirk, Ralph Droms, Mohamed Boucadair and Roberta Maglione for Paul Selkirk, Ralph Droms, Mohamed Boucadair, Roberta Maglione and
their valuable feedback and suggestions. Shawn Routhier for their valuable feedback and suggestions.
This work has been partially supported by the Polish Ministry of This work has been partially supported by the Polish Ministry of
Science and Higher Education under the European Regional Development Science and Higher Education under the European Regional Development
Fund, Grant No. POIG.01.01.02-00-045/09-00 (Future Internet Fund, Grant No. POIG.01.01.02-00-045/09-00 (Future Internet
Engineering Project). Engineering Project).
9. Normative References 9. Normative References
[I-D.softwire-ds-lite] [I-D.softwire-ds-lite]
Durand, A., Ed., "Dual-stack lite broadband deployments Durand, A., Ed., "Dual-stack lite broadband deployments
 End of changes. 8 change blocks. 
18 lines changed or deleted 26 lines changed or added

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