As usual I'm just running my fingers here; disregard at will...
how about if the client starts with the widest granularity and narrows
down with long TTLd EGRAINSIZE responses (coded into A records)? They
would be cached locally. The EGRAINSIZE messages would go into a
currently meaningless range of dnsxl A record response codes, and such
dnsxl servers would be designed for access with new clients only.
So the lookup for 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.theory.example (a
full 128 bit 1pv6 address, by octets) would go like this, presuming
that we can safely assume that grain size will always be more than 24
bits
d.e.f.theory..?
EGRAINSIZE: variable (long TTL)
c.d.e.f.theory..?
EGRAINSIZE: variable (long TTL)
b.c.d.e.f.theory..?
EGRAINSIZE: variable (long TTL)
a.e.c.d.e.f.theory..?
EGRAINSIZE: variable (long TTL)
9.a.b.c.d.e.f.theory..?
EGRAINSIZE: 64 bits (long TTL)
this means that all distinctions smaller than that are at eight
octets, or standard 64 bit allocations.
8.9.a.b.c.d.e.f.theory..?
answer: not in list (medium TTL, or whatever the BCP is)
that way no queries that are too fine-grained ever get made, and
neither TXT records or distribution of wildcarding policies to caches
need be involved.
netmask length (aka grain size) not evenly divisible by 8 could get
represented by trivially extending this.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg