Multicast reconfiguration protocol for stateless dhcpv6
This presentation is the property of its rightful owner.
Sponsored Links
1 / 13

Multicast Reconfiguration Protocol for Stateless DHCPv6 PowerPoint PPT Presentation


  • 41 Views
  • Uploaded on
  • Presentation posted in: General

Multicast Reconfiguration Protocol for Stateless DHCPv6. DHC WG @ 61 st IETF S. Daniel Park [email protected] Background.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Multicast reconfiguration protocol for stateless dhcpv6

Multicast Reconfiguration Protocol for Stateless DHCPv6

DHC WG @ 61st IETF

S. Daniel Park

[email protected]


Background

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


Overview

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


Intention

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


Server behavior

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


Relay client behavior

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


Dhcpv6 policy 1 2

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


Dhcpv6 policy 2 2

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


Assumption

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


Advantages

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


Security considerations

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


Related work

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


Concluding remarks

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


  • Login