🚀 go-pugleaf

From: Marc T. Kaufman <kaufman@Neon.Stanford.EDU>
Date: Fri, 5 Jul 91 09:43:26 -0700
Subject: Re: Why is the ampr.org namespace flat?

	From: Bob Hoffman <hoffman@cs.pitt.edu>
	To: tcp-group@ucsd.edu
	Subject: Re: Why is the ampr.org namespace flat?
	In-Reply-To: Your message of Wed, 3 Jul 91 23:41:14 -0700
	Message-Id: <CMM.0.90.0.678723455.hoffman@speedy.cs.pitt.edu>
	
Bob Hoffman <hoffman@cs.pitt.edu> writes:
>Marc T. Kaufman <kaufman@Neon.Stanford.EDU> writes:
-> I want to
-> be wb6ece.ampr.org [44.4.0.33] whereever I may go.

>It is certainly desirable that the name be the same no matter where
>you are.  It is also easy to accomplish.

>The IP address is another matter.  If I were to move from Pitt across
>the valley to CMU, I would not be able to keep my 130.49.x.x address;
>it would have to change to 128.2.x.x.  All of the routers in the Internet
>would continue to route all 130.49 packets onto the Pitt campus.

>Names, addresses, and routes are disjoint entities, however addresses
>do imply routes.  If network 44 were fully connected, I would expect
>to send all 44.4.x.x packets to the Bay area.  If those addresses were
>permitted to move around at will, it would be a management nightmare.
>My routing table would have to have specific entries for everyone who
>wasn't in their "home" area.

I'm willing to live with the one (variable IP address) if I can have the
other (constant name), PROVIDED I don't have to do anything special,
manually, to acquire an IP address assignment when I am roaming [i.e. the
assignment must be automatic and dynamic].  I see no particular reason why
the Internet routing model MUST be the one used for 'ampr', since it was
developed with assumptions of stationary hosts and "cost center" subnets.

The direction of cellular phones should be our model:  When roaming into
new cells, the network (can) automatically learn what cell I am in, or even
what service area I am in, and will route calls to me without either having
the caller know what service area I am in, or having ME know what service
area I am in.  Cellular service started with having the caller call special
"roam" ports in the city the callee was supposed to be in.  It is now getting
to be automatic.  We should strive for the same.  When I activate my packet
station in a new city, the initial negotiation with some nameserver upon
power-up should be all that is required *OF ME* to ensure that I can be
connected to "by name".

Marc Kaufman (kaufman@Neon.stanford.edu)


----
From: emv@ox.com (Ed Vielmetti)
Date: Fri, 5 Jul 91 13:19 EDT
Subject: Re: Why is the ampr.org namespace flat?


> The IP address is another matter.  If I were to move from Pitt across
> the valley to CMU, I would not be able to keep my 130.49.x.x address;
> it would have to change to 128.2.x.x.  All of the routers in the Internet
> would continue to route all 130.49 packets onto the Pitt campus.

Not true at all, you could easily manage to keep a 130.49.x.x (CMU)
address within the Pitt campus if you tried hard enough.

You could run a fancy modern routing protocol that lets you have
disjoint subnets; I believe that OSPF has support for that.

You could use some sort of encapsulation or tunnelling so that the
datagrams get sent to the right place over some virtual circuit, then
reconstitutued out into the right form; like IP over IP, or IP over
X.25 over IP, or IP over PPP over IP, or whatever.  There's some
performance loss perhaps if you have too many layers, but you have
fast networks to play with.

There's always alternative physical access too, like making a dialup
IP connection over modems.  Take care not to get the routing goofed up
though, you'd not want to advertise that your wet piece of string is
now the best way to go across the valley on....

--Ed


----
From: Bob Hoffman <hoffman@cs.pitt.edu>
Date: Fri, 5 Jul 91 15:53:43 EDT
Subject: Re: Why is the ampr.org namespace flat?

Marc Kaufman (kaufman@Neon.stanford.edu) writes:
> I'm willing to live with the one (variable IP address) if I can have the
> other (constant name), PROVIDED I don't have to do anything special,
> manually, to acquire an IP address assignment when I am roaming [i.e. the
> assignment must be automatic and dynamic].

...

> When I activate my packet
> station in a new city, the initial negotiation with some nameserver upon
> power-up should be all that is required *OF ME* to ensure that I can be
> connected to "by name".

The paper I presented at the 1987 ARRL CNC proposes exactly this.

I only hope that our connectivity will advance to a level capable of
supporting roaming, modulo FCC content screening restrictions.

	---Bob.


----
From: Bob Hoffman <hoffman@cs.pitt.edu>
Date: Fri, 5 Jul 91 16:08:36 EDT
Subject: Re: Why is the ampr.org namespace flat?

