[Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-0
0.txt
Eric A. Hall
ehall at ehsco.com
Thu Aug 21 23:29:40 EDT 2003
on 8/21/2003 12:58 PM Tim Christensen wrote:
> If what you are meaning is "These are named aggregates-of-netblocks
> [CIDR-expressed blocks], not the [individual] netblocks themselves", I
> would agree with that.
Yeah, that's what I mean.
>>> To exemplify, assume that we have a network delegation from
>>> 10.10.254.2 to 10.10.254.254 (this is close to a real world example
>>> in ARIN's database, details modified somewhat). It requires 13
>>> CIDR blocks to represent this single network resource (resource
>>> from the perspective of a single allocation instance). If I were
>>> to issue a query for 10.10.254.64, or even for the range
>>> 10.10.254.64 -> 10.10.254.240, I would want to know that this range
>>> is encompassed by the delegated network 10.10.254.2->254. Using
>>> the 'netblock' query model above does not permit the latter query
>>> (since itself is a multi-cidr range), and the further discussion
>>> seemed to preclude identification of the network as a single
>>> database entry (again not reflective of reality and undesirable
>>> IMO)
>>
>> The example you cited is supported in the default (with FIRS anyway).
>> Each parent netblock in the delegation path would be returned as it
>> was encountered during the chase-down to the query value.
>
> Could you amplify your response further? Let me provide context.
>
> In the example above of the range 10.10.254.2 to 10.10.254.254, the
> proper way to describe this 'network' in CIDR is:
>
> 10.10.254.2/31 + 10.10.254.4/30 + 10.10.254.8/29 +
> 10.10.254.16/28 + 10.10.254.32/27 + 10.10.254.64/26 +
> 10.10.254.128/26 + 10.10.254.192/27 + 10.10.254.224/28 +
> 10.10.254.240/29 + 10.10.254.248/30 + 10.10.254.252/31 +
> 10.10.254.254/32
>
> Now, if I search for the range 10.10.254.64 -> 10.10.254.240, I am only
> hitting nodes in cidr-sections 6,7,8,9, and 10 in my list of 13....
>
> My assertion is that the protocol should be defined such that it
> returns the network 10.10.254.2->254, because that was the closest
> aggregated network delegation. It should _not_ only return the cidr
> blocks represented by cidr-sections 6 thru 10 above, because that is an
> incomplete expression of the delegation that was delegated by the
> upstream.
>
> Similarly, if I used a single-term query such as 10.10.254.64, it would
> still return the network 10.10.254.2->254, because that node is
> encompassed in that delegated network, and to return only
> 10.10.254.64/26 mischaracterizes the delegation.
Okay I see what you're seeing, and this is different than what I thought
you were saying earlier.
> In the context above, what would FIRS return?
The inetIpvNetworkMatch query doesn't match against entries that exceed a
netblock so if you gave it 10.10.254.64 it would find the 10.10.254.64/26
entry and none of the siblings. It would find any parent netblocks that
had been created (eg 10.10.254.0/24), but since your example uses an
administrative grouping and not a netblock delegation, the matching entry
is the only one that would be returned in a fully-distributed query.
Note that the sibling entries could be returned as attribute values which
identified the other netblocks. You could also do a targetted search
against the server for the administratively grouped data. But in the
default distributed query (where the client has zero knowledge apart from
an input address), the associated entries wouldn't be located in the
distributed system using the "normal" query syntax.
As a demonstration of this, I've added the entries to goose.ehsco.com.
Point a whois client to that and issue a query for 10.10.254.64/26 (or any
address within that specific netblock), and you'll get back that entry
alone, but the data contains pointers to all of the siblings, which you
can requery for through the same interface. You can point an LDAP client
to that same server and issue a query with the searchbase of
cn=inetResources,dc=ntrg,dc=com and with the assertion value of
(&(objectclass=inetIpv4Network)(inetPrivateIdentifier=TC-NET-00)) to find
all of the netblocks associated with "TC-NET-00" private identifier.
Although it would be possible to automate such a query, it's important to
point out again that identifiers like "TC-NET-00" don't have any hierarchy
in their naming, so they cannot be used as seed values for searches
against distributed partititions. Unless the RIRs want to setup a branch
of governance to allocate identifiers (which you hopefully don't want),
that won't ever work.
> More to the point, what should the CRISP protocol call for
> $CRISP_IMPLEMENTATION demand? I believe it's more 'correct' to return
> the entire 'delegation', not just its closest CIDR sub-component.
Return all 13 detailed entries or just a pointer to the siblings? If the
latter then that's working now. It could probably stand to be cleaned up
some -- there need to be explicit sibling, parent and child attributes to
fully present what's registered, rather than relying on a generic
"associated" attribute -- but the latter part more or less works now.
> Moving on, how would I have queried the first search above in the
> following [strawman] query models (from earlier in the thread):
>
>>>> <IPv4-query begin="193.0.0.0" end="193.0.31.255"/>
>>>>
>>>> <inetnum> <first>3238002688</first> <last>3238010879</last>
>>>> </inetnum>
>>>>
>>>> <NETBLOCK><IP VAL="193.0.0.0"/><BITS VAL="19"/></NETBLOCK>
>
> The first 2 are intuitive but the last, I struggle with. Would it be
> <netblock><IP VAL="10.10.254.64"/><BITS VAL="26"/><IP
> VAL="10.10.254.128"/><BITS VAL="26"/>...<IP VAL="10.10.254.240"/><BITS
> VAL="32"/></netblock>?
In FIRS, it's just a single unit of "10.10.254.64/26".
> Ew, that's cumbersome. And requires the queryant to have
> better-than-average clue about how to express networks in CIDR
> notation.
Don't get UI stuff confused with this. It's possible to represent a
netblock by any number of mechanisms. The firs.pl demonstration client
(the one listening on goose:43) will take an address without a prefix and
take an educated guess at the appropriate network, for example. It also
handles the various hex/octal notations.
Its not hard to imagine another client having two fields:
start: [___.___.___.___]
end: [___.___.___.___]
and then try to figure out what the user wants.
The format of the vallue in the protocol message is what's important, not
the data-entry format.
> Expressing a range as a range (and not in CIDR notation) is far
> preferable, IMO.
That format also assumes that the queryant knows what the full
administrative assignment looks like.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
More information about the Ietf-not43
mailing list