][Date Next][Thread Prev
][Thread Next][Date Index
Re: DIALUP SLIP cont...
- To: email@example.com
- Subject: Re: DIALUP SLIP cont...
- From: firstname.lastname@example.org (Mike Bilow)
- Date: Sat, 31 Dec 94 14:46:00 -0000
- Reply-to: email@example.com
On 94 Dec 31 at 01:48, Michael Stenner <firstname.lastname@example.org> 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
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
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.
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 3, additional = 5
HAMGATE.N8KHN.AMPR.ORG, type = A, class = IN
internet address = 126.96.36.199
ttl = 864000 (10 days)
nameserver = ucsd.edu
ttl = 864000 (10 days)
nameserver = trout.nosc.mil
ttl = 864000 (10 days)
nameserver = hpcsos.col.hp.com
ttl = 864000 (10 days)
internet address = 188.8.131.52
ttl = 86400 (1 days)
internet address = 184.108.40.206
ttl = 86400 (1 days)
internet address = 220.127.116.11
ttl = 86400 (1 days)
internet address = 18.104.22.168
ttl = 367898 (4 days 6 hours 11 mins 38 secs)
internet address = 22.214.171.124
ttl = 48807 (13 hours 33 mins 27 secs)
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 126.96.36.199, 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
# traceroute /max=20 188.8.131.52
traceroute to 184.108.40.206, 20 hops max, 38 byte packets
1 inet-gw.ids.net (220.127.116.11) 0 ms 0 ms 0 ms
2 sl-pen-4-S2/3-T1.sprintlink.net (18.104.22.168) 10 ms 30 ms 10 ms
3 sl-pen-1-F0/0.sprintlink.net (22.214.171.124) 10 ms 10 ms 20 ms
4 sl-dc-6-H2/0-T3.sprintlink.net (126.96.36.199) 40 ms 20 ms 40 ms
5 sl-dc-8-F0/0.sprintlink.net (188.8.131.52) 10 ms 10 ms 10 ms
6 sl-fw-5-H4/0-T3.sprintlink.net (184.108.40.206) 50 ms 50 ms 50 ms
7 sl-fw-6-F0/0.sprintlink.net (220.127.116.11) 80 ms 50 ms 50 ms
8 sl-ana-1-H2/0-T3.sprintlink.net (18.104.22.168) 80 ms 70 ms 70 ms
9 sl-ana-3-F0/0.sprintlink.net (22.214.171.124) 80 ms 70 ms 70 ms
10 sl-univ-ca-1-S0-T1.sprintlink.net (126.96.36.199) 90 ms 90 ms 100 ms
11 sdsc-ucop-mci.cerf.net (188.8.131.52) 110 ms 110 ms 100 ms
12 longboard.cerf.net (184.108.40.206) 110 ms 110 ms 100 ms
13 muir-gw-fddi.ucsd.edu (220.127.116.11) 100 ms 110 ms 110 ms
14 mirrorshades.ucsd.edu (18.104.22.168) 130 ms 120 ms 130 ms
15 hamgate.ee.unr.edu (22.214.171.124) 190 ms 190 ms 180 ms
Interestingly, the traceroute stops when a machine with IP address
126.96.36.199 claims that it is also 188.8.131.52. 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
184.108.40.206 to 220.127.116.11. While my ping frame is traveling encapsulated,
it is incapable of provoking traceroute replies.
What is important about this is that my ping to 18.104.22.168, 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 "22.214.171.124" 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 "126.96.36.199," 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 188.8.131.52.
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
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?