emv@ox.com (Ed Vielmetti) writes:
> You could run a fancy modern routing protocol that lets you have
> disjoint subnets; I believe that OSPF has support for that.

Disjoint subnets are one thing, disjoint individual stations are another.
I would be interested to see how the latter would not become a management
problem.

> You could use some sort of encapsulation or tunnelling

Agreed, but is it _so_ important to keep a particular IP address?  I'm
trying to propose the simplest solution.  By changing my IP address,
nobody's routing tables have to be changed but my own, and they can
be learned automatically.

> There's always alternative physical access too, like making a dialup
> IP connection over modems.

I could also string fiber from tree to tree between here and there, but
is it _really_ worth it?

	---Bob.


----
From: Mike Chepponis <k3mc@suntan.tandem.com>
Date: Fri, 5 Jul 91 14:18:30 PDT
Subject: Re: Why is the ampr.org namespace flat?

Since Bob, N3CVL, made some comments in this discussion, I would like to point
interested readers a paper that Bob did on this subject:

"Reusable IP Addresses in a Dynamic Network", p76-77, 6th ARRL Computer
Networking Conference, Redondo Beach, CA  August 29, 1987

(I knew Bob would be too modest to point this out!)

-Mike k3mc


----
From: Mark H. Levine <yba@space.mit.edu>
Date: Fri, 5 Jul 91 11:15:02 PDT
Subject: Re: Why is the ampr.org namespace flat?

	Date: Wed, 3 Jul 91 23:41:14 -0700
	From: Marc T. Kaufman <kaufman@Neon.Stanford.EDU>
	To: tcp-group@ucsd.edu
	Subject: Re:  Why is the ampr.org namespace flat?

 I want to be wb6ece.ampr.org [44.4.0.33] whereever I may go.

 If you want geographic hierarchical addressing, use the AX-25 BBS system.
 I aspire to better things, and don't want to see us bog down in "practical
 systems" to the point that the goal becomes unattainable.

I tried to raise the issue a while back, that if this is what you want,
you may as well just use your call-sign, or choose any other unique 32-bit
serial number as if you were on a cellular telephone, because TCP-IP routing
cannot handle your goal -- gateway routing has always been able to assume
implicit network topology from your IP number.  Why not just be wb6ece
wherever you go and leave the poor IP namespace alone?

(It is hard for mood to be conveyed by email, but the question is not meant
to be facetious or rhetorical, but serious.  This looks to me like a prime
example of pounding on a sqaure peg until you have to replace it completely
with a round one to get into the round hole anyway.  If we do not ever
intend to use the rest of the internet from our ham IP stations, we ought
to make that a known constraint of the system, and we will not have to stay
with one Class A net anymore either.)

-wm1i


----
From: pabc@n5jxs.jsc.nasa.gov
Date: Fri, 05 Jul 91 17:14:07 cst
Subject: Flat ampr.org

If the cellular model is adopted, then our IP addresses would need
to be unique to the computer instead of the amateur (a class A does 
have a large address space!). Take as example VE6ATS with a base station
and a laptop in a mobile and a gateway at the "QRL". The model must
be able to handle simultaneous use of all these, not just the relocation
situation.
 
Paul Barrow, VE6ATS (pabc@n5jxs.jsc.nasa.gov)


----
From: emv@ox.com (Ed Vielmetti)
Date: Fri, 5 Jul 91 19:00 EDT
Subject: Re: Why is the ampr.org namespace flat?


Bob Hoffman and I are talking about mobile hosts.
   
   is it _so_ important to keep a particular IP address?  I'm
   trying to propose the simplest solution.  By changing my IP address,
   nobody's routing tables have to be changed but my own, and they can
   be learned automatically.

Well, there's another complication.  By changing your IP address, you
need to propogate name server information out and around the world
that lets people who know you by your name find out what address you
are currently at.

Host name to address mappings are usually relatively long-lived, on
the order of months to years.  If people are trying to find you, you
run the risk of them caching the old address, using that, and finding
no one there.  If you're moving around a lot, keeping that
name-to-address mapping up to date is going to be hard.

But it does suggest an idea...

When you move to a new area temporarily outside of your "home" address
range, get a new address that's logically part of the one where you
are.  Register a tunneling gateway [*] in your old neighborhood with a
system that will know your new home and route packets for you to where
you currently are.  If people want to address you efficiently, they'll
use the temporary address; if you want to get in touch with the home
folks, or to preserve continuity of service, the old address will
still "work" albeit slightly (or much) less efficiently.

--Ed

[*] by tunneling gateway I'm waving my hands here to say "some machine
    which will arp for your address on the local net, wrap up the
    packets it gets in some wrappers, and pass them along to your
    preconfigured new address.


----
From: pabc@n5jxs.jsc.nasa.gov
Date: Fri, 05 Jul 91 19:55:38 cst
Subject: Flat ampr.org

