Multicast Reconfiguration Protocol for Stateless DHCPv6 DHC 61 st IETF S. Daniel Park

DHC 61st IETF Background 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.

DHC 61st IETF Overview Make use of the RAs to notify the clients in the renumbered link about the configuration change –A new option was defined in ICMPv6 Server initiates the relay to trigger RAs in the client’s link which will in-turn trigger the clients to contact the server to obtain the updated information DHCPv6 policies along with M and O flag of RA are newly defined in IPv6 WG

DHC 61st IETF Intention This protocol is used to reconfigure stateless DHCPv6 domain in conjunction with RA This protocol should take into account of how M and O flag of RA are used and defined Reorganizing it along with a new M&O draft, if this protocol is of interest (WG Item…)

DHC 61st IETF Server Behavior Server sends the Relay-repl message to the Relay attached to the client’s link with peer-addr as :: and the encapsulated reconfigure message will have an unique xid It may include Interface-id option The server will retransmit the relay-repl message till it receives DHCP Reply from the relay

DHC 61st IETF Relay & Client Behavior When the relay receives a Relay-repl message which identifies one of its link and has an unspecified address in peer-addr field, it does: –Triggers the router to send RA with an option which carries the xid copied from encapsulated reconfigure message from the server and makes the clients to contact the server to obtain the updated information May maintain xid cache when a new option is used There is no change in the client’s behavior

DHC 61st IETF DHCPv6 Policy (1/2) 6.2 M-Policy o Policy 1 : The host should invoke Host Configuration Behaviour for address autoconfiguration (along with other configuration information) regardless of the content of received Router Advertisement messages or the existence of Router Advertisement messages. o Policy 2 : The host should invoke Host Configuration Behaviour for address autoconfiguration (along with other configuration information) if and only if it sees a Router Advertisement changing the M-Flag from FALSE to TRUE. o Policy 3 : The host should not invoke Host Configuration Behaviour for address autoconfiguration (along with other Configuration information) regardless of the content of received Router Advertisement messages or the existence of Router Advertisement messages.

DHC 61st IETF DHCPv6 Policy (2/2) 6.3 O-Policy o Policy 1 : The host should invoke Information Configuration Behaviour for getting other configuration information regardless of the content of received Router Advertisement messages or the existence of Router Advertisement messages. o Policy 2 : The host should invoke Information Configuration Behaviour for getting other configuration information if and only if it sees a Router Advertisement changing the O-Flag from FALSE to TRUE. o Policy 3 : The host should not invoke Information Configuration Behaviour for getting other configuration information regardless of the content of received Router Advertisement messages or the existence of Router Advertisement messages.

DHC 61st IETF Assumption The Relay resides in the same machine as router Even it doesn’t coexist, the relay should be able to trigger RAs but with default router flag disabled This protocol doesn’t work in the absence of IPv6 router in the link

DHC 61st IETF Advantages This mechanism can be further extended to be used in stateful DHCPv6, thus it can increase the performance This can override the need of RAs sending service parameters/addresses

DHC 61st IETF Security considerations SEND can be used to secure the RA Server – Relay communication will be secured by IPSec as per RFC 3315

DHC 61st IETF Related Work The related work on this draft can be found in: – – M and O flag document was officially accepted as IPv6 WG item: –

DHC 61st IETF Concluding remarks Reorganizing this work along with M and O flag draft, if WG needs this protocol Suggesting a reconfiguration scheme in RFC3736 without options –O-Policy 1 or 2: triggering a client to do a reconfiguration through RA –O-Policy 3: Not possible Go ahead ?