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

[Ole Trøan <[e-mail]>]

Ted,

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

draft:
   "The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast address as the destination address, 
   section 20 of [RFC3315].  If the 6rd link supports multicast [I-D.ietf-mboned-auto-multicast] the 6rd
   CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the   destination address of Relay-forward messages."

some links (e.g. 6rd) do not support IPv6 multicast.

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

I don't quite understand this concern. this draft describes how one can put together existing DHCP protocol modules to achieve support for links that do not support link-local addresses and multicast.

if we instead were to change 3315 how would a new client speak to an old server?

cheers,
Ole