Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation - src LL vs GUA

[Alexandre Petrescu <[e-mail]>]

Le 18/10/2017 à 22:30, 神明達哉 a écrit :
> At Wed, 18 Oct 2017 22:03:26 +0200,
> Alexandre Petrescu <[e-mail]> wrote:
> 
>>>> But I need guidance to the following question: if the Client sends
>>>> a Solicit with a LL in src, MUST the Server reply to it?  (yes/no
>>>> is the needed guidance).
>>>
>>> I don't see the need for such guidance, at least as part of
>>> rfc3315bis.  What's your problem if we didn't have such guidance in
>>> normative text like a "MUST"?
>>
>> The problem is the following: exchange between Client and Server does
>> not work.  CLient believes it needs to send LL in src, whereas Server
>> believes the Client should use GUA in src.  There are other fields on
>> which the problem may reside (port number, IA_ID, and others); each
>> needs separate treatment.
> 
> To me, it's just that the server implementation is broken.  Unless the
> protocol specification explicitly imposes a limitation on the type of
> source addresses it shouldn't assume a limitation and refuse to accept
> packets that don't meet its proprietary assumption.
> 
> Now, the question is whether a protocol specification needs to
> explicitly say that a server MUST NOT have such an assumption.  I
> simply don't think so - we can't just add nearly obvious statement
> just because there is some broken implementation.  I wouldn't be
> surprised if there is a broken DNS server implementation that doesn't
> respond to a query from an IPv6 link-local address, but I just don't
> think we should write an RFC that has "a DNS server MUST NOT drop a
> query from a link-local IPv6 address" just because of such a broken
> implementation.  This case is no different from that to me.
> 
> You seem to think it's worth noting in the protocol spec, but as far
> as I can see you have not successfully convinced the wg about the need
> for it.

I can agree with you.

Alex

> 
> --
> JINMEI, Tatuya
>