[Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt

[Shane Kerr]

David Blacka wrote:
> On Tuesday 19 August 2003 06:00 am, Shane Kerr wrote:
> 
> Excellent response, Shane.  Thanks.  My comments are in-line.
> 
> 
>>For us (RIPE NCC), nested matching means:
>>
>>- Given a range, find all the networks that contain that range; "-L" 
>>in RIPE-land, or "all supernets" in your terminology
>>
>>- Given a range, find only the most specific network that contains 
>>that range (could be multiple networks, but usually single); "-l" in 
>>RIPE-land, and the default for our servers, or "supernets" in your 
>>terminology
> 
> 
> I called this "the closest enclosing supernet", but your description is 
> quite clear.
> 
> 
>>- Given a range, find all the networks that are fully within that 
>>range; "-M" in RIPE-land, or "all subnets" in your terminology
>>
>>- Given a range, find only the least specific networks that are fully 
>>within that range; "-m" in RIPE-land, or "subnets" in your terminology
> 
> 
> Ok, is "least specific" the same thing as largest, in this context?  I 
> guess I'm not sure how to define this search.

Well, it includes the largest networks.  For instance, given this query:

193.0.0.0 - 193.0.31.255

"least-specific" is:

193.0.0.0 - 193.0.7.255
193.0.8.0 - 193.0.11.255
193.0.14.0 - 193.0.14.255
  .
  .
  .

And so on.  Note that the networks here are a /21, a /22, and a /24.

It should not find:

193.0.0.0 - 193.0.3.255

Even though this is a /22, and larger than the /24 (if you count IP's 
in the range).  Size matters, but it's not the only thing.  ;)

You could say it is the "child networks" of the network, although that 
begs the question of what a child is in this context (the definition 
below is relatively formal and complete, IMHO).

>>Exact matching means:
>>
>>- Given a range, find the network that begins and ends on the same IP 
>>addresses as the range; "-x" in RIPE-land
> 
> 
>>More details:
>>
>>-x is networks where:
>>   (start(network) = start(search)) AND
>>   (end(network) = end(search))
>>
>>For us, a "less-specific" search can return a network that is an exact 
>>match, as well as the encompassing networks:
>>
>>-L is networks where:
>>   (start(network) <= start(search)) AND
>>   (end(network) >= end(search))
>>
>>-l is all of the networks from -L, with the provisio that:
>>   no other network in the return set is contained by the network
>>
>>However, a "more-specific" search must not be an exact match:
>>
>>-M is networks where:
>>   (start(network) >= start(search)) AND
>>   (end(network) <= end(search)) AND
>>   NOT ((start(network) = start(search)) AND
>>        (end(network) = end(search)))
> 
> 
>>-m is all of the networks from -M, with the provisio that:
>>   no other network in the return set contains the network
> 
> 
> Sorry, couldn't parse that last sentence.  "no other network in the return 
> set contains the network"? which network? huh?

Maybe a diagram:

    X                                             Y 

A  |------------------|
B          |--------------------|
C                      |-------------------------|
D    |--------|
E                  |-------|
F                                    |---------|

Given these networks, if you searched with "-m" for "X - Y", you would 
get A, B, and C.  You would not get D (contained by A), E (contained 
by B) or F (contained by C).

Or look at some code:

@results = $db->selectall_arrayref(qq"
   SELECT lo_ip, hi_ip FROM networks
   WHERE (lo_ip <= $search_lo_ip) AND
         (hi_ip >= $search_ip_ip) AND
         NOT ((lo_ip == $search_lo_ip) AND hi_ip == $search_hi_ip))
   ");

for ($i=0; $i<@results; $i++) {
     for ($j=$i+1; $j<@results; $j++) {
         if (contains($results[j], $results[i])) {
             # remove network that is contained by the other
             splice(@results, $i, 1);
         }
     }
}

sub contains {
     my ($a, $b) = @_;
     return ($a->[0] <= $b->[0]) && ($a->[1] >= $b[1]) &&
            !(($a->[0] == $b->[0]) && ($a->[1] == $b->[1]));
}

>>(Note that the definition is not the best way to find the answer.)
>>
>>Any replacement for WHOIS would have to have at *least* this much 
>>expressiveness.
> 
> 
> I realize that this is currently what the RIPE WHOIS servers do, but are 
> there specific reasons why some of these rules exist?  For instance, if 
> the "more-specific" supernet search (-l) was able to return exact matches, 
> would you even need (-x)?

It's currently used in the RIPE database to do lookups (versus 
searches).  I guess there's no real need if we have intelligent 
clients, but it could reduce bandwidth consumption if nothing else in 
the case where you know what you are looking for.

Note that if you have -l return exact matches, then you MUST have a -L 
flag.  Otherwise you can't know who the parent of a given network is, 
except by trying both of these:

-l  (lo_ip-1) - hi_ip
-l  lo_ip - (hi_ip+1)

:)

>>>Also, I would sort of think that searching for network blocks (IPv4 or 
>>>IPv6) would be one of the most basic points of the service, so should 
> 
> the 
> 
>>>ability to search for them be a SHOULD?
>>
>>Agreed.
> 
> 
> This information, in some form, needs to make it into the requirements 
> document as MUSTs.  Or maybe some subset of these searches are MUSTs and 
> some are SHOULDs.

We absolutely cannot live without:

-l  (one level less specific)
-m  (one level more specific)

The client can do the -x checking on its side.

You can build -L (all less specific) and -M (all more specific) with 
these, although I don't know if it makes sense.  You'll also end up 
sending the same objects in some cases if you build them from the 
others, due to overlapping networks.  -L is a lightweight query (going 
up a tree doesn't give you much data), but -M can be very, very 
heavyweight (somebody does "-M 0.0.0.0/0" every day on our server).

So perhaps:

-l => MUST
-m => MUST
-L => SHOULD
-M => MAY
-x => SHOULD

I like -x because it's efficient.

Note that you can do more funky things, like "2nd level more specific" 
and so on.  I don't know if these are useful, especially if they can 
be constructed through use of the -l/-m operators.

-- 
Shane Kerr
RIPE NCC