Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03

Here's a question we can also ponder ...

Should we perhaps allow the server to send back the Server-Unicast option to tell the 4o6 Client where it can send unicast (DHCPv4) packets to? This would allow DHCPv4 unicast packets to be sent directly to the server (of course inside a BOOTREQUESTV6 message).

I'm not sure it is worth it (as RFC 5010 discusses issues related to server-id-override and the unicast flag addresses this).

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, November 27, 2013 2:24 PM
To: Simon Perreault; Qi Sun
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

I had suggested (perhaps privately) that at least in my mind, having a single option would be so much better.

The option can return a list of N IPv6 addresses where N can be 0.

If the option is returned with no IPv6 addresses, then it means enabled but with standard multicast.

If the option is returned with one or more addresses, then it means sent to those addresses (whether unicast or multicast - why does the sender care).

If the option is NOT returned, it means that the service is disabled.

Now, one issue against this is that it may be a bit unusual for servers to support an option with 0 or more IPv6 addresses? If that is a problem for a particular server, then one possibility is just configure it with one address - the All_DHCP_Relay_Agents_and_Servers. (I don't see a reason to prohibit this value from being included; it just isn't required as it can be implied by sending no addresses.)

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: Wednesday, November 27, 2013 1:10 PM
To: Qi Sun
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Le 2013-11-27 11:18, Qi Sun a écrit :
>> - The client MUST always include both OPTION_DHCP4_O_DHCP6_ENABLE and 
>> OPTION_DHCP4_O_DHCP6_SERVER in the ORO.
>>
>
> [Qi] RFC3315 says that the client SHOULD use unicast if instructed by 
> the server. In this document, if the client doesn't include this 
> option, it can still work (using multicast). So I think it's SHOULD 
> for the OPTION_DHCP4_O_DHCP6_SERVER.

Let me repeat: You don't want to have a server sending an option that was not requested by the client. Stay with the usual ORO model.

Please explain why deviating from the usual ORO model is warranted.

>> - The server responds with zero (if DHCPv4-over-DHCPv6 is not
>> available) or one of two options. Never both.
>>    - OPTION_DHCP4_O_DHCP6_ENABLE means "multicast".
>>    - OPTION_DHCP4_O_DHCP6_SERVER means "unicast".
>>
>> If this makes sense, then I would rename the options:
>> s/ENABLE/MULTICAST/ and s/SERVER/UNICAST/. And maybe go further and 
>> kill OPTION_DHCP4_O_DHCP6_ENABLE, and just put the multicast address 
>> in the payload of OPTION_DHCP4_O_DHCP6_SERVER.
>
> [Qi] The multicast address is a well-known address in RFC3315. The 
> client knows it even you don't tell the client. I don't think it 
> necessary to put the multicast address into the option.

I did not argue that it was necessary to tell the multicast address to the client. I did argue that it was simpler to have only one option.

>> By the way, a suggestion for the document: replace all instances of
>> "4o6 Server Address option" with the full option name, 
>> "OPTION_DHCP4_O_DHCP6_SERVER". Always using the same terminology 
>> makes it much easier to grep the document.
>
> [Qi] Thanks for the suggestion! IMHO, the "4o6 Server Address option" 
> is the name of the option, while the OPTION_DHCP4_O_DHCP6_SERVER is 
> the option code to be assigned by the IANA. What I get from RFC3315 is 
> that when you refer to an option, use the name; if you want to mention 
> the code, then use the uppercase phrase.

Sure, it is common practice, but it still makes the document harder to grep. But this is just an editorial suggestion, I don't care much. Feel free to ignore it.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg