Re: DIALUP SLIP cont...

[mikebw@bilow.bilow.uu.ids.net (Mike Bilow)]

On 94 Dec 31 at 01:48, Michael Stenner <mstenner@haven.uniserve.com> wrote:

MB>>I must respectfully disagree with you about this.  NOTHING 
MB>>at Internic links "AMPR.ORG" with any IP address, whether in 
MB>>the 44.x.x.x Class-A net or not.

 MS> On this, we have agreed to disagree...   The proof is in 
 MS> the pudding Mike.  Any datagrams from Internet to 
 MS> "ampr.org" WILL be forwarded by Internic to the domain 
 MS> servers at UCSD.EDU and NOSC.MIL.  This being the case, 
 MS> there must be something that links ampr.org and the 44 
 MS> domain.

Look, I don't mean to be rude, but you have got a fundamental misconception of
how TCP/IP works.  Datagram routing has nothing to do with domain names or
domain name servers.  Datagrams destined for a host in AMPR.ORG are never
actually routed or forwarded or touched by UCSD.EDU or TROUT.NOSC.MIL, which
are the authoritative domain name servers for the AMPR.ORG domain.  Rather,
datagrams for any address in Net 44 are routed by the Internet to a completely
different machine unrelated to domain name service, specifically
MIRRORSHADES.UCSD.EDU.

It is important to understand that datagrams contain the IP address of their
destination, and are routed based on this IP address.  They are called
"datagrams" because every single IP frame is self-contained as far as routers
are concerned, and can be routed to its next stop without regard to anything
other than than the local IP routing table on each router.

Domain name servers may be queried for mapping information in order to get
these IP addresses, but the mapping from domain names to IP addresses is
considered to be entirely temporary.  If such a mapping is discovered, it is
known only to the originator of the IP frames, and is not known to the routers
of IP frames along the way.

 MS> Further if these were only resource records, the 
 MS> following test shouldn't work...

 MS> TRY THIS TEST: From "Internet", telnet to "hamgate.n8khn.ampr.org".
 MS> Here too, the link (even one hidden "behind the curtain")
 MS> can be proven; hence, the importance for a gateway
 MS> sysop to limit internet access to other 44.x.x.x systems.
 MS> (BTW, I don't think you'll find hamgate.n8khn.ampr.org
 MS> listed in too many "Internet" tables.)

 MS> In standard Internet fashion, the mnemonic routing is
 MS> converted to an IP number.  Because there is only one
 MS> way into the 44 domain, the Internet then directs all "44"
 MS> datagrams to the 44 domain servers.

You have got this confused.  When a human issues a command such as "telnet
hamgate.n8khn.ampr.org," the machine he is on initiates a domain name service
query that is most likely answered by UCSD.EDU or TROUT.NOSC.MIL.  One of those
authoritative name servers replies that the domain "hamgate.n8khn.ampr.org" is
mapped to an IP address:

# nslookup /type=a /debug hamgate.n8khn.ampr.org.
------------
Server:  LOCALHOST
Address:  127.0.0.1

------------
Got answer:
    HEADER:
    opcode = QUERY, id = 3, rcode = NOERROR
    header flags:  response, auth. answer, want recursion, recursion avail.
    questions = 1,  answers = 1,  authority records = 3,  additional = 5

    QUESTIONS:
    HAMGATE.N8KHN.AMPR.ORG, type = A, class = IN
    ANSWERS:
    ->  HAMGATE.N8KHN.AMPR.ORG
    internet address = 44.125.128.131
    ttl = 864000 (10 days)
    AUTHORITY RECORDS:
    ->  AMPR.ORG
    nameserver = ucsd.edu
    ttl = 864000 (10 days)
    ->  AMPR.ORG
    nameserver = trout.nosc.mil
    ttl = 864000 (10 days)
    ->  AMPR.ORG
    nameserver = hpcsos.col.hp.com
    ttl = 864000 (10 days)
    ADDITIONAL RECORDS:
    ->  ucsd.edu
    internet address = 132.239.254.201
    ttl = 86400 (1 days)
    ->  ucsd.edu
    internet address = 132.239.1.1
    ttl = 86400 (1 days)
    ->  ucsd.edu
    internet address = 128.54.16.1
    ttl = 86400 (1 days)
    ->  trout.nosc.mil
    internet address = 128.49.16.7
    ttl = 367898 (4 days 6 hours 11 mins 38 secs)
    ->  hpcsos.col.hp.com
    internet address = 15.255.240.16
    ttl = 48807 (13 hours 33 mins 27 secs)

------------
Name:    HAMGATE.N8KHN.AMPR.ORG
Address:  44.125.128.131

This debug trace of a name resolution lookup tells us that domain
"hamgate.n8khn.ampr.org" is mapped, by authority of one of the authoritative
domain name servers for AMPR.ORG, to IP address 44.125.128.131, and that this
address may be cached by my machine for 10 days.  The domain name server also
helpfully supplies the IP address records for the authoritative domain name
servers themselves, none of which are in Net 44.

Now that the domain name is resolved to an IP address, which does happen to be
in Net 44, we can send frames to it without any further reference to domain
name service:

# traceroute /max=20 44.125.128.131
traceroute to 44.125.128.131, 20 hops max, 38 byte packets
 1  inet-gw.ids.net (155.212.1.20)  0 ms  0 ms  0 ms
 2  sl-pen-4-S2/3-T1.sprintlink.net (144.228.64.77)  10 ms  30 ms  10 ms
 3  sl-pen-1-F0/0.sprintlink.net (144.228.60.1)  10 ms  10 ms  20 ms
 4  sl-dc-6-H2/0-T3.sprintlink.net (144.228.10.33)  40 ms  20 ms  40 ms
 5  sl-dc-8-F0/0.sprintlink.net (144.228.20.8)  10 ms  10 ms  10 ms
 6  sl-fw-5-H4/0-T3.sprintlink.net (144.228.10.18)  50 ms  50 ms  50 ms
 7  sl-fw-6-F0/0.sprintlink.net (144.228.30.6)  80 ms  50 ms  50 ms
 8  sl-ana-1-H2/0-T3.sprintlink.net (144.228.10.30)  80 ms  70 ms  70 ms
 9  sl-ana-3-F0/0.sprintlink.net (144.228.70.3)  80 ms  70 ms  70 ms
10  sl-univ-ca-1-S0-T1.sprintlink.net (144.228.73.82)  90 ms  90 ms  100 ms
11  sdsc-ucop-mci.cerf.net (134.24.66.100)  110 ms  110 ms  100 ms
12  longboard.cerf.net (198.17.46.152)  110 ms  110 ms  100 ms
13  muir-gw-fddi.ucsd.edu (132.239.254.238)  100 ms  110 ms  110 ms
14  mirrorshades.ucsd.edu (128.54.16.18)  130 ms  120 ms  130 ms
15  hamgate.ee.unr.edu (134.197.39.252)  190 ms  190 ms  180 ms

Interestingly, the traceroute stops when a machine with IP address
134.197.39.252 claims that it is also 44.125.128.131.  In fact, the route
between steps 14 and 15 is not a direct one, and my ping frame is traveling
through multiple hops while encapsulated inside another IP frame sent by
128.54.16.18 to 134.197.39.252.  While my ping frame is traveling encapsulated,
it is incapable of provoking traceroute replies.

