Network Working Group V. Kalusivalingam Internet-Draft Cisco Systems Expires: January 30, 2005 S. Park Samsung Electronics August 2004 Multicast Reconfiguration Protocol for Stateless DHCPv6 draft-vijay-dhc-dhcpv6-mcast-reconf-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 30, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Stateless DHCPv6 is a light-weight DHCPv6 protocol in which the server manages only the service parameters like DNS server addresses, NTP server addresses etc., and hence there is no need to maintain the state of the clients, perhaps, it doesn't need to store any information about the clients at all. So, a renumbering event or change in some of the configuration parameters cannot be notified to the clients by the Stateless DHCPv6 server. This specification provides a solution for this. Kalusivalingam & Park Expires January 30, 2005 [Page 1] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 1. Introduction DHCPv6 specification [RFC3315] provides a mechanism called reconfiguration to notify the clients to update their configuration information, if there is a change in any of the configuration information. It requires the DHCPv6 server to send unicast Reconfigure messages to the individual nodes' addresses and trigger them to initiate Renew/Reply or Information-Request/Reply by which they can obtain the updated configuration information. This is not possible in [RFC3736] as the server doesn't remember the state of the client, including the address by which the client can be reached. The detailed description of this problem can be found in [I-D.ietf-dhc-stateless-dhcpv6-renumbering] . This specification makes use of the Router Advertisement messages in conjunction with O-Policy of [I-D.daniel-ipv6-ra-mo-flags] to notify the clients in the renumbered link about the configuration change. Here, the term "renumbering" means either renumbering of the whole site or change in certain service addresses/parameters. Throughout this specification DHCPv6 means Stateless DHCPv6[RFC3736] unless explicitly mentioned as Stateful DHCPv6 [RFC3315]. 2. Requirements 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 [RFC2119]. 3. Terminology This document uses terminology specific to Neighbor Discovery for IPv6 and DHCPv6 as defined in "Terminology" section of the [RFC2461] and [RFC3315] respectively. 4. Basic assumption 1. The DHCPv6 Relay resides in the default router of the link in which the client resides. It is quite normal that relay sits in the router and it is a widely deployed scenario for DHCPv4 [RFC2131]. So, this assumption is not a major concern. Even if the Relay doesn't reside in the default router of the link, it should be capable of sending Router Advertisement messages without advertising itself as a default router. 2. For the model suggested in this specification to work better, the DHCPv6 server SHOULD be configured with information about all relay agents in the DHCPv6 administrative domain. If it is not configured so, then it MUST learn about the relay agents in the DHCPv6 administrative domain. As the DHCPv6 specification [RFC3315] Kalusivalingam & Park Expires January 30, 2005 [Page 2] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 mandates authentication for reconfigure messages, it implies that the DHCPv6 server MUST learn about all the relay agents in the DHCP administrative domain to have the security association with them for IPSec. Thus, this is not a new constraint introduced by the specification. This specification just cites this constraint explicitly, which is written implicitly in the DHCPv6 specification. 3. This model won't work on the link without routers. In the absence of routers, anyhow the nodes implementing the DHCPv6 should use DHCPv6 for obtaining the IPv6 address itself. This mandates the server to maintain the state of the clients and there is already a well defined mechanism for reconfiguring the stateful DHCPv6 clients. So, the inability to work in the absence of router cannot be termed as a flaw in this specification. The solution for this is well taken care in DHCPv6 specification [RFC3315]. 5. Protocol overview If the nodes which are configured by O-Policy 2 in default find the O flag in the Router Advertisement changes from OFF to ON, they initiate Information-Request to obtain service addresses/parameters like DNS server addresses, NTP server addresses etc as described in [I-D.daniel-ipv6-ra-mo-flags] . After a period of time, for e.g., due to renumbering or introduction of a new DNS server, the administrator changes some of the configuration parameters. The server sends the reconfigure message to the DHCPv6 relay agent with the information about the link where the changes need to take effect. The DHCPv6 relay triggers the router to send Router Advertisement messages with Refresh Other Configuration Option [I-D.vijay-ipv6-icmp-refresh-otherconf], thus making all the nodes in the link to contact the server to obtain the updated configuration information using Information-Request/Reply message exchanges. If O-Policy 1 is applied for the nodes, they will invoke Stateless DHCPv6 for getting other configuration information without IPv6 address information regardless of the content of receiving Router Advertisement messages or the existence of Router Advertisement messages. In this situation, The router sends Router Advertisement messages without Refresh Other Configuration Option. Although it can expedite denial of service attacks by allowing a mischievous host to trigger Router Advertisement messages, this approach would be useful to reconfigure the Stateless DHCPv6 domain without other extended protocols. 6. Server behavior The DHCPv6 server sends the Reconfigure message to the Relay agent to make it trigger the DHCPv6 clients to contact DHCPv6 server to Kalusivalingam & Park Expires January 30, 2005 [Page 3] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 refresh their configuration parameters. 7. Creation and Sending of Reconfigure Messages to Relays The administrator decides to change some configuration information like DNS server address for the DHCPv6 domain. For simplicity let's assume there is only a single link L identified by the prefix P in the DHCPv6 domain. The server identifies the relay R which is attached to the link L. The server constructs a Reconfigure message with a non-zero transaction id generated through some random number generation mechanism or through some incremental counter, but the transaction id generator mechanism should make sure that the same value is not repeated in minimal iterations. This specification overides the DHCPv6 specification constraint of having "0" as transaction id for reconfigure message. The reason will be discussed in the following sections. The server then constructs Relay-reply as described in Section 20.3, "Construction of Relay-reply Messages" of DHCPv6 specification [RFC3315]. The values of the variable fields in the Relay-reply message are: - hop-count: 0 - link-address: Should be filled with IPv6 prefix P. - peer-address: It should be filled with 0 (unspecified address), as this message is not really destined to any client. This is a bit variation from the DHCPv6 specification, as it expects a valid IPv6 address to be used in this field. This is needed as this is the only way by which the relay can differentiate between the reconfigure message destined to specific clients and the one destined to it. The server includes a Relay Message Option [RFC3315] by encapsulating the reconfigure message in it. If the server is not able to convey the link information to the relay, then the server MUST include an Interface-id option [RFC3315] containing the information which will identify the relay's interface attached to the client's link L. This will be helpful, if the relay's interface attached to the link L is not configured with the address from prefix P. Then the server unicasts the Relay-reply message to the relay agent R on UDP port 546. Kalusivalingam & Park Expires January 30, 2005 [Page 4] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 8. Timeout and Retransmission of Reconfigure Messages to relays If the server does not receive a valid DHCP Reply message from the Relay in REC_TIMEOUT milliseconds, the server retransmits the Reconfigure message, doubles the REC_TIMEOUT value and waits again. The server continues this process until REC_MAX_RC unsuccessful attempts have been made. If there is no response from the relay and the server has information about the other relays attached to the client's link L, the server SHOULD repeat the procedure explained in Section 7,1 and 7.2 for these relays one by one, but it MUST use the same transaction-id for these messages. If it still could not get a valid reply from any of the relays, the server SHOULD abort the reconfigure process. Default and initial values for REC_TIMEOUT and REC_MAX_RC are documented in section 5.5 of DHCPv6 Specification [RFC3315]. 9. Relay behavior 9.1 Validation of the Relay-reply message If the relay receives any Relay-reply message with peer-address as unspecified address (::), then it MUST do the following validation tests. The Relay MUST ignore the Reconfigure message, if - the hop-count is not 0. - the peer-address doesn't match any of the IPv6 prefixes configured in any of the relay's interfaces and the Interface-id option is not sent. The match is done based on longest prefix match. It MUST ignore the peer-address field, if Interface-id option is sent by the server. - cannot interpret the Interface-id option and map it to one of its interface. If all these validity checks pass, then the relay should extract the reconfigure message encapsulated in the Relay Message option. The extracted transaction id in the Reconfigure message MUST be checked with the cache of transaction ids it maintains. The relay SHOULD maintain a cache of transaction ids for the Router Advertisement messages containing Refresh Other Configuration Option Kalusivalingam & Park Expires January 30, 2005 [Page 5] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 [I-D.vijay-ipv6-icmp-refresh-otherconf] it sends. Actually, the relay is not required to store the transaction-id cache, as storing only the current transaction id corresponding to the Refresh Other Configuration Option sent in the Router Advertisement messages is enough. Moreover server will make sure that transaction-id generation will be random. However, this could be used as an additional check. If the transaction id exists in the cache and it is the transaction-id corresponding to the Refresh Other Configuration Option in the current Router Advertisement message sent across the link, then the relay MUST proceed with sending the Reply message to the server instead of triggering the router to send Router Advertisement messages once again. If the transaction id doesn't exist in its cache, then the relay MUST proceed with triggering the RAs as specified below. 9.2 Triggering Router Advertisements The relay SHOULD trigger the router to include the Refresh Other Configuration Option in the Router Advertisement messages. In case of O-Policy 1, the relay SHOULD trigger the router send Router Advertisement messages without the Refresh Other Configuration Option The lower order 3 bytes of transaction-id field in the Refresh Other Configuration Option should contain transaction-id extracted from the Reconfigure message sent by the DHCPv6 server and the higher order 1 byte MUST be 0. All the remaining parameters associated with the Router Advertisement messages like prefix information, M,O bits etc., should be kept unchanged. Once the relay is able to send one successful Router Advertisement, it SHOULD add the transaction-id to its cache. Note: if O-Policy 1 is applied for the nodes, they don't process above step to generate 4-bytes transaction-id since no Refresh Other Configuration Option is used for renumbering. 9.3 Sending Reply to the DHCPv6 Server The Relay prepares an DHCP Reply message with transaction-id copied from the Reconfigure message sent by the Server. Then the relay sends the unicast DHCP Reply to the source address of the Relay-reply message sent by the server. This message is sent to UDP port 547. Kalusivalingam & Park Expires January 30, 2005 [Page 6] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 10. Client Behavior The multicast reconfiguration for Stateless DHCPv6 happens transparently to the DHCPv6 clients. The nodes running DHCPv6 client with O-Policy 1 will listen to the Router Advertisement messages and trigger the DHCPv6 client to initiate the Information-Request/Reply with the servers to obtain new updated configuration, as explained in [I-D.vijay-ipv6-icmp-refresh-otherconf]. The nodes running DHCPv6 client with O-Policy 2 will listen to the Router Advertisement messages and trigger the DHCPv6 client to initiate the Information-Request/Reply with the servers to obtain new updated configuration regardless of the Refresh Other Configuration Option. 11. Security considerations An intruder DHCPv6 server can send Reconfigure message to the Relays to make it trigger the Router Advertisement messages with Refresh Other Configuration Option frequently. This makes all the DHCPv6 clients in the link to flood the network with their requests to the server to update their configuration parameters. This will reduce the bandwidth of the network by large scale and overload the DHCPv6 servers. To avoid security attacks using this mechanism, the Relay and Server communication MUST be secured with IPSec for IPv6 as described in the Section 21.1, Security of Messages Sent Between Servers and Relay Agents, in the DHCPv6 specification [RFC3315]. SEND [I-D.ietf-send-ndopt] SHOULD be used for securing the Router Advertisement messages. 12. Conclusion Although this protocol provides a multicast solution for achieving reconfiguration using Stateless DHCPv6 server, this can fit well in the stateful model also. The DHCPv6 servers, instead unicasting the Reconfigure message to the individual nodes, can use the mechanism discussed in this specification to multicast the reconfigure message to all the clients. Thus, the reconfiguration can be done in a more efficient way. The nodes can use stateless autoconfiguration for IPv6 address allocation and DHCPv6 for obtaining configuration parameters. This is going to be the most commonly used scenario. With the Stateless DHCPv6 providing a light-weight mechanism for obtaining non-address configuration and Router Advertisement messages enhanced to notify Kalusivalingam & Park Expires January 30, 2005 [Page 7] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 the reconfiguration events to the nodes, there is absolutely no need of any service discovery mechanism to be implemented in Router Advertisement messages. The meaning of "O" Flag of Router Advertisement is being clarified in [I-D.daniel-ipv6-ra-mo-flags] and O-Policy 1 thus is able to be used for triggering Stateless DHCPv6 server on the nodes without other extended protocol like Refresh Other Configuration Option in Router Advertisement. 13. Acknowledgement The author acknowledges Tim Chown and Stig Venaas, as the original idea of this specification came out from the discussion with them. 14. References 14.1 Normative References [I-D.daniel-ipv6-ra-mo-flags] Park, S., "Consideration M and O Flags of IPv6 Router Advertisement", draft-daniel-ipv6-ra-mo-flags-00 (work in progress), July 2004. [I-D.vijay-ipv6-icmp-refresh-otherconf] Vijayabhaskar, a., "ND Support to trigger the nodes refresh the other configuration", draft-vijay-ipv6-icmp-refresh-otherconf-00 (work in progress), November 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [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. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. 14.2 Informative References [I-D.ietf-dhc-stateless-dhcpv6-renumbering] Chown, T., "Renumbering Requirements for Stateless Kalusivalingam & Park Expires January 30, 2005 [Page 8] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 DHCPv6", draft-ietf-dhc-stateless-dhcpv6-renumbering-01 (work in progress), July 2004. [I-D.ietf-send-ndopt] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 (work in progress), July 2004. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. Authors' Addresses Vijayabhaskar A Kalusivalingam Cisco Systems (India) Private Limited 9, Brunton Road Bangalore 560025 INDIA Phone: +91 80 51197777 EMail: vibhaska@cisco.com Soohong Daniel Park Mobile Platform Laboratory, Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-742 KOREA Phone: +82 31 200 4508 EMail: soohong.park@samsung.com Kalusivalingam & Park Expires January 30, 2005 [Page 9] Internet-Draft Mcast Reconf for Stateless DHCPv6 August 2004 Intellectual Property Statement 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. 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 (2004). 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 currently provided by the Internet Society. Kalusivalingam & Park Expires January 30, 2005 [Page 10]