Network Working Group Vijayabhaskar A Kalusivalingam Internet-Draft Hewlett-Packard Expires: May 2004 Nov 2003 Multicast Reconfiguration Protocol for Stateless DHCPv6 draft-vijay-dhc-dhcpv6-mcast-reconf-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Stateless DHCPv6 [DHCPv6Light] is a light-weight DHCPv6 [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. 1. Introduction DHCPv6 specification [DHCPv6] 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 Vijay Expires May, 2004 [Page 1] Internet-Draft Mcast Reconfig Protocol for DHCPv6Light Nov 2003 possible in stateless DHCPv6 as the server doesn't remember the state of the of the client, including the address by which the client can be reached. The detailed description of this problem can be found in [RENUMREQS]. This specification makes use of the RAs 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. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119] 3. Terminology This document uses terminology specific to Neighbor Discovery for IPv6 and DHCPv6 as defined in "Terminology" section of the [RFC2461] and [DHCPv6] respectively. 4. Basic Assumptions 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. 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 RAs 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 [DHCPv6] 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 IPv6Sec. 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 [DHCPv6]. Note: Throughout this specification DHCPv6 means stateless DHCPv6 unless or otherwise, it is explicitly mentioned as stateful DHCPv6. Vijay Expires May, 2004 [Page 2] Internet-Draft Mcast Reconfig Protocol for DHCPv6Light Nov 2003 5. Overview of the protocol If the nodes find the O flag in the RA changes form FALSE to TRUE, they initiate Information-Request to obtain service addresses/parameters like DNS server addresses, NTP server addresses etc. They can use the stateless DHCPv6 server for this. 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 RAs with Refresh Other Configuration Option [RefrOtherConf], thus making all the nodes in the link to contact the server to obtain the updated configuration information using Information-Request/Reply message exchanges. 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 refresh their configuration parameters. 6.1 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 [DHCPv6]. 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, 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. Vijay Expires May, 2004 [Page 3] Internet-Draft Mcast Reconfig Protocol for DHCPv6Light Nov 2003 The server includes a Relay Message Option [DHCPv6] 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 [DHCPv6] 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. 6.2 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 [DHCPv6] 7. Relay Behavior 7.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. Vijay Expires May, 2004 [Page 4] Internet-Draft Mcast Reconfig Protocol for DHCPv6Light Nov 2003 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 RAs containing Refresh Other Configuration Option [RefrOtherConf] 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 RAs 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 RA message sent across the link, then the relay MUST proceed with sending the Reply message to the server as described in Section 7.3 instead of triggering the router to send RAs once again. If the transaction id doesn't exist in its cache, then the relay MUST proceed with triggering the RAs as specified below. 7.2 Triggering Router Advertisements. The relay MUST trigger the router to include the Redo Service Discovery Option in the RAs. 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 RAs like prefix information, M,O bits etc., should be kept unchanged. Once the relay is able to send one successful RA, it SHOULD add the transaction-id to its cache. 7.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. 8. Client Behavior The multicast reconfiguration for stateless DHCPv6 happens transparently to the DHCPv6 clients. The nodes running DHCPv6 client will listen to the RAs and trigger the DHCPv6 client to initiate the Information-Request/Reply with the servers to obtain new updated configuration, as explained in [RefrOtherConf]. 9, Security Considerations An intruder DHCPv6 server can send Reconfigure message to the Relays to make it trigger the RAs with Refresh Other Configuration Option frequently. This makes all the DHCPv6 clients in the link to flood Vijay Expires May, 2004 [Page 5] Internet-Draft Mcast Reconfig Protocol for DHCPv6Light Nov 2003 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 [DHCPv6]. SEND [SEND] SHOULD be used for securing the RAs. 10. Conclusion 1. Although this specification 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. 2. 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 RAs enhanced to notify the reconfiguration events to the nodes, there is absolutely no need of any service discovery mechanism to be implemented in RAs. 11. Acknowledgement The author acknowledges Tim Chown and Stig Venaas, as the original idea of this specification came out from the discussion with them. 12. Normative References [RefrOtherConf] A.K. Vijayabhaskar, T. Chown, S. Venaas, "ND Support to trigger the nodes refresh the other configuration", draft-vijay-ipv6-icmp-refresh-otherconf-00 (work in progress), November 2003. [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [DHCPv6Light] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October 2003. [RFC2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP version 6", RFC 2461, December 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Vijay Expires May, 2004 [Page 6] Internet-Draft Mcast Reconfig Protocol for DHCPv6Light Nov 2003 13. Informative References [RENUMREQS] T. Chown, S. Venaas, A.K. Vijayabhaskar, " Renumbering Requirements for Stateless DHCPv6", draft-chown-dhc-stateless-dhcpv6-renumbering-00 (work in progress), November 2003. [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt, (work in progress), June 2003. Author's Address Vijayabhaskar A Kalusivalingam Hewlett-Packard STSD-I 29, Cunningham Road Bangalore - 560052 India Phone: +91-80-2053085 E-Mail: vijayak@india.hp.com Vijay Expires May, 2004 [Page 7] Internet-Draft Mcast Reconfig Protocol for DHCPv6Light Nov 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Vijay Expires May, 2004 [Page 8]