DHCP Option for Proxy Server Vijayabhaskar A K DHC WG IETF 59 Seoul

DHCP Option for Proxy Server Configures proxy server addresses and their ports in the nodes Each sub option carries the list of proxy server addresses and their corresponding ports Ready for last call?

Extended Remote Boot Options for DHCPv4 Vijayabhaskar A K DHC WG IETF 59 Seoul

Requirements More than one TFTP server is needed in the case of high availability In many cases, the nodes need to obtain multiple files. TFTP usage in the remote installation is a typical case. Multiple levels of encapsulation is needed for coupling TFTP server addresses and the associated file names.

Option format The format of the Remote Boot Option is as shown below: Code Len Extended Remote Boot Information Field | TBD | N | r1 | r2 | r3 | r4 | | rN | Each and every field in this option will have: Code Len Remote Boot Information Field | 1 | N | ts | f1 | f2 | f3 | | fN | “ts” will be either TFTP server address/name. “f1” to “fn” will be the list of filenames. Ready to last call?

Remote Boot support in DHCPv6 Vijayabhaskar A K DHC WG IETF 59 Seoul

Remote Boot Support in DHCPv6 Requirement: Same as Extended Remote boot option for DHCPv4 Option format: Same as its DHCPv4 equivalent. Ready for last call?

Configured Tunnel Endpoint Option for DHCPv6 Vijayabhaskar A K DHC WG IETF 59 Seoul

Usable Scenario This option will be used by the v4/v6 router to know about the list of tunnel end points it is connected through IPv4.

Option format | OPTION_CTEP | option-len | | prefix-len | | | | | | Destination Prefix (16 bytes) | | | | | | | | | Configured TEP Address (16 bytes) | | | | | | prefix-len | | | | | | Destination Prefix (16 bytes) | | | | | | | | | | | Configured TEP Address (16 bytes) | | | | | | | |... |

Multicast Reconfiguration Protocol for Stateless DHCPv6 Vijayabhaskar A K DHC WG IETF 59 Seoul

Overview Overview Make use of the RAs to notify the clients in the renumbered link about the configuration change. -> A new option has been 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

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

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 There is no change in the client’s behavior

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

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.

Security considerations SEND can be used to secure the RAs. Server – Relay communication will be secured by IPSec as per RFC 3315

Related Work The related work on this draft can be found in: – –