At Thu, 08 Jan 2015 15:52:12 +0100,
Yuri Schaeffer <[email protected]> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