What is important about this is that my ping to 44.125.128.131, which is the IP
address mapped from domain "hamgate.n8khn.ampr.org," is routed to the right
machine (or at least to a machine which thinks it is the right machine)
entirely without passing through Internic or any of the authoritative domain
name servers.  MIRRORSHADES.UCSD.EDU is not one of these domain name servers;
it is a router.  Routers do not know or care anything about domain name
service, only about IP addresses.

 MS> Further, there is nothing unusual about this Mike.  Many
 MS> domains use outside servers  I work with them on a daily
 MS> basis.  I've offered my proof, showing the links between
 MS> AMPRnet, ampr.org and the 44.x.x.x domain.  Unless you are
 MS> willing to provide evidence to the contrary, my point still
 MS> remains valid, that the term "44net" (or "net44") is wrong,
 MS> the proper domain name assigned to the 44.x.x.x (ampr.org)
 MS> domain (and it's linked network) is "AMPRnet".

Your point is not valid.  I do not even understand your reasoning.  IP
addresses are part of a network, not of a domain.  Mapping between a domain
such as AMPR.ORG to a network such as Net 44 is a convention that occurs
because someone typed it in at the primary authoritative domain name server. 
If someone types in that "xyz.ampr.org" maps to "1.2.3.4" then that is what the
Internet will think.

MB>>I suppose you could argue that a block of IP addresses is a 
MB>>"domain" in the sense that someone has traceable 
MB>>administrative authority for them, but that is
MB>>not the common use of the term in TCP/IP.  A network is 
MB>>generally considered to
MB>>be mappable into a pseudo-domain (IN-ADDR.ARPA) for purposes 
MB>>of back resolution
MB>>using PTR resource records, but that is not the same thing 
MB>>as saying that a network is a domain.

 MS> True, and in my haste I should have properly stated, "The
 MS> first DOES identify this DOMAIN is LINKED to a
 MS> NETWORK; the second identifies the DOMAIN."

Nothing whatever at Internic, certainly not "whois" records, signifies that a
domain is linked to a network.  In fact, domains and networks are linked only
logically, not physically, by resource records maintained by domain name
servers which are authoritative for the domain.

 MS> A domain
 MS> can encompass a single server, a single network, or a whole
 MS> bunch of networks.  Again, Internet (and Internic) could 
 MS> care less.  The mnemonic routing (aka "the descriptive 
 MS> domain name") for the 44 domain is "ampr.org", not 
 MS> "44net.net" or "net44.net".  The only thing actually 
 MS> identifying a network under the domain are the records at 
 MS> Internic (BTW, while not actually trying it, I don't think 
 MS> you'll find too many X.500 listings under ampr.org).

No, no, no, no!  Besides, how on earth did X.500 get into this?  You have got
logical names messed up with physical addresses.  Internic does not even tell
you how to map them back and forth; it just tells you which machines are
responsible for doing it.  Even so, it is the domain name server at Internic,
not the "whois" database, which has any actual effect.

AMPR.ORG is a domain.  Internic says it has domain name servers.  These domain
name servers contain resource records that happen to map logical domain names
into Net 44, which is a net and not a domain.  Nets are connected machines
which have similar physical IP addresses.  Routing of IP frames takes place
entirely on the basis of these physical IP addresses, independent of logical
information about domain names.

MB>>It is merely administrative policy that requires AMPR.ORG 
MB>>domains to be mapped
MB>>to Net 44 addresses and vice versa.  The administrator is 
MB>>free to map whatever
MB>>he wants to wherever he wants.  I really am at a loss to 
MB>>follow your chain of
MB>>reasoning regarding "whois" queries.

 MS> Sorry Mike, it's INTERNET POLICY - always has been, always
 MS> will be - you can't have a domain without naming it.  And
 MS> "whois" querries have been around longer than Internet 
 MS> has... ..originating with ARPAnet.  (There I go again, using 
 MS> the right tool for the right job - must be my Unix 
 MS> background, eh?  ;-)   )

I really think it is inappropriate for you to cross the line and insult me.

The administrative policy, insofar as it exists, is made by the human in charge
of the domain.  In the case of AMPR.ORG, this is Brian Kantor.  If he says that
he wants "xyz.ampr.org" to map to "1.2.3.4," he is perfectly free to type that
into his primary authoritative name server.  He does not even have to have any
authority over Net 1, nor over host 1.2.3.4.

Domains are not networks.  Networks are not domains.

 MS> Hate to break it to you Mike, but AMPRnet has delegated 
 MS> it's routing to UCSD.EDU and NOSC.MIL.  Otherwise the above
 MS> test wouldn't work, would it?  AMPRnet is unusual, in that 
 MS> we don't have sub-domains and related servers (ie. hamgate
 MS> .ve7sfu.#vanc.bc.ca.ampr.org).

Routing for Net 44 is NOT delegated to UCSD.EDU or TROUT.NOSC.MIL.  These are
domain name servers, not routers.  Only domain name service for AMPR.ORG is
delegated to UCSD.EDU and TROUT.NOSC.MIL.  Routing for Net 44 is delegated to
MIRRORSHADES.UCSD.EDU, which is a router, not a domain name server.

Brian Kantor will send the RCMP to throw you in leg irons if you register a
domain name like "hamgate.ve7sfu.#vanc.bc.ca.ampr.org."  AMPR.ORG obviously has
subdomains, else "hamgate.n8khn.ampr.org" would not resolve.  What AMPR.ORG
does not have is delegated subdomains, which are different.

 MS> We instead rely on an
 MS> economical system of point-to-point (read  IP/IP)
 MS> encapsulation, which utilizes the servers of other domains.
 MS> Also, AXIP is a further encapsulation of AX frames within
 MS> the IP/IP encapsulation.  RFC 1226 states this very simply.

 MS> [BARRY - Please acknowledge the above]

I would not call IP-in-IP "economical," but that is a matter of opinion.  The
comment about AXIP in my earlier message was a result of my editing out the
wrong sentence.  Barry McLarnon corrected the resulting error.

MB>>I'm talking about where IP frames go, not what gets typed 
MB>>into name servers.

 MS> So am I Mike, and my "Internet" IP frames manage to make it
 MS> to hamgate.n8khn.ampr.org (and other gateways) from an
 MS> "Internet" telnet session, even though my local system (and
 MS> Internet) doesn't have a clue where, or what, it is...
 MS> ..so prove me wrong.  :-)

I am going to try this one last time: domain name service and Internic have
nothing whatever to do with where an IP frame goes once it is addressed by the
sender.  Your local system resolves the name to an IP address by querying a
domain name server, and then uses this IP address and only this IP address to
send the actual frames which comprise your telnet session.

 MS> If you (and others) are hell bent on calling the 44.x.x.x 
 MS> domain "44net" or "net44", might I suggest you formally 
 MS> change both the domain name "AMPRNET-DOM" to "NET44-NET"; 
 MS> and the mnemonic routing "ampr.org" to "net44.net" first.  
 MS> After all, it is the medium by which most of our DX traffic 
 MS> is passing.

Hey, I'm being nice about this and trying to teach you something.  You are just
being sarcastic.  The only reason I am even bothering to reply to this is
because there are people reading this who are trying to learn something.

 MS> But before you do this, you can start to work 
 MS> on the ARRL, because they've formally recognized the name 
 MS> "Amateur Packet Radio Network" (see 1994 ARRL Handbook), and 
 MS> again I don't think the same can be said for "44net" or 
 MS> "net44".  Good luck on the uphill fight!   :-)

Guess who had the job of writing the packet radio section of the ARRL Handbook?
 
-- Mike