Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

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

At Thu, 08 Jan 2015 15:52:12 +0100,
Yuri Schaeffer <[e-mail]> wrote:

> > If I understand this (and Section 6.3 in general), the following
> > "suboptimal" scenario could happen: - The Authoritative Server is
> > configured with two prefixes for optimized responses: 2001:db8::/32
> > and 2001:db8:2::/48 - The Recursive Server sends a query with
> > SOURCE of 2001:db8:1::/48 - The Authoritative Server finds the best
> > matching prefix for the SOURCE is 2001:db8::/32 and returns a
> > response corresponding to it, setting SCOPE NETMASK to 32
>
> No, I thing the authority should have responded with a scope of 47.
> That's the number of bits it needs (for this address) to make sure
> there isn't a more specific answer.
>
> Q:  2001:db8:1::/48/0
> A:  2001:db8:1::/48/47

Hmm, okay, if the definition of SCOPE is what you described, I see it
will prevent the "suboptimal" case I described above.

I hope I'm not the only person, but I suspect it's very difficult to
reach this understanding just from the current description of the
draft:

   o  SCOPE NETMASK, unsigned octet representing the length of the
      netmask pertaining to the reply.  [...
      ...] In responses, this field is set by the
      Authoritative Nameserver to indicate the coverage of the response.
[...]
   The SCOPE NETMASK in the reply indicates the netmask of the network
   for which the answer is intended.
[...]
   Conversely, a shorter SCOPE NETMASK indicates that more bits than
   necessary were provided, and the answer is suitable for a broader
   range of addresses.

[...]

> Think of scope like:
>  "I would have used N bits to come to this answer if N or more have
> been available. (for this particular block)"
> Rather than:
>  "Only the first N bits of the address are relevant"

I'm also not sure if the "would have used N bits" definition is clear
enough to get the idea.  To me, "the number of bits it needs (for this
address) to make sure there isn't a more specific answer" looks
better, and, even with this definition, I guess I'd need some specific
examples to understand it correctly.  (So I'd suggest revising the
draft with some "better" definition with helper examples)

   In the cache, any resource record in the answer section will be tied
   to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK
   fields, as detailed below.


Now, if this is the intended definition of SCOPE, I have a couple of
concerns:

- The authoritative server's implementation will be very complicated.
  Maybe this is not something we have to worry about, maybe
  existing utility libraries used for longest prefix matching are good
  and capable enough to implement the concept, and maybe
  the quality/maturity of implementations will become better over time
  anyway.  But I think it's still worth discussing whether the
  resulting behavior is worth the complexity.
- Using my server side configuration example of 2001:db8::/32 and
  2001:db8:2::/48 again.  With this definition of SCOPE and caching
  behavior at the Recursive Server, the Recursive Server would have to
  cache separate responses for all of the 64K prefixes that match
  2001:db8::/48.  Wouldn't it be too costly, even though a Recursive
  Server that supports this option is already expected to be memory
  (or cache storage in general) hog and it would manage the amount of
  total cache storage properly by, e.g., purging least used ones
  regularly?  Do we have any analysis and/or measurement results on
  the cost against the perceived benefits?

--
JINMEI, Tatuya