Multicast Reconfiguration Protocol for Stateless DHCPv6

1
Multicast Reconfiguration Protocol for Stateless
DHCPv6

• DHC WG _at_ 61st IETF
• S. Daniel Park
• soohong.park_at_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.

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
  clients 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

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 MO draft, if
  this protocol is of interest (WG Item)

5
Server Behavior

• Server sends the Relay-repl message to the Relay
  attached to the clients 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

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 clients behavior

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.

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.

9
Assumption

• The Relay resides in the same machine as router
• Even it doesnt coexist, the relay should be able
  to trigger RAs but with default router flag
  disabled
• This protocol doesnt work in the absence of IPv6
  router in the link

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

11
Security considerations

• SEND can be used to secure the RA
• Server Relay communication will be secured by
  IPSec as per RFC 3315

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-dh
  cpv6-mcast-reconf-00.txt
• M and O flag document was officially accepted as
  IPv6 WG item
• http//www.watersprings.org/pub/id/draft-daniel-ip
  v6-ra-mo-flags-01.txt

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 ?