dhc Group R. Droms Internet-Draft B. Volz
Expires: July 28, 2006Intended status: Informational O. Troan Expires: February 11, 2007 Cisco Systems, Inc. January 24,August 10, 2006 DHCPDHCPv6 Relay Agent Assignment Notification (RAAN) Option draft-ietf-dhc-dhcpv6-agentopt-delegate-00.txtdraft-ietf-dhc-dhcpv6-agentopt-delegate-01.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. 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 July 28, 2006.February 11, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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 The DHCP Relay Agent Assignment Notification (RAAN) option encapsulates address and prefix options to indicate that an address or prefix has been assigned. The option may also carry other information required by the network element for configuration related to the assigned address or prefix. For example, a network administrator uses the DHCP Relay Agent Assignment NotificationRAAN option to inform a 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 theit is implemented of the delegation information so the network element can add routing information about the delegated prefix into the appropriate routing protocols. 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 . The term "DHCP" in this document refers to DHCP for IPv6, as defined in RFC 3315 . The terms "DHCP prefix delegation" and "DHCP PD" refer DHCP for IPv6 prefix delegation, as defined in RFC 3633  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 The DHCP Relay Agent Assignment NotificationRAANn option carries information about assigned IPv6 addresses and prefixes. It encapsulates an IA Address option (RFC 3315) or an IA Prefix option (RFC 3633), and possibly other options that carry other information related to the assigned IPv6 address or prefix. The DHCP server MAY include this option in a Reply message sent to a client that includes assigned addresses and/or prefixes. If the DHCP server does include this option in a Reply message, it MUST include it in the option area of the Relay-reply message sent to the relay agent intended as the recipient of the option. The DHCP server is responsible for synchronizing any state created by a node through the use of the Assignment NotificationRAAN option. For example, if a DHCP server receives a Release message for a delegated prefix, it causes the node to delete any state associated with that prefix by sending an Assignment NotificationRAAN option containing an IA Prefix option with the released prefix and a valid lifetime of zero. A relay agent that receives this option SHOULD pass the information to the node in which the relay agent is instantiated. The node MAY make use of the information received from the relay agent. If a node creates state based on the information included in this option, it MUST remove that state when the lifetime as specified in the option expires. Examples of use: o Populate an ACL with an assigned IPv6 address if the network device in which the relay agent is instantiated implements a security policy limiting IPv6 forwarding to devices that have obtained an address through DHCP o Inject routing information into a routing infrastructure about a delegated prefix on behalf of a requesting router 4. Option format The DHCP Relay Agent Assignment Notification OptionRAAN option has the following format: 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-code | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encapsulated-options | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_AGENT_NOTIFY (TBD) length length of encapsulated options, in octets encapsulated-options DHCP options to be delivered by the Relay Agent Assignment Notification option 5. Encapsulating DHCP options in the DHCP Relay Agent Assignment NotificationRAAN Option The contents of options encapsulated in the DHCP Relay Agent Assignment NotificationRAAN option are interpreted according to the use of those options in the node on which the relay agent is implemented. For the purposes of address and prefix assignment, the uses of the DHCP IA Address and IA Prefix options are defined in this document. Note that the contents of these options are not necessarily the same as in the corresponding options sent to the DHCP client. For example, the node that receives the information from these options may be instructed to use the information for a shorter period of time than the client by setting a shorter valid-lifetime in the this option. 5.1. IA Address option The fields in an IA Address option (OPTION_IAADDR, option code 5) are used as follows: IPv6 address The IPv6 address assigned in this DHCP message preferred-lifetime Not used at the time this document was published valid-lifetime The expiration lifetime of the information carried in this IA Address option, expressed in units of seconds; the expiration-lifetime is a relative time, giving the duration relative to the current time of the information in this IA Address option; if the valid-lifetime is 0, the information is no longer valid. IAaddr-options Not used 5.2. IA Prefix option The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28) are used as follows: preferred-lifetime Not used valid-lifetime The expiration lifetime of the information carried in this IA Prefix option, expressed in units of seconds; the expiration-lifetime is a relative time, giving the duration relative to the current time of the information in this IA Prefix option; if the valid-lifetime is 0, the information is no longer valid. prefix-length length for this prefix in bits IPv6-prefix The IPv6 prefix assigned in this DHCP message IAprefix-options Not used at the time this document was published 6. 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. 7. Reordering received DHCP messages The relay agent MUST use the Server Reply Sequence Number (SRSN) option  to detect and discard RAAN options contained in DHCP messages that are received out of order. 8. IANA considerations IANA is requested to assign an option code from the "DHCPv6 and DHCPv6 optionsoptions" registry http://www.iana.org/assignments/dhcpv6-parameters to OPTION_AGENT_NOTIFY. 8.9. Security considerations Security issues related to DHCP are described in RFC 3315 and RFC 3633. The DHCP Relay Agent Assignment Notification OptionRAAN option may be used to mount a denial of service attack by causing a node to incorrectly populate an ACL or incorrectly configure routing protocol information for a delegated prefix. This option may also be used to insert invalid prefixes into the routing infrastruture or add invalid IP addresses to ACLs in nodes. Communication between a server and a relay agent, and communication between relay agents, can be secured through the use of IPSec, as described in section 21.1 of RFC 3315. 9.10. Changes in this revision If this section is included in the document when it is submitted for publication, the RFC Editor is requested to remove it. Changes in rev -01: o Added section describing use of "Server Reply Sequence Number" option to allow resequencing of out-of-order messages 11. Normative References  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.  Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence Number Option", draft-volz-dhc-dhcpv6-srsn-option-00 (work in progress), August 2006. Authors' Addresses Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978.936.1674 Email: firstname.lastname@example.org Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978.936.0382 Email: email@example.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: firstname.lastname@example.org 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 StatementThe 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 email@example.com. Disclaimer of Validity 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. 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.Acknowledgment Funding for the RFC Editor function is currentlyprovided by the Internet Society.IETF Administrative Support Activity (IASA).