--- 1/draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt 2009-02-07 04:12:03.000000000 +0100 +++ 2/draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt 2009-02-07 04:12:03.000000000 +0100 @@ -1,48 +1,55 @@ dhc Group R. Droms Internet-Draft B. Volz -Intended status: Informational O. Troan -Expires: May 31, 2007 Cisco Systems, Inc. - November 27, 2006 +Intended status: Standards Track Cisco Systems, Inc. +Expires: August 10, 2009 O. Troan + No Affiliation + February 6, 2009 DHCPv6 Relay Agent Assignment Notification (RAAN) Option - draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt + draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt 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. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and 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 May 31, 2007. + This Internet-Draft will expire on August 10, 2009. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Abstract The DHCP Relay Agent Assignment Notification (RAAN) option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients. 1. Introduction @@ -56,25 +63,26 @@ relay agent of a prefix that has been delegated through DHCP PD to a DHCP client. The relay agent notifies the network element on which it is implemented of the delegation information so the network element can add routing information about the delegated prefix into the routing infrastructure. 2. Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be - interpreted as described in RFC 2119 [1]. + interpreted as described in RFC 2119 [RFC2119]. The term "DHCP" in this document refers to DHCP for IPv6, as defined - in RFC 3315 [2]. The terms "DHCP prefix delegation" and "DHCP PD" - refer DHCP for IPv6 prefix delegation, as defined in RFC 3633 [3] + in RFC 3315 [RFC3315]. The terms "DHCP prefix delegation" and "DHCP + PD" refer DHCP for IPv6 prefix delegation, as defined in RFC 3633 + [RFC3633] Additional terms used in the description of DHCP and DHCP prefix delegation are defined in RFC 3315 and RFC 3633. In this document "assigning" an IPv6 prefix is equivalent to "delegating" a prefix. 3. Option Semantics and Usage The RAAN option carries information about assigned IPv6 addresses and prefixes. It encapsulates IA Address options (RFC 3315) and/or IA Prefix options (RFC 3633), and possibly other options that carry @@ -215,22 +224,22 @@ 8. Requesting assignment information from the DHCP server If a relay agent requires the DHCP server to provide information about assigned addresses and prefixes, it MUST include an Option Request option, requesting the Assignment Notification option, as described in section 22.7 of RFC 3315. 9. Reordering received DHCP messages The relay agent MUST use the Server Reply Sequence Number (SRSN) - option [4] to detect and discard RAAN options contained in DHCP - messages that are received out of order. + option [I-D.ietf-dhc-dhcpv6-srsn-option] to detect and discard RAAN + options contained in DHCP messages that are received out of order. 10. IANA considerations IANA is requested to assign an option code from the "DHCPv6 and DHCPv6 options" registry http://www.iana.org/assignments/dhcpv6-parameters to OPTION_AGENT_NOTIFY. 11. Security considerations @@ -253,48 +262,51 @@ Changes in rev -01: o Added section describing use of "Server Reply Sequence Number" option to allow resequencing of out-of-order messages Changes in rev -02: o Made editorial change in section 1: s/the appropriate routing protocols/the routing infrastructure/ o Updated first paragraph in Section 3 to allow multiple IA Address options and/or IA Prefix options - o Renamed section "Options Semantics and Usage" + o Renamed section 3 to "Options Semantics and Usage" o Added paragraph to section "Option Semantics and Usage" requiring that the DHCP server must include all addresses/prefixes for the client (on that link) in the RAAN option o Added list of use cases to section "Option Semantics and Usage" o Added section "Relay Agent Behavior" o Added section "Server Behavior"; moved second paragraph of section "Option Semantics and Usage" to "Server Behavior" o Updated reference to draft-ietf-dhc-dhcpv6-srsn-option-00 o Clarified descriptions of various option fields in section "Encapsulating DHCP options in the RAAN Option" + Changes in rev -03: refreshed after expiration. + 13. Normative References - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. - [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. - Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", - RFC 3315, July 2003. + [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. - [3] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host - Configuration Protocol (DHCP) version 6", RFC 3633, + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. - [4] Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence Number - Option", draft-ietf-dhc-dhcpv6-srsn-option-00 (work in - progress), November 2006. + [I-D.ietf-dhc-dhcpv6-srsn-option] + Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence + Number Option", draft-ietf-dhc-dhcpv6-srsn-option-02 (work + in progress), February 2009. Authors' Addresses Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978.936.1674 @@ -292,72 +304,24 @@ Authors' Addresses Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978.936.1674 Email: rdroms@cisco.com - Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978.936.0382 Email: volz@cisco.com - Ole Troan - Cisco Systems, Inc. - Shinjuku Mitsui Building, 2-1-1, Nishi-Shinjuku, Shinjuku-Ku - Tokyo, Kanto 163-0409 - Japan - - Phone: +81 3 5324.4027 - Email: otroan@cisco.com - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - 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 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. -Acknowledgment + Ole Troan + No Affiliation - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). + Phone: TBD + Email: TBD