draft-ietf-dhc-dhcpv6-stateful-issues-02.txt   draft-ietf-dhc-dhcpv6-stateful-issues-03.txt 
Network Working Group O. Troan Network Working Group O. Troan
Internet-Draft B. Volz Internet-Draft B. Volz
Updates: 3315,3633 (if approved) Cisco Systems, Inc. Updates: 3315,3633 (if approved) Cisco Systems, Inc.
Intended status: Standards Track October 22, 2012 Intended status: Standards Track November 5, 2012
Expires: April 25, 2013 Expires: May 9, 2013
Issues with multiple stateful DHCPv6 options Issues with multiple stateful DHCPv6 options
draft-ietf-dhc-dhcpv6-stateful-issues-02.txt draft-ietf-dhc-dhcpv6-stateful-issues-03.txt
Abstract Abstract
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
with the expectation that additional stateful DHCPv6 options would be with the expectation that additional stateful DHCPv6 options would be
developed. IPv6 Prefix Options for Dynamic Host Configuration developed. IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6 shoe-horned the new options for Prefix Protocol (DHCP) version 6 shoe-horned the new options for Prefix
Delegation into DHCPv6. Implementation experience of the CPE model Delegation into DHCPv6. Implementation experience of the CPE model
described in has shown multiple issues with the DHCPv6 protocol in described in has shown multiple issues with the DHCPv6 protocol in
supporting multiple stateful options. supporting multiple stateful options.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 April 25, 2013. This Internet-Draft will expire on May 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 5, line 50 skipping to change at page 5, line 50
is only applicable to IA_NA/IA_TA, it may be problematic to make this is only applicable to IA_NA/IA_TA, it may be problematic to make this
assumption for all status codes. Ideally the Status Code option assumption for all status codes. Ideally the Status Code option
should be encapsulated in the IA option for all DHCP messages. This should be encapsulated in the IA option for all DHCP messages. This
makes Advertisement messages equal to Reply messages. makes Advertisement messages equal to Reply messages.
Proposed solution: No change. For backwards compatibility, the Proposed solution: No change. For backwards compatibility, the
NoAddrsAvail Status Code option when no addresses are available will NoAddrsAvail Status Code option when no addresses are available will
be kept in the global scope for Advertise messages. Other IA option be kept in the global scope for Advertise messages. Other IA option
types MUST encapsulate the Status Code option within the IA option. types MUST encapsulate the Status Code option within the IA option.
To clarify further: the expected Advertise message from a server when To clarify further: when a client requests both IA_NA and IA_PD, and
a client requests both address assignment (IA_NA) and prefix the server can offer IA_PD but not IA_NA, the server sends an
delegation (IA_PD) and the server can only delegate prefixes, is a Advertise response containing no IA_NA option, a status code option
Status Code Option with the NoAddrsAvail status code, no IA_NA of NoAddrsAvail, and one or more IA_PD options containing IAPREFIX
option(s), and the IA_PD option(s) with IAPREFIX option(s). options.
4.3. T1/T2 timers 4.3. T1/T2 timers
The T1 and T2 timers determine when the client will contact the The T1 and T2 timers determine when the client will contact the
server to extend lifetimes of information received in an IA. How server to extend lifetimes of information received in an IA. How
should a client handle the case where multiple IA options have should a client handle the case where multiple IA options have
different T1 and T2 timers? different T1 and T2 timers?
In a multiple IA option types model, the T1/T2 timers are protocol In a multiple IA option types model, the T1/T2 timers are protocol
timers, that should be independent of the IA options themselves. If timers, that should be independent of the IA options themselves. If
 End of changes. 4 change blocks. 
9 lines changed or deleted 9 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/