Re: [Softwires] [dhcwg] Is tunnelling DHCP multicast messages in 6rd unicast tunnel to BR acceptable for DHCP redundancy?//re: About draft-guo-softwire-6rd-ipv6-config-00

[Ted Lemon <[e-mail]>]

On Aug 19, 2010, at 1:27 AM, Xu Xiaohu wrote:
> With multicast, many DHCP authentication mechanisms will not be available
> any more, e.g., IPsec mechanism for securing the messages exchanged between
> servers and relay agents, and CGA usage for DHCP server authentication. By
> the way, is the 6rd domain deemed as a secure network for DHCP message
> exchange?

I don't see how you would use IPsec for authenticating DHCP from the client--how would the client choose a security association?   Hm, okay, maybe that works because the client has the DHCP server's IP address.   Still, this doesn't seem to fit the problem very well--the client would have to go around with a long list of server IP addresses and security associations.

If CGA authentication is one of the major goals, a solution to this would be for the client to request a unicast response.   Servers that don't implement that would respond normally; servers that do implement it would respond via unicast to the client's unicast address, and could sign their response using CGA.   The client could also send a CGA-based signature along with the message containing the unicast request--since the CGA address the client would be providing will only work if it belongs to the client, this is useful authentication.

> I admit that the DHCP relay agent on the CPE could relay the
> information-request message to ALL_SERVERS_OR_RELAY-AGENT_ADDRESS in a 6rd
> tunnel towards a 6rd BR, However, is it actually an optimal choice? 

We have to remember that "optimal" can mean a lot of different things in this context.   I agree that in principal what you are proposing is optimal in some cases, but overall, I am concerned that it creates a lot of problems for a very small benefit--thus all the questions.