At Thu, 08 Jan 2015 15:52:12 +0100, Yuri Schaeffer <y...@nlnetlabs.nl> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop