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]