Network Working Group B. Volz
Internet-Draft Ericsson
Expires: October 24, 2002 J. Bound
Compaq Computer Corporation
R. Droms
Cisco Systems
T. Lemon
Nominum, Inc.
April 25, 2002
DSTM Options for DHCP
draft-ietf-dhc-dhcpv6-opt-dstm-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 October 24, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The DSTM Global IPv4 Address option and the DSTM Tunnel Endpoint
Option provide DSTM (Dual Stack Transition Mechanism) configuration
information to DHCPv6 hosts.
Volz, et al. Expires October 24, 2002 [Page 1]
Internet-Draft DSTM Options April 2002
1. Introduction
This document describes two options for DHCPv6 [2] that provide
information for hosts using the "Dual Stack Transition Mechanism"
(DSTM) [3].
2. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC2119 [1].
3. Terminology
This document uses terminology specific to IPv6 and DHCPv6 as defined
in section "Terminology" of the DHCPv6 specification.
4. Identity Association for DSTM Global IPv4 Addresses
The Identity Association for DSTM Global IPv4 Addresses (IA_DSTM)
option is used to carry an IA, the parameters associated with the IA
and the addresses associated with the IA. All of the addresses in
this option are used by the client as DSTM Global IPv4 Addresses [3].
The format of the IA_DSTM option is:
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_IA_DSTM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_IA_DSTM (TBD)
option-len: 12 + length of IA-options field
IAID: The unique identifier for this IA; the IAID must be
unique among the identifiers for all of this client's IAs
Volz, et al. Expires October 24, 2002 [Page 2]
Internet-Draft DSTM Options April 2002
T1: The time at which the client contacts the server from
which the addresses in the IA were obtained to extend the
lifetimes of the addresses assigned to the IA; T1 is a time
duration relative to the current time expressed in units of
seconds
T2: The time at which the client contacts any available
server to extend the lifetimes of the addresses assigned to the
IA; T2 is a time duration relative to the current time expressed
in units of seconds
IA-options: Options associated with this IA.
The IA-options field encapsulates those options that are specific to
this IA. For example, all of the Address Options carrying the
addresses associated with this IA are in the IA-options field.
An IA_DSTM option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_DSTM options.
The status of any operations involving this IA is indicated in a
Status Code option in the IA-options field.
Note that an IA has no explicit "lifetime" or "lease length" of its
own. When the lifetimes of all of the addresses in an IA have
expired, the IA can be considered as having expired. T1 and T2 are
included to give servers explicit control over when a client
recontacts the server about a specific IA.
In a message sent by a client to a server, values in the T1 and T2
fields indicate the client's preference for those parameters. The
client may send 0 if it has no preference for T1 and T2. In a
message sent by a server to a client, the client MUST use the values
in the T1 and T2 fields for the T1 and T2 parameters. The values in
the T1 and T2 fields are the number of seconds until T1 and T2.
The server selects the T1 and T2 times to allow the client to extend
the lifetimes of any addresses in the IA before the lifetimes expire,
even if the server is unavailable for some short period of time.
Recommended values for T1 and T2 are .5 and .8 times the shortest
preferred lifetime of the addresses in the IA, respectively. If the
server does not intend for a client to extend the lifetimes of the
addresses in an IA, the server sets T1 and T2 to 0.
T1 is the time at which the client begins the lifetime extension
process by sending a Renew message to the server that originally
assigned the addresses to the IA. T2 is the time at which the client
starts sending a Rebind message to any server.
Volz, et al. Expires October 24, 2002 [Page 3]
Internet-Draft DSTM Options April 2002
T1 and T2 are specified as unsigned integers that specify the time in
seconds relative to the time at which the messages containing the
option is received.
A DSTM Tunnel End Point option (Section 5) MAY be encapsulated in an
IA_DSTM option to specify one or more tunnel endpoints.
5. DSTM Tunnel Endpoint Option
The DSTM Tunnel Endpoint option carries an IP address that is to be
used as a tunnel endpoint (TEP) to encapsulate IP datagrams within
IP.
The format of the DSTM Tunnel Endpoint option is:
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_DSTM_TEP | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. tep .
. (16 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DSTM_TEP (TBD)
option-length: 16
tep: Tunnel endpoint
A DSTM Tunnel EndPoint Option MUST NOT be used except when
encapsulated in an IA_DSTM option.
6. Appearance of these options
The IA_DSTM option may appear in the same messages as the IA option
and the IA_TA option [2].
A server may send a Reconfigure with an IA_DSTM option number in the
Option Request option (see sections 19 and 22.7 of the DHCP
specification [2]) to request that the client send a IA_DSTM option,
with an IAID, in the Renew message the client subsequently sends to
the server.
The DSTM Tunnel Endpoint option MUST only appear as an encapsulated
option in an IA_DSTM option.
Volz, et al. Expires October 24, 2002 [Page 4]
Internet-Draft DSTM Options April 2002
7. Security Considerations
The DSTM Global IPv4 Address option may be used by an intruder DHCP
server to assign an invalid IPv4-mapped address to a DHCPv6 client in
a denial of service attack. The DSTM Tunnel Endpoint option may be
used by an intruder DHCP server to configure a DHCPv6 client with an
endpoint that would cause the client to route packets thorugh an
intruder system.
To avoid these security hazards, a DHCPv6 client MUST use
authenticated DHCPv6 to confirm that it is exchanging the DSTM
options with an authorized DHCPv6 server.
8. IANA Considerations
IANA is requested to assign an option code to this option from the
option-code space defined in section "DHCPv6 Options" of the DHCPv6
specification [2].
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.
Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6 (work in progress), April 2002.
[3] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf-
ngtrans-dstm (work in progress), November 2001.
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
Authors' Addresses
Bernie Volz
Ericsson
959 Concord Street
Framingham, MA 01701
USA
Phone: +1 508 875 3162
EMail: bernie.volz@ericsson.com
Volz, et al. Expires October 24, 2002 [Page 5]
Internet-Draft DSTM Options April 2002
Jim Bound
Compaq Computer Corporation
ZK3-3/W20
110 Spit Brook Road
Nashua, NH 03062-2698
USA
Phone: +1 603 884 0062
EMail: Jim.Bound@compaq.com
Ralph Droms
Cisco Systems
250 Apollo Drive
Chelmsford, MA 01824
USA
Phone: +1 978 497 4733
EMail: rdroms@cisco.com
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
EMail: mellon@nominum.com
Volz, et al. Expires October 24, 2002 [Page 6]
Internet-Draft DSTM Options April 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Volz, et al. Expires October 24, 2002 [Page 7]
