Inverse queries on EID; autoconfiguration

wollman@uvm-gen.emba.uvm.edu Tue, 13 July 1993 02:12 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28934; 12 Jul 93 22:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28930; 12 Jul 93 22:12 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17122; 12 Jul 93 22:12 EDT
Received: by thumper.bellcore.com (4.1/4.7) id <AA20072> for ietf-archive@nri.reston.va.us; Mon, 12 Jul 93 22:12:49 EDT
Received: from sadye.emba.uvm.edu by thumper.bellcore.com (4.1/4.7) id <AA20062> for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 12 Jul 93 22:12:47 EDT
Received: by sadye.emba.uvm.edu id AA03924 (5.65/1.23); Mon, 12 Jul 93 22:12:35 -0400
Date: Mon, 12 Jul 1993 22:12:35 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: wollman@uvm-gen.emba.uvm.edu
Message-Id: <9307130212.AA03924@sadye.emba.uvm.edu>
To: PIP mailing list <pip@thumper.bellcore.com>
Subject: Inverse queries on EID; autoconfiguration

Ok, I've read the new near-term document, and the new DNS document,
and I still can't figure out how you can efficiently (read: at least
as efficiently as IPv4) do inverse mapping in the DNS.  Although this
is practically useless with respect to security, it is still extremely
useful for management(*).  Since the near-term document states that 802
numbers are to be used, how would this work?  (Should I make a list of
all my 802 numbers and mail it to Paul Francis?)

I think the answer is that it wouldn't work.  Furthermore, I don't see
that Paul's stated concerns about the effect of organizational EIDs on
autoconfiguration are really borne out by reality.  Here's my model of
autoconfiguration, which is a bit different from Paul's...

1) The host is manually configured with its DNS name.

2) Host discovers network prefixes in the usual way.

3) Host /temporarily/ assigns itself an 802-based EID.

4) The host then has enough information to anycast a DNS query to the
nearest name server, asking for its correct EID.  (This could also be
done without using the DNS directly since that protocol is rather
complex.)

5) Host configures itself with the real EID and is ready for
operation.

Note in particular step (1).  All hosts have DNS names.  In my
experience, DNS names are more static than 802 numbers, and it's a lot
easier to assign a DNS name than it is to figure out an 802 number and
record it in some database somewhere.  (Usually you have to get the
host working before you can figure out what its 802 number(s) is/are.)

Given this model, it is reasonable to return to the original scenario
of organizationally-assigned EIDs, and I can breathe a sigh of relief.

OBTW, I think we really need a link-level binding document to go along
with the Near-Term document.  Reading through some of the
sections---especially the multicast bits---I began to wonder how this
is going to actually be implemented over an Ethernet...  (Is somebody
still going to re-write things to use an ESIS-like model for the
final-hop address resulution?)

Another question.  The current spec looks like the transit part
includes one or more FTIFs.  Since two systems in the same area/LAN
don't need any of this, shouldn't it be more like zero or more FTIFs?

-GAWollman

(*)For example, service providers often like to get an organizational
or geographic overview of the clients of their service.  This can
often provide useful information about whether multiple servers are
needed, etc.  It is thus important that there be an efficient
automatic procedure to convert from an incoming TCP/PIP connection to
the name of the host that originated it, even ignoring ``trusted
host'' ``security'' measures in current systems.

--
Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman      | It is a bond more powerful than absence.  We like people
UVM disagrees.       | who like Shashish.  - Claude McKenzie + Florent Vollant