Subject: [Ietf-not43] extensibility

From: Michael.Dillon at radianz.com ([email-masked])
Date: Thu Jul 17 09:32:54 2003

>One observation I've been refining is that when you look at Domain 
>registries, DNS is the most important protocol.  In the Address 
>registry realm, routing is the most important protocol.  For Domains, 
>routing, and for Address, DNS, are "optional" protocols.

Seemingly symmetrical but not really. The relationship between DNS
(Domain Name System) and Domain Name Registries is inherent. But
The relationship between routing and address registries is not. The
address registries are not involved in routing and routing can be done
and is being done without involving address registries.

>DNS has a natural hierarchy, routing doesn't.  This difference make 
>me question the FIRS definition of its name space as a basic tenet of 
>that approach.

IP Addressing has a natural hierarchy too, namely the allocation 
hierarchy.
The entire IP address space (either IPv4 or IPv6) is cut up into 
large address ranges (begin,end pairs). These ranges are delegated to
various authorities who then cut them up into smaller ranges. These
smaller ranges are delegated to network operators and large companies.
In turn they cut up their ranges into smaller ranges. 

Some, but not all, of these ranges end up as route table entries. Some of
them end up as entries in an ACL (Access Control List) or in various
other types of tables (NAT pools) in various types of network devices.

Frequently, the begin and end pair that marks out a range also corresponds
to a bit boundary in the binary form of the address. But not always. For 
eaxmple,
my company has many address ranges registered with ARIN, and two of them 
are
not proper CIDR blocks. Try a whois search on NET-65-62-0-0-1 or NET-192-199-128-0-1
at http://www.arin.net to see what I mean.

So there is hierarchy, but it is found in the allocation hierarchy where
ranges are split into several smaller ranges, and it is also found in
the delegation hierarchy, where ranges are delegated to another 
organization
who is then responsible for sub-allocating and perhaps sub-delegating. Not
all allocations are necessarily delegated, i.e. it is possible to split
a range into smaller ranges for use within a single organization.

There are analogies to the DNS here. The .com domain can delegate 
example.com to
another organization. That organization can allocate warehouse.example.com 
for
its own use and it can delegate kids.example.com to another organization. 
If you
don't believe me about the "kids" example, then look at what these folks 
http://www.centralnic.com/
are doing with uk.com, de.com, ru.com etc.

>PS - I haven't had time to really think though how this plays for 
>Routing registries.  If anyone can contribute thoughts on this, I'd 
>appreciate it.

It's worth mentioning, for those who may not be familiar with the ISP 
business, that
there are things called routing registries which are entirely separate 
from
address registries. These routing registries allow a network operator to 
publish details
on the BGP announcements that they might make. Because IP routing is a 
dynamic activity
that is intended to represent the true state of the network topology, it 
is entirely 
possible for a network to announce different sets of routes at different 
times, for instance
when a circuit goes down. The routing registry, allows a recipient of 
route announcements
to validate any particular announcement with the intention of protecting 
the routing
system against flaws in routing software, human error, or malicious 
interference with
route announcements.

There are routing registries operated by several address registries, some 
non-profit organizations
and some network operators. None of them are complete and many network 
operators don't use
any route registry at all. That may be due partially to the fact that the 
route registries use
poorly documented software that was only created for this one arcane 
purpose and therefore few
people know anything about it other than the frontline network engineers 
working for network 
operators. Something standard like LDAP or XML could help here.

--Michael Dillon

---

From: edlewis at arin.net (Edward Lewis)
Date: Fri Jul 25 16:01:54 2003

>and is being done without involving address registries.

My point wasn't clear enough evidently.  It's not that domain name 
registries are involved in DNS and that address registries are not, 
it's that the usefulness of what's being registered in each case 
depends on different protocols.  Domain names are meaningful if they 
are in DNS, addresses are meaningful if they are in route tables. 
Meaningful to the general Internet community, that is.

>IP Addressing has a natural hierarchy too, namely the allocation

That's an artifact of how the space is divided up, not how it has to be used.

Waxing theoretic for a moment, a domain name isn't an identifier so 
much as a path - a path through a database.  A domain name's labels 
direct the seeker to the location in the space where the desired data 
is.  On the other hand, an IP address is an address, just a location.

