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

[神明達哉 <[e-mail]>]

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.

--
JINMEI, Tatuya