Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

[Ted Lemon <[e-mail]>]

On Sep 26, 2012, at 9:11 AM, Ole Trøan <[e-mail]>
 wrote:
> - allow a unicast address as destination address to reach the DHCPv6 server

Huh.   How does the client know that address?   Why aren't you advertising a route to the All_DHCP_Servers multicast address down the tunnel?

> there are a few MUSTs that must be changed. equally there might be security implications, and new text for how the server should deal with on or offlink clients.

Wouldn't the security implications be the same in both cases?   You realize that RFC3315 does allow unicast to the server if it's been negotiated with the server, right?   How are the security implications different in that case than in this one?   How does putting in a fake relay agent change things?   Can't any client put in a fake relay agent, whether they are at a tunnel endpoint or not?   I can help you to work through the security considerations section if that's your only concern.

> this isn't completely different. the draft describes how this can be achieved with existing DHCPv6 servers and within current RFC3315.
> what is complicated and what is not compatible?

You have to hack the client to pretend it's a relay agent.   If this happens, you're going to wind up with clients like that all over the place, and your DHCP deployment is going to have to handle them correctly.   And then if we change RFC3315 to solve the problem the right way, then your DHCP deployment is going to have to handle both mechanisms, one of which delivers a packet with an extra relay package.