1 / 18

DHCP Option for Proxy Server

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?.

axel-copeland
Download Presentation

DHCP Option for Proxy Server

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. DHCP Option for Proxy Server Vijayabhaskar A K DHC WG IETF 59 Seoul

  2. 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?

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

  4. 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.

  5. 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?

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

  7. 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?

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

  9. 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.

  10. Option format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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.

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

  18. Related Work • The related work on this draft can be found in: • http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt • http://ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt

More Related