Re: [dhcwg] about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

>  > => all the relays forward to all the configured servers, for responses
>  > they are sent to relays so there is no further duplication.
>  So you believe this is especially harmful in the over-IPv6 context?

=> no and BTW this is what you want when you have many relays to
serve the same link, or configure a relay with many server addresses.

>  I'm sorry that I'm still a little lost...
>  Could you explain why and how the flag you proposed work? Thanks

=> as the same code is able to serve the colocated client or the
whole link, IMHO a flag is required so the administrator is able
to choose between the two available scopes of service.
Now about the way to implement it: check if the query comes
from the same box or not.

>  > => it is good but it breaks the second usage so it won't work...
>  Sorry, apologize that I misunderstand what you point in the previous mail.
>  Here are some thoughts on this issue,
>  1)For the case of CRA co-locating with host, this should not be an
>  issue because we'll use IPv6 unicast, no matter what is written in
>  this field. We should state it in the draft.

=> you miss the point: some clients use the server-identifier to
unicast in IPv4 the request to the server (i.e., to the IPv4 /
the content of the server-identifier option).
So it is no related to the scope of the CRA service.

>  For the case of CRA on the link:
>  2)Make it mandatory that the client send out DHCP message in broadcast
>  manner in this scenario, or

=> you can't change the behavior of the DHCPv4 client.

>  3)Make the CRA to be the gateway and relay unicast DHCP messages;

=> it doesn't work: nothing can be the IPv4 gateway for just a given
protocol and port.

Regards

[e-mail]

PS: for anybody who is lost, the issue is the second part of:
  "The 'server identifier' field is used both to identify a DHCP server
   in a DHCP message and as a destination address from clients to
   servers."
when you want to run the whole DHCPv4 protocol exchange(s) over
a not IPv4 transport.