1 / 8

DHCPv4 over DHCPv6 Transport

DHCPv4 over DHCPv6 Transport. draft-ietf-dhc-dhcpv4-over-dhcpv6-02 Q. Sun , Y. Cui, M. Siodelski , S. Krishnan, I. Farrer IETF 88 th , 2013@Vancouver. Protocol Summary. Put DHCPv4 and DHCPv6 engines together, on both Server and Client sides Two new DHCPv6 msgs for conveying DHCPv4 msgs

marnin
Download Presentation

DHCPv4 over DHCPv6 Transport

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. DHCPv4 over DHCPv6 Transport draft-ietf-dhc-dhcpv4-over-dhcpv6-02 Q. Sun, Y. Cui, M. Siodelski, S. Krishnan, I. Farrer IETF 88th, 2013@Vancouver

  2. Protocol Summary • Put DHCPv4 and DHCPv6 engines together, on both Server and Client sides • Two new DHCPv6 msgs for conveying DHCPv4 msgs • Support both IPv6 multicast and unicast DHCPv4 Msg DHCPv6 Msg BOOTREQUESTV6 IPv6 DHCPv4 client engine DHCPv4 server engine BOOTREPLYV6 • DHCPv6 client engine • DHCPv6 server engine

  3. Comments during/after Berlin Meeting • Broadcast /unicast information loss – Bernie, Tomek • Background: DHCPv4 Server may distinguish the client’s state by checking the destaddr type of a pkt • REBIND -> DHCPREQUEST in broadcast • RENEW -> DHCPREQUEST in unicast • Background: RFC5010 defines Relay Agent Flags Sub-option to convey the info if a DHCPv4 relay presents • Problem: Loss information in DHCPv4 over DHCPv6 • Only DHCPv4 msgs are encapsulated without IPv4 header • Outer IPv6 header has no relationship with the information

  4. Update (Solution) • Def: Flags Field in Boot-request-v6 & Boot-reply-v6 msg • This field in Boot-reply-v6 message is reserved • Def: Unicast Flag in Boot-request-v6 message • Indicates unicast or broadcast of the original DHCPv4 msgs if in IPv4 • 1 -> unicast, 0 -> broadcast • Client needs to set this flag when sending the messages • Thanks to Bernie and Tomek for their suggestions

  5. Updates (Cont’) • Outcome of Language session in Berlin • Improve the Abstract • Describe the scenario • Briefly summarize the mechanism • Some rewording • Editorial changes

  6. Comments received recently • Use with stateless DHCPv6 => Include Enable option and 4o6 Server Address option in every client’s requests (ORO) and server’s responses • DHCPv4 over DHCPv6 service revoke => 4o6 DHCP client requests the two options in every client messages in ORO => If no Enable option, disable the DHCPv4 over DHCPv6 service => Information refresh time option (RFC4242) • Editorial suggestions

  7. Next Step • -02 version posted • No concrete changes to the current draft • Will update based on the comments => Ready for WGLC

  8. Backup • Transaction-id in DHCPv4 message is the ‘right’ xid to use rather than DHCPv6 Transaction-id • No DHCPv6 Transaction-id field in new msgs

More Related