Network Working Group Vijayabhaskar A Kalusivalingam Internet-Draft Hewlett-Packard Expires: May 2004 T. Chown University of Southampton S. Venaas UNINETT ND Support to trigger the nodes refresh the other configuration draft-vijay-ipv6-icmp-refresh-otherconf-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 Neighbor Discovery for IPv6 [RFC2461] provides a way by which the nodes can determine whether to use administered protocol for address autoconfiguration and other non-address information through M and O bits in the Router Advertisements. Though RAs can notify nodes of a change in the address prefixes, currently there is no way the nodes can learn that there is a change in the non-address configuration parameters. This will make the nodes unable to learn about new or changed configuration parameters like DNS server addresses. This specification extends the Neighbor Discovery protocol [RFC2461] to notify the nodes that the other information obtained through an administered protocol has been changed. Vijay, et. al. Expires May, 2004 [Page 1] Internet-Draft ND support to refresh other configuration Nov 2003 1. Introduction When the O bit in RAs [RFC2461] changes from FALSE to TRUE, the nodes can use the administered protocols to obtain the non-address configuration information. One such administered protocol is stateless DHCPv6 protocol [DHCPv6Light]. This is a light-weight DHCPv6 protocol in which the server manages only the non-address configuration 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. So, a renumbering event or change in some of the parameters cannot be notified to the clients by the stateless DHCPv6 server. The detailed problem description of renumbering requirements for stateless DHCPv6 can be found in [RENUMREQS]. Since the RAs can be used to notify the change in the prefixes, they can be used to solve this problem by notifying the nodes that some of the non-address configuration parameters have changed. This specification extends the Neighbor Discovery to provide a way to notify nodes that some of the non-address configuration parameters have changed and thus triggering the nodes to refresh their configuration parameters using the administered protocols. 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 as defined in "Terminology" section of the [RFC2461]. 4. Refresh Other Configuration Option The Refresh Other Configuration Option can be used in Router Advertisements to notify the nodes that one or more "Other (non-address) configuration parameters" obtained through administered protocols have changed. The format of the Refresh Other Configuration Option is as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 8-bit identifier of the option type (tbd) Length 1 (in the units of 8 octets) Vijay, et. al. Expires May, 2004 [Page 2] Internet-Draft ND support to refresh other configuration Nov 2003 Reserved 16-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Transaction-id 32-bit unsigned integer in network byte order used to differentiate between the retransmitted option from the freshly sent option. 5. Routers' Behavior The Refresh Other Configuration Option MUST NOT be used in message other than Router Advertisement ICMPv6 message. This option SHOULD NOT be sent in RAs, if O bit is unset. Once this option is enabled in RA, it SHOULD appear in the subsequent RAs for a minimum time period for better reliability. This time SHOULD be configurable in the routers. If it cannot be configurable, then RAs SHOULD contain this option till the routers are triggered to send this option with a new Transaction-id or to disable the option. 6. Nodes' Behavior If the nodes receive this option in the Router Advertisement and they are using configuration parameters obtained from the administered protocol, they MUST invoke the administered protocol to refresh their configuration parameters. There is a possibility this option could be retransmitted once again in the RAs. So, to differentiate between the retransmitted option and a newly sent option, the Transaction-id field can be used. The nodes SHOULD cache the Transaction-ids sent in this option once they invoke the administered protocol to refresh their configuration parameters. If the RAs received by the node contain this option and its Transaction-id matches with any of the entries in the cache, the nodes MUST ignore this option and they MUST not invoke the administered protocol to refresh their configuration. The nodes which are coming up when the RAs are triggering the nodes to refresh their configuration information initiate RS and get a unicast RA message with this option. In this case, if the O bit is set, the nodes SHOULD initiate the administered protocol to obtain the configuration parameters it is interested in and SHOULD cache the transaction id. Otherwise, they MUST ignore this option and they MUST not invoke the administered protocol. If both M and O bits are set, when the RAs contain this option, the nodes MAY choose to initiate administered protocol to refresh their address configuration also. 7. Operational Scenario Nodes using Stateless Autoconfiguration [RFC2462] for address configuration and configuration of non-address parameters through some administered protocol is going to be a widely used scenario. Vijay, et. al. Expires May, 2004 [Page 3] Internet-Draft ND support to refresh other configuration Nov 2003 The possible logical steps of the operational scenario are given below. 1) The administrator can trigger the RAs with O bit set to make the nodes in the link use administered protocols like DHCPv6 [DHCPv6] to obtain the non-address configuration information like DNS server addresses. 2) The site is renumbered (or) a DNS server address of the site is changed (or) a new powerful DNS server is introduced and the nodes need to configure themselves to make use of the new or additional DNS resolver. In all these cases, the nodes which had obtained DNS server addresses should be updated with new DNS configuration information. 3) In this case, either the DHCPv6 or the administrator will trigger the routers to send RAs with Refresh Other Configuration Option. The RAs can be retransmitted as per the retransmission mechanism specific to DHCPv6 for reliability. 4) Once the nodes receive the RAs with Refresh Other Configuration Option, they lookup their transaction id cache to check whether it is a new trigger for refreshing their parameters or not. If it is a new one, they initiate a new transaction with DHCPv6 to obtain updated DNS server addresses and any other configuration settings it had already obtained and update the cache with the transaction id. If it is a retransmitted one, the nodes will ignore this option. Thus, the node gets the updated DNS configuration from the DHCPv6 server. Note that DHCPv6 and DNS Server addresses are used just as an example. This mechanism can be used by any administered protocols for refreshing any configuration information, e.g. NTP server address. 8. IANA Considerations IANA is requested to assign an option code to the following options from the option-code space defined for Neighbor Discovery for IPv6 [RFC2461] options. Option Name Value Described in Refresh Other Configuration Option tbd Section 4 9. Security Considerations An intruder router/node can send RAs with Refresh Other Configuration Option and make all the nodes in the link initiate the message exchange with the administrator protocols and thus congest the network and overload the administrator protocol server. One of the ways of solving this problem is through an authentication mechanism, the nodes can use the IP authentication header in the RAs to authenticate the router. Security issues regarding the Neighbor Discovery protocol are being discussed in IETF SEND [SEND] WG. It can be used once it is ready. Vijay, et. al. Expires May, 2004 [Page 4] Internet-Draft ND support to refresh other configuration Nov 2003 10. Normative References [RFC2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP version 6", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Address Autoconfiguration", RFC 2462, December 1998. [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11. Informative References [DHCPv6Light] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October 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. [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt, June 2003. Authors' Addresses Vijayabhaskar A Kalusivalingam Hewlett-Packard STSD-I 29, Cunningham Road Bangalore - 560052 India Phone: +91-80-2053085 E-Mail: vijayak@india.hp.com Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk Vijay, et. al. Expires May, 2004 [Page 5] Internet-Draft ND support to refresh other configuration Nov 2003 Stig Venaas UNINETT Trondheim NO 7465 Norway EMail: venaas@uninett.no Vijay, et. al. Expires May, 2004 [Page 6] Internet-Draft ND support to refresh other configuration 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, et. al. Expires May, 2004 [Page 7]