Internet DRAFT - draft-droms-dhc-dhcpv6-agentopt-delegate

draft-droms-dhc-dhcpv6-agentopt-delegate







dhc Group                                                       R. Droms
Internet-Draft                                                   B. Volz
Expires: April 21, 2006                                         O. Troan
                                                     Cisco Systems, Inc.
                                                        October 18, 2005


            DHCP Relay Agent Assignment Notification Option
         draft-draft-droms-dhc-dhcpv6-agentopt-delegate-00.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 April 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The DHCP Relay Agent Assignment Notification 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.






Droms, et al.            Expires April 21, 2006                 [Page 1]

Internet-Draft     DHCP Assignment Notification Option      October 2005


1.  Introduction

   The DHCP Relay Agent Assignment Notification 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 Notification 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 the it 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 [1].

   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]

   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 Notification 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 Notification option.  For



Droms, et al.            Expires April 21, 2006                 [Page 2]

Internet-Draft     DHCP Assignment Notification Option      October 2005


   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 Notification 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 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






Droms, et al.            Expires April 21, 2006                 [Page 3]

Internet-Draft     DHCP Assignment Notification Option      October 2005


5.  Encapsulating DHCP options in the DHCP Relay Agent Assignment
    Notification Option

   The contents of options encapsulated in the DHCP Relay Agent
   Assignment Notification 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.




Droms, et al.            Expires April 21, 2006                 [Page 4]

Internet-Draft     DHCP Assignment Notification Option      October 2005


   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.  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.


8.  Security considerations

   Security issues related to DHCP are described in RFC 3315 and RFC
   3633.

   The DHCP Relay Agent Assignment Notification 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.  Normative References

   [1]  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.

   [3]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host



Droms, et al.            Expires April 21, 2006                 [Page 5]

Internet-Draft     DHCP Assignment Notification Option      October 2005


        Configuration Protocol (DHCP) version 6", RFC 3633,
        December 2003.


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 (2005).

   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,



Droms, et al.            Expires April 21, 2006                 [Page 6]

Internet-Draft     DHCP Assignment Notification Option      October 2005


   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

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

















Droms, et al.            Expires April 21, 2006                 [Page 7]