[Ietf-not43] comments on FIRS

[Eric A. Hall]

on 6/15/2003 9:41 PM George Michaelson wrote:
> Eric, I think you are making a mistake arguing that the DNS is the
> vehicle to control the mapping of Internet Addresses back to their
> parent allocation blocks (which is how i read part of your response
> to Ed.)

By default, queries would be sent to the servers responsible for the top
of the delegation hierarchy (in-addr.arpa., etc). Those queries would
follow LDAP referrals to registry-specific servers for the range that was
queried, possibly following LDAP referrals to operator-specific servers.

The use of full-reverse maps are only intended to be used in those cases
where the user wants to *start* the process at the servers belonging to
the operator of a particular block, and where starting at the top of the
delegation tree would be a waste of time for the user and an unnecessary
burden on the top-level delegation servers. There are going to be some
applications which need to communicate directly with leaf-nodes -- one
possible example might be a reverse-route analyser, where the client wants
to ask a remote operator's server for its view of a route -- and there
needs to be a mechanism for performing leaf-node bootstrapping to support
these kinds of applications. In the typical case, however, clients will
usually start at the top, as described in the preceding paragraph.

[btw, the use of in-addr.arpa is a change from what is in the -01 specs
right now, which just uses the arpa TLD, but which has been changed in the
pending -02 specs after discussions with Edward].

> Reverse-DNS domain registration is a disjoint set from Allocation space
> records. While ARIN may use mechanisms in their 'inetnum' object to
> manage default DNS servers, there is no obligation to maintain a
> reverse-DNS entry, and in fact we are considering mechanisms to de-list
> people from the DNS who are lame, to try and improve global services
> (impact on the root for lame DNS is large)

That's understood and perfectly okay; it's not mutually exclusive with the
intended usage. If somebody wants to provide data on their leaf-node
server, their DNS mapping has to work in order for the server to be
located. Removing broken delegations from the parent domain would not
affect anything that wasn't broken already (this is equally true for SRV
RRs as it is for PTR RRs).

> I think all not43 candidates trying to del with addresses have to face
> up to address behaviour as allocation behaviour as a 'first class'
> data type with certain behaviours, not as a side-effect of
> DNS/domain behaviours:
> 
> 	allocations are integer ranges
> 
> 	not all allocations are CiDR aligned (but usually can be broken
>       down into CiDR equivalents)

Allocations that don't fall on CIDR boundaries are a problem for ARIN too,
and we're bouncing a couple of ideas around on this now. The problem from
my perspective is that hierarchical, non-indexed distributed partitions
have to store the lookup key in the entry name in order for them to be
locatable in the global database, and the CIDR allocations are the best
key value (and thus the best naming value for entries) for a variety of
different reasons.

The best solution to this dilemma for me personally would be to generate
your LDIF dumps to use the known CIDR allocations, regardless of how the
allocations are stored in the canonical database. Using the example that
Edward gave, that would mean creating multiple LDIF entries from the
single "NET-631-823-120-0-1" entry in the canonical database, with the
resulting ["cn=631.823.120.0/22"|"cn=631.823.124.0/23"|etc] LDIF entries
with data from the canonical entry.

While it's possible to use some kind of centralized delegation data for
some of this (such as keeping it within LDAP), that goes against the
federated approach the WG has explicitly favored, and causes unnecessary
burden for applications that want to locate a leaf-node server without
having to ask the delegation root for the information. This is especially
true for leaf-nodes that may be several delegations removed from the
top-level (eg, a server on a /29 subnet, delegated from an ISP, who
delegated from a provider, who delegated from a registry,...).

> 	allocations nest.

Nested allocations can be accomodated either directly (if they fall on
CIDR boundaries) or indirectly (as above).

> 	requests to look up allocations include
> 
> 		find immediate parent
> 			ie find the nearest thing 'above' this entry,
> 			containing this entry.
>
> 		find maximal (largest) parent
> 			ie find the largest thing 'above' this entry,
>			which may contain sub-entries which themselves
> 			nest, to this entry

Those scenarios are handled in the default case already. The matching
rules in the specs say that all entries that are superior to the address
in the assertion value must be returned. So, you could return the /8 top
allocation, a /16 sub allocation, all the way down to a /32 allocation if
you have those allocations stored in your server (and you can generaate
referrals to the operator's server if you don't have them stored).

The requirement here is that the LDAP server will need to have specific
entries for each of these address blocks (note that this may just be a
result of how you spit out LDIF files nightly or whatnot, not necessarily
how your internal database is structured).

> 		find all children

Today that could be handled with an inetAssociatedIpv[4|6]Network
attribute in the parent entry. If we we need something more robust than
that, we can define an additional matching filter that specifically
requests all of the subordinate allocations on the queried server. The
downside to that approach is more complexity at the client, in that it's
another radio button the user has to navigate. How common would this be?

It seems from the above that you have pretty much the same issues as
Edward is raising in our off-list discussion. We should bring you into the
discussion once we get a little further into it.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/