1 / 13

Multicast Reconfiguration Protocol for Stateless DHCPv6

Multicast Reconfiguration Protocol for Stateless DHCPv6. DHC WG @ 61 st IETF S. Daniel Park soohong.park@samsung.com. Background.

stanislaus-duscha
Download Presentation

Multicast Reconfiguration Protocol for Stateless DHCPv6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multicast Reconfiguration Protocol for Stateless DHCPv6 DHC WG @ 61st IETF S. Daniel Park soohong.park@samsung.com

  2. 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 WG @ 61st IETF

  3. 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 WG @ 61st IETF

  4. 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 WG @ 61st IETF

  5. 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 WG @ 61st IETF

  6. 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 WG @ 61st IETF

  7. 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 WG @ 61st IETF

  8. 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 WG @ 61st IETF

  9. 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 WG @ 61st IETF

  10. 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 WG @ 61st IETF

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

  12. Related Work • The related work on this draft can be found in: • http://www.ietf.org/internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt • http://ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt • M and O flag document was officially accepted as IPv6 WG item: • http://www.watersprings.org/pub/id/draft-daniel-ipv6-ra-mo-flags-01.txt DHC WG @ 61st IETF

  13. 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 ? DHC WG @ 61st IETF

More Related