The difference is that a domain name tells you how to get to it no 
matter your starting point (step 1, go to the root, step 2, go to the 
TLD, ...).  An IP address only tells you where you want to end up, 
it's up to you to know how to get from where you are to that point. 
It's up to the routing tables to direct you - and you're view of them 
is specific to your location, not the desired address.

>ranges are split into several smaller ranges,

Perhaps there is a point here - that we are talking about locating 
the registry who would have the information.  In this case it isn't 
the address-aspect of the IP address that is important but finding an 
authority to speak to its allocation/assignment.

But:

What has raised my hackles is the thought that "reversing the flow" 
(I mean finding the 'not whois' data for something from the bottom 
up) is not the same between domain names and IP addresses.

Given a domain name, since the name is actually a path, I can see 
it's registration heritage.  I.e., placing SRV records at a specific 
location relative to the domain name is a pretty reasonable 
convention for finding where the right authority of registration 
information might lie.

This isn't so true with IP address ranges.  A limitation of DNS gives 
us essentially a choice of /16 and /24 sized zones, with the RFC 2137 
process to help a bit in un-CIDRizing this, meaning that for an 
arbitrary range, it's not so clear cut where to put the SRV-like 
pointers.  (They may need to be replicated 127 times for a /17.) 
That, and, because there's some question as to the value of the 
reverse map, esp. in IPv6, there's no guarantee that there is even a 
place to put the SRV-like things.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

...as graceful as a blindfolded bull in a china shop...

---

From: davidb at verisignlabs.com (David Blacka)
Date: Fri Jul 25 16:44:18 2003

> place to put the SRV-like things.

Let me try to restate this:  you are saying that because address allocation 
information, unlike domain allocation information, does not need DNS to 
function, and so the reverse tree is broken, clumsy or nonexistent.  Thus, 
using the reverse tree to find CRISP servers is problematic.

Did I get that right?

Assuming I did, and it seems like a reasonable conclusion to me, do you 
have a better suggestion?  do you think that all address searches should 
start from the top (i.e., just don't do SRV lookups)?

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: edlewis at arin.net (Edward Lewis)
Date: Fri Jul 25 17:11:05 2003

>using the reverse tree to find CRISP servers is problematic.

Dang close.  s/reverse tree is/reverse tree could be and in some cases is/

>start from the top (i.e., just don't do SRV lookups)?

I don't have a suggestion at this point, I'm still new to the problem 
and my belief/theory that there's a significant difference lurking 
here.  I wish I had a suggestion.

Perhaps yes to the latter question.  It's fairly clear to go to the 
source of the authority and ask "who did you give it to" and chase 
the chain of custody than reverse the path.  One reason - you can't 
rely on there being a reverse DNS for the space.  Another reason is 
with the way addresses can be reassigned and used, it's not easy to 
reverse the path.  E.g., I (as a registry) may allocate to you (as 
operator) 5 IP prefixes and 5 AS numbers, but I can't tell how you 
mix and match them.  (I'd need to look into the route tables to see.)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Jul 25 17:39:12 2003

on 7/25/2003 4:11 PM Edward Lewis wrote:

> rely on there being a reverse DNS for the space.

This is how FIRS works with ASNs and IP addresses. Find the LDAP server
for asn.arpa, in-addr.arpa, etc., and follow the in-band referrals down.
DNS isn't being used everywhere, just for bootstrapping the query.

But having said that, DNS is still being used as the delegation
*authority* for the query, since the DNS information has control.

Separately, if this is trustworthy and reliable for finding the ~default
servers, then there's no reason not to use the same approach for finding
other partitions (eg, private route servers, or whatever).

> Another reason is 
> reverse the path. 

The only time you'd WANT to ask a specific server for its view of a piece
of data is because you have an application that knows it can benefit from
that data. As such, that application (which may just be your own personal
habit rather than a piece of code) would have to be wired to know "go ask
this partition for information about the resource".

All of that is only going to work if the delegation entries exist and are
functional. If the delegation entries don't work, you can't ask that
server for anything anyway.

Working delegations are only needed if you plan to offer a service at the
partition that is linked to the domain name in question. The other 99% of
the delegations don't even have to exist, much less be functional. If
nobody ever asks them for anything, who cares.

Now then, once there is a broad base of data ~out there, then I expect
that there will be more user-to-user applications, and those WOULD require
working delegations to function. It may be that using something like a
route server would make more sense than using DNS, but I'd want to discuss
this in the context of specific applications. In the general case, a
delegation is a delegation is a delegation.

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