If the cellular model is adopted (and even if it isn't), our IP addresses
must be unique to each computer interface instead of the amateur (a
class A does have a large address space, but there are a large number
of us too). Take as example VE6ATS, with a base station, a laptop in a
mobile/portable and a gateway at the "QRL". The model used must accomodate
simultaneous use of all of these as well as the relocation problem.
 
Paul Barrow, VE6ATS (pabc@n5jxs.jsc.nasa.gov)


----
From: brian@ucsd.Edu (Brian Kantor)
Date: 6 Jul 91 05:24:48 GMT
Subject: Re: Why is the ampr.org namespace flat?


Just because we're currently using the hack of routing network 44 as
though it were a bunch of subnets doesn't mean we'll always be doing
that.  I believe that routing should be taking place at the transport
(AX.25) level, below the IP level, and that would make the IP address
space flat too.  Someday we may be able to do it.
	- Brian


----
From: --- <nt1l!aardvark@UCSD.EDU>
Date: Sat, 06 Jul 91 03:07:19 EDT
Subject: Re: Why is the ampr.org namespace flat?


It would seem to me that the only useful feature of subdomaining ampr.org
would be for mail routing.  Getting mail directly to ka9q.ampr.org directly
seems less likely than getting mail to ka9q.nj.us.ampr.org, where a local
mail host would at least know where to send nj mail.  (Sorry to pick on
you, Phil, but you were the first case to come to mind where your call
doesn't indicate what area of the country you are in.)

Besides, why couldn't you have both a "top level" and a subdomain name
for the same address (e.g., nt1l.ampr.org and nt1l.ma.us.ampr.org are
the same ip address), the latter mostly for mail routing?  Mail routers
would only need to have MX records for local sites, connecting regions
and *.ampr.org (which would go to the next node "up").  If you move,
the mail host for that area could forward your mail to your new address.

The next best (or actually better) thing would be a set of mail hosts
with reasonable connections to some decent DNS servers (could be the
same machine for any given region).  If your machine doesn't know the
destination site's IP address, it sends it to the local mail host and
lets it figure it out.  (I haven't seen any instances of mail hosts
in this area.  Are there any areas using one?)

For all other services, I'd definitely prefer the "flat" address space.
If I can't get the address from the DNS zone server for that machine, I
probably won't be able to get to the machine anyway.

Don
aardvark@nt1l.uucp
aardvark%nt1l.uucp@primerd.prime.com


----
From: ""Milo S. Medin" (NASA ARC NSI Project Office)" <medin@nsipo.arc.nasa.gov>
Date: Sat, 06 Jul 91 00:46:06 -0700
Subject: Re: Why is the ampr.org namespace flat?


Bob, I think you are overestimating the routing overhead involved.
Modern link-state routing protocols have very little overhead in
supporting routes.  OSI's IS-IS protocol in fact has no notion of
subnets.  Each host's reachability is flooded throughout the whole
area.  The overhead taken by this is pretty small in the usual case
where topology is stable.  A recent simulation of OSPF shows that
if one wanted to keep routing overhead at 5% the link bandwidth,
that OSPF could support up to 2000 routes on a 9600 baud line.
This means up to 2000 host routes as well.  

I'm not necessarily advocating this approach, but if it is the "right"
thing to do for multiple reasons, I think the overhead would be 
reasonable.  Maybe not for 1200 baud AX.25 links, but sooner or
later we have to learn hat we need to be implementing a higher
performance subnet technology than the stuff we currently have...

					thanks,
					   Milo


----
From: 70007.4651@CompuServe.COM (James C Walker(Cap'n))
Date: 6 Jul 91 14:25:08 GMT
Subject: Questions


First, I'm interested in getting source code for the latest versions of NOS
that will compile under BCC 2.0 (Borland's C++ version 2). Preferably with
all the fixes/patches in place.
 
Second, what are the latest versions and where are they available ?
Compuserve customers must now rely on decwrl.dec.com for FTP and the turn
around is *slow*.
 
Third, anyone know of the latest version of Grace Nos ?
 
Fourth, would anyone be willing/interested in uploading the latest revisions
of NOS, documentation and source code to the HAMNET forum on Compuserve ?
There's a dearth of the latest code.
 
Fifth and final, I am trying to debug a connection between my machine KC4TWU
and another (AL7FL-2) about 50 miles away. We do have an RF path. But when
any FTP or TELNET is attempted the following happens:
 
       KC4TWU -> SABM(P)
       AL7FL-2 -> UA
       KC4TUW -> [syn sent] I NR=2
       KC4TWU -> [verify sent]
       AL7FL-2 -> NR=0
 
this just loops between stations and will *not* complete the connect. The
windows are different, but experiments between local stations show this
should not make a difference.
 
       Cap


----