[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- Date: January 8-11, 1995
- Date: _________________________
- Chair: Gottfried Luderer
- Email: h.james@conference.com
- Fax: +1 305 666 7134
- Note: If you fax or email your charge order please do NOT mail it also.
- Signature: ________________________________
- Site: Loews Ventana Canyon Resort, Tucson, Arizona
- Telephone: +1 305 666 5115 / Fax: +1 305 666 7134 / Email:
- Telephone: +1 305 666 5115
- Theme: Emerging Broadband Applications, Systems, and Networks
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08422;
9 Nov 94 15:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08416;
9 Nov 94 15:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14822;
9 Nov 94 15:49 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08405;
9 Nov 94 15:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08279;
9 Nov 94 15:46 EST
Received: from daedalus.epcc.ed.ac.uk by CNRI.Reston.VA.US id aa14759;
9 Nov 94 15:46 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Thomas Pfenning <pfenning at epcc.ed.ac.uk>
Message-Id: <9411092046.ZM1996 at epcc.ed.ac.uk>
Date: Wed, 9 Nov 1994 20:45:57 +0000
X-Face: #Mjaw'lS(rlCam-]hu[ at 5x8aR8}8}qLtD2G{&[4j]k`_p5p8U%6*4O[Al0"o$R0WP9Sf^{_/;02AC*tGRw3D%nB<K*(0u:#dz$+cJAS|~"eobxB4pq:Zv?w]9n2NS*O(jy{>mcK2U+7hWpO1~~qwI25+O=g*N.cc)jdh",txzr{>J'*vA.9 at wlf{OtIe;T8jq7[<YW
X-Mailer: Z-Mail (3.2.0 06sep94)
To: ietf at CNRI.Reston.VA.US
Subject: IPng Job mobility
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 403
Can any body point me to an idea on how to support job migration in the
framework of the IPng proposal.
I am thinking of a job being a network adressable entity which gets its
packets delivered independent from the host it is running on.
Thomas
--
Currently on a research visit at Edinburgh Parallel Computing Centre
Phone: +44 31 650 6714
Fax: +44 31 650 6555
E-Mail: pfenning at zpr.uni-koeln.de
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09057;
9 Nov 94 16:14 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15429;
9 Nov 94 16:14 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09028;
9 Nov 94 16:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08814;
9 Nov 94 16:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15292;
9 Nov 94 16:08 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08807;
9 Nov 94 16:08 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: rolc at maelstrom.timeplex.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: NBMA Address Resolution Protocol (NARP) to
Experimental
Date: Wed, 09 Nov 94 16:08:09 -0500
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9411091608.aa08807 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "NBMA Address Resolution
Protocol (NARP)" <draft-ietf-rolc-nbma-arp-00.txt> and recommends
that it be published by the RFC Editor as an Experimental RFC. This
document is the product of the Routing over Large Clouds Working
Group. The IESG contact person is Joel Halpern.
RFC Editor -- Please attach the following "IESG Note" to the front
of the RFC:
Note that the work contained in this memo does not describe an
Internet standard. This work represents an early stage in the
ongoing efforts to resolve direct communication over NBMA subnets.
It is a suitable experimental protocol for early deployment. It
is expect that it will be superceded by other work being developed
within the IETF.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10395;
9 Nov 94 18:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10391;
9 Nov 94 18:07 EST
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa18048;
9 Nov 94 18:07 EST
Received: from sdiv.cray.com (daemon at ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id QAA10074; Wed, 9 Nov 1994 16:57:52 -0600
Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA16236; Wed, 9 Nov 1994 16:57:48 -0600
Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA16231; Wed, 9 Nov 1994 16:57:47 -0600
Received: from hp.com (hp.com [15.255.152.4]) by timbuk.cray.com (8.6.9/8.6.9M) with ESMTP id QAA10056 for <telnet-ietf at cray.com>; Wed, 9 Nov 1994 16:57:44 -0600
Received: from hpindda.cup.hp.com by hp.com with ESMTP
(1.37.109.13/15.5+ECS 3.3) id AA086511859; Wed, 9 Nov 1994 14:57:41 -0800
Received: by hpindda.cup.hp.com
(1.37.109.12/15.5+IOS 3.20+cup+OMrelay) id AA045561827; Wed, 9 Nov 1994 14:57:08 -0800
Date: Wed, 9 Nov 1994 14:57:08 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Raghu Seshadri <seshadri at hpindda.cup.hp.com>
Message-Id: <199411092257.AA045561827 at hpindda.cup.hp.com>
To: telnet-ietf at cray.com
Subject: Query
Content-Length: 416
Hello,
I do not know if it is appropriate to post this query here;
if it is not, I'd appreciate pointers to where it might be
suitable to send this message.
I'd like to know if the following RFCs have been implemented;
if so, I request you to get in touch with me. Thanks.
The RFCs are - 1692, 1646, 1073, 927, 933, 1041, 1408, 1468,
1079, 1080, 885.
Regards,
Raghu Seshadri
seshadri at cup.hp.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10642;
9 Nov 94 18:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10638;
9 Nov 94 18:46 EST
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa18586;
9 Nov 94 18:46 EST
Received: from sdiv.cray.com (daemon at ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id RAA16128; Wed, 9 Nov 1994 17:40:16 -0600
Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA21803; Wed, 9 Nov 1994 17:40:13 -0600
Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA21798; Wed, 9 Nov 1994 17:40:12 -0600
Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by timbuk.cray.com (8.6.9/8.6.9M) with ESMTP id RAA16116 for <telnet-ietf at cray.com>; Wed, 9 Nov 1994 17:40:09 -0600
Received: (billw at localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id PAA13260; Wed, 9 Nov 1994 15:34:35 -0800
Date: Wed, 9 Nov 94 15:34:34 PST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Chops Westfield <billw at cisco.com>
To: Raghu Seshadri <seshadri at hpindda.cup.hp.com>
Cc: telnet-ietf at cray.com
Subject: Re: Query
In-Reply-To: Your message of Wed, 9 Nov 1994 14:57:08 -0800
Message-Id: <CMM.0.90.2.784424074.billw at glare.cisco.com>
Content-Length: 1579
The RFCs are - 1692, 1646, 1073, 927, 933, 1041, 1408, 1468,
1079, 1080, 885.
1079 C. Hedrick, "Telnet terminal speed option", 12/01/1988. (Pages=3)
(Format=.txt)
1080 C. Hedrick, "Telnet remote flow control option", 11/01/1988.
(Pages=4) (Format=.txt) (Obsoleted by RFC1372)
0885 J. Postel, "Telnet end of record option", 12/01/1983. (Pages=2)
(Format=.txt)
These three are supported by cisco communication servers. 1079 is/was used
for speed matching between autobaud and "milking machine" lines. 1080 for
allowing servers to turn off SW flow control for file uploads, and 885 is
used under rather obscure circumstance to indicate the packet delimitation
of an x.25 data stream when it is "translated" to a telnet session.
In addition, I beleive 885 is rather extensively used within the TN3270
"extension" of telnet.
0927 B. Anderson, "TACACS user identification Telnet option",
12/01/1984. (Pages=4) (Format=.txt)
Note that this predates the use of "TACACS" on cisco or other terminal
servers. These were real milnet TACs they are talking about, and I doubt
that the option has much practical application nowdays.
1041 Y. Rekhter, "Telnet 3270 regime option", 01/01/1988. (Pages=6)
(Format=.txt)
This was a well-meant attempt to improve the transition to tn3270 mode,
but I don't think and of the host implementations ever supported it, and
it is now deprecated. There is a tn3270 group within the IETF codifying
current practices and possible extensions for tn3270.
BillW
cisco
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10712;
9 Nov 94 18:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10706;
9 Nov 94 18:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18727;
9 Nov 94 18:54 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10695;
9 Nov 94 18:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10660;
9 Nov 94 18:52 EST
Received: from wintermute.imsi.com by CNRI.Reston.VA.US id aa18678;
9 Nov 94 18:52 EST
Received: from relay.imsi.com by wintermute.imsi.com
id SAA17301; Wed, 9 Nov 1994 18:52:23 -0500
Received: from snark.imsi.com by relay.imsi.com
id SAA24580; Wed, 9 Nov 1994 18:52:22 -0500
Received: by snark.imsi.com (4.1/SMI-4.1)
id AA23604; Wed, 9 Nov 94 18:52:21 EST
Message-Id: <9411092352.AA23604 at snark.imsi.com>
To: ietf at CNRI.Reston.VA.US
Cc: ji at cs.columbia.edu, karn at qualcomm.com
Subject: Re: IPng Last Call -- Mobility
In-Reply-To: Your message of "Wed, 09 Nov 1994 12:37:42 EST."
<9411091737.AA17058 at ginger.lcs.mit.edu>
Reply-To: perry at imsi.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 09 Nov 1994 18:52:20 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Perry E. Metzger" <perry at imsi.com>
In Re: the recent discussion of mobility and where it belongs
It may be heretical to say this, but I suspect that the IP suite will
ultimately have nothing to do with the way real world mobility gets
implemented.
If we build a mobility support layer, are people going to go out there
and build a brand new mobile IP radio network? No. People who are
actually doing mobile computing fall into two categories -- those that
are doing it in a local area, who will appear to be on a radio lan
like one of the several commercial ones available who will simply be
able to use the normal IP stack via a router to the radio lan base
station and who will appear stationary to the IP network, and those
who will be using the cellular phones network and who will again
appear to be stationary with respect to the IP network.
In short, I think this is going to be handled in the layers below
IP. Real users aren't going to care about the IP mobility support
because they'll just be using the built in IP support in their CDMA
phones or what have you and the protocols being developed will go
unused. The mobility support will go in far below the IP layer and
none of our IP mobility work will matter.
Perry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10896;
9 Nov 94 19:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10890;
9 Nov 94 19:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19157;
9 Nov 94 19:15 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10879;
9 Nov 94 19:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10834;
9 Nov 94 19:13 EST
Received: from pax.cavebear.com by CNRI.Reston.VA.US id aa19112;
9 Nov 94 19:13 EST
Received: from karl.pax by cavebear.com (4.1/SMI-4.1)
id AA00710; Wed, 9 Nov 94 16:13:37 PST
Date: Wed, 9 Nov 94 16:13:37 PST
Message-Id: <9411100013.AA00710 at cavebear.com>
To: stev at ftp.com
Cc: dcrocker at mordor.stanford.edu, bsimpson at morningstar.com,
ietf at CNRI.Reston.VA.US
In-Reply-To: stev at ftp.com's message of Wed, 9 Nov 94 11:18:39 EST <9411091618.AA02543 at mailserv-D.ftp.com>
Subject: Re: IPng Last Call -- Mobility
Reply-To: karl at cavebear.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Karl Auerbach <karl at cavebear.com>
X-Orig-Sender: karl at cavebear.com
Repository: cavebear
Originating-Client: pax
> I'd like to raise one of my current hot flags (not flashes): why put the
> meat of mobility into the Internet protocol, itself? Other than, perhaps,
> a 'redirect' control message, there is a line of suggestion for puting the
> real core of the mechanism into transport-level services directly.
> Comments?
>since you asked:)
>while i understand some of the facilities needed for efficient
>mobility need to appear in the IP layer (an example might be to
>consider the needs of mobility in one's addressing architecture),
>i always viewed mobility as more of a routing issue. sure, you can fix
>things elsewhere (like the transport level) to make things easier still,
>but mobility, to me, seems to be fundamentally a routing issue.
Actually one can make a strong argument that mobility can be handled
at the application layer. See the pcmail protocol for an example.
Essentially applications are designed to resynchronize whenever the
transport fails, i.e. when things move. (Of course this assumes a
relatively low disconnect rate.) The nice thing about this kind of
approach is that it deals with the application as an end point name
and lets the topology dependent lower layer addresses change as things
move. Essentially, it is repeating the lesson we learned from ARP but
at a higher level of abstraction.
I.e. there are lots of ways to skin a cat. (Not that I would want to
skin a cat ;-)
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11835;
9 Nov 94 20:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11828;
9 Nov 94 20:39 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20426;
9 Nov 94 20:39 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11819;
9 Nov 94 20:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11774;
9 Nov 94 20:36 EST
Received: from [131.112.32.132] by CNRI.Reston.VA.US id aa20386;
9 Nov 94 20:36 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 10 Nov 94 10:26:51 +0859
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9411100127.AA16647 at necom830.cc.titech.ac.jp>
Subject: Re: IPng Last Call -- Mobility
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Date: Thu, 10 Nov 94 10:26:49 JST
Cc: stev at ftp.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <v03000706aae6aaa0410e at [128.102.17.23]>; from "Dave Crocker" at Nov 9, 94 8:44 am
X-Mailer: ELM [version 2.3 PL11]
> >but mobility, to me, seems to be fundamentally a routing issue.
^^^^^^^^^^^^^^^
More precisely, an IP layer issue.
> Let me try to re-state the suggestion I'm making, since I can't figure out
> how to treat mobility as a routing issue and then decide on a specification
> path:
Dave, I'm tired of denying your broken suggesions so many times without
hearing any supporting reasoning.
> What part(s) of the Internet service should we change, in order to support
> roaming hosts?
At the part which identifies a host. That is, at the IP layer.
Absolutely not individual TCP connections.
No two TCP end points on a host make different movement.
As all the TCP end points on a host moves as a whole, doing mobility
on each TCP is a total waste of effort (and you are also suggesting
to abandon UDP)..
> Can you provide some details for pursuing this as a routing topic,
You can't provide any reasons for your approach. Do it first.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11953;
9 Nov 94 20:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11947;
9 Nov 94 20:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20618;
9 Nov 94 20:49 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11932;
9 Nov 94 20:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11899;
9 Nov 94 20:47 EST
Received: from nacho.cisco.com by CNRI.Reston.VA.US id aa20590;
9 Nov 94 20:47 EST
Received: from [198.92.30.64] (macip-dialup-18.cisco.com [198.92.30.64]) by nacho.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id RAA15480; Wed, 9 Nov 1994 17:47:26 -0800
X-Sender: fred at nacho.cisco.com
Message-Id: <aae7253b080210037615 at [198.92.30.64]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Nov 1994 17:47:30 -0800
To: logo at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Fred Baker <fred at cisco.com>
Subject: Re: Chair's contest for an IETF Logo
Cc: ietf at CNRI.Reston.VA.US
How about crowd of running "C"'s, leaving one dead body behind the crowd?
the motto is "rough consensus and running code".
=============================================================================
If you're not living on the edge, you're taking up too much room!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12490;
9 Nov 94 21:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12484;
9 Nov 94 21:24 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21469;
9 Nov 94 21:24 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12465;
9 Nov 94 21:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12412;
9 Nov 94 21:22 EST
Received: from necom830.cc.titech.ac.jp by CNRI.Reston.VA.US id aa21397;
9 Nov 94 21:22 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 10 Nov 94 11:11:09 +0900
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9411100211.AA16876 at necom830.cc.titech.ac.jp>
Subject: Re: IPng Last Call -- Mobilityg
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Date: Thu, 10 Nov 94 11:11:07 JST
Cc: jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: <v0300070eaae6bc3261e7 at [128.102.17.23]>; from "Dave Crocker" at Nov 9, 94 10:06 am
X-Mailer: ELM [version 2.3 PL11]
> Anyhow, the point is that the effort to replicate in the transport layer
> may be inevitable, since (for example) I believe that transport needs to
> modify its retransmission scheme to take advantage of the alternate paths.
"to take advantage of the alternate paths" is exactly the purpose of
routing.
You archieve your goal only by separating IP layer identification and IP
layer routing all in the IP layer.
> His argument is that we really only NEED the mechanism for something like
> TCP (as opposed to UDP) and I think he has a point.
Use X.25. Don't use DNS.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12576;
9 Nov 94 21:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12570;
9 Nov 94 21:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21801;
9 Nov 94 21:35 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12558;
9 Nov 94 21:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12526;
9 Nov 94 21:33 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa21747;
9 Nov 94 21:33 EST
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id SAA24391; Wed, 9 Nov 1994 18:33:49 -0800
Message-Id: <v03000701aae731fd9a65 at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Nov 1994 18:33:52 -0800
To: karl at cavebear.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng Last Call -- Mobility
Cc: ietf at CNRI.Reston.VA.US
At 4:13 PM 11/9/94, Karl Auerbach wrote:
>Actually one can make a strong argument that mobility can be handled
>at the application layer. See the pcmail protocol for an example.
>Essentially applications are designed to resynchronize whenever the
Once upon a time, I held the same view.
What swayed me was watching some other spec efforts try to lay extra core
services on top of TCP. They ended up re-inventing much of TCP's
reliability mechanisms. (This is the basic challenge in doing a 'session'
layer.) As a consequence, I'd rather modify TCP just a tad and have only
one set of reliability mechanisms.
d/
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email: dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12658;
9 Nov 94 21:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12651;
9 Nov 94 21:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21917;
9 Nov 94 21:39 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12638;
9 Nov 94 21:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12606;
9 Nov 94 21:38 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa21850;
9 Nov 94 21:38 EST
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id SAA24426; Wed, 9 Nov 1994 18:36:00 -0800
Message-Id: <v03000705aae733cc0726 at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Nov 1994 18:36:02 -0800
To: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng Last Call -- Mobility
Cc: ietf at CNRI.Reston.VA.US
At 5:26 PM 11/9/94, Masataka Ohta wrote:
>Dave, I'm tired of denying your broken suggesions so many times without
alas, not tired enough, I fear.
>hearing any supporting reasoning.
you may choose not to accept the reasons I've offered, but the reasons were
stated and repeatedly.
My query to this list, this time, had to do with trying to evoke some
discussion for the reasons that modifying the infrastructure fabric is
better than the 'outer' ( or host) portion of the system.
Since you have already participated in the earlier discussion on the
big-internet list, feel free to indulge in your exhaustion on the topic and
sit this one out.
But just for the OTHER readers on the list, the motivations that drive the
suggestion for NOT doing mobility in the Internet layer are:
1. ease of adoption by pairwise host implementation rather than modifying
the underlying Interent fabric
2. retaining the current internet relaying model in its current level of
simplicity/complexity, rather than adding a very significant change to its
basic concepts
3. eliminating the claimed need for an EID by using domain names, instead
(or with Huitema's proposal, using NO additional identifier at all!)
4. providing dual functionality for both mobility and higher transmission
robustness during outage -- Chiappa labeled this support of multi-homed
hosts and I think that's a reasonable view; it means that an outage down
one path can be recovered from in one TCP retransmission time.
d/
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email: dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12763;
9 Nov 94 21:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12757;
9 Nov 94 21:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22246;
9 Nov 94 21:54 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12744;
9 Nov 94 21:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12708;
9 Nov 94 21:52 EST
Received: from necom830.cc.titech.ac.jp by CNRI.Reston.VA.US id aa22200;
9 Nov 94 21:53 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 10 Nov 94 11:44:15 +0900
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9411100244.AA17039 at necom830.cc.titech.ac.jp>
Subject: Re: IPng Last Call -- Mobility
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Date: Thu, 10 Nov 94 11:44:13 JST
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <v03000705aae733cc0726 at [128.102.17.23]>; from "Dave Crocker" at Nov 9, 94 6:36 pm
X-Mailer: ELM [version 2.3 PL11]
> you may choose not to accept the reasons I've offered, but the reasons were
> stated and repeatedly.
Repeatedly denied.
> 1. ease of adoption by pairwise host implementation rather than modifying
> the underlying Interent fabric
Pairwise means your mobile host can not communicate with mobiliity-unaware
host and is completely broken.
> 2. retaining the current internet relaying model in its current level of
> simplicity/complexity, rather than adding a very significant change to its
> basic concepts
YOU are changing the basic concepts.
> 3. eliminating the claimed need for an EID by using domain names, instead
You can't say "domain names", as you throw away UDP.
> (or with Huitema's proposal, using NO additional identifier at all!)
EID is an identification part of address and is not an additional
identifiier at all.
> 4. providing dual functionality for both mobility and higher transmission
> robustness during outage --
"higher transmission robustness during outage" is process migration
requires a lot of application specific state preservation and is
unrelated to mobiliy.
> rather than adding a very significant change to its
> basic concepts
So, don't add it and pursue it elsewhere.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21317;
10 Nov 94 1:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21311;
10 Nov 94 1:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25202;
10 Nov 94 1:09 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21300;
10 Nov 94 1:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21261;
10 Nov 94 1:07 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa25180;
10 Nov 94 1:07 EST
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id WAA25231; Wed, 9 Nov 1994 22:07:14 -0800
Message-Id: <v03000702aae7679a2a55 at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Nov 1994 22:07:16 -0800
To: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng Last Call -- Mobility
Cc: ietf at CNRI.Reston.VA.US
At 6:44 PM 11/9/94, Masataka Ohta wrote:
>> 1. ease of adoption by pairwise host implementation rather than modifying
>> the underlying Interent fabric
>
>Pairwise means your mobile host can not communicate with mobiliity-unaware
>host and is completely broken.
there is no great magic in obtaining interoperability. You always need at
least the participating end portions of the service to interoperate.
However, by specifying the functionality in the IP layer, ALL IP modules
will need to be updated. Hence, the proposed host-level implementation is
the minimum. Working instead at the IP layer must do at least that, but
appears to require more effort, certainly not less.
>> 4. providing dual functionality for both mobility and higher transmission
>> robustness during outage --
>
>"higher transmission robustness during outage" is process migration
>requires a lot of application specific state preservation and is
>unrelated to mobiliy.
the only added state information is a modification to a connection table.
Rather than listing one IP address for an endpoint, it may contain
multiple.
d/
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email: dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21894;
10 Nov 94 3:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21888;
10 Nov 94 3:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26590;
10 Nov 94 3:08 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21879;
10 Nov 94 3:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21838;
10 Nov 94 3:06 EST
Received: from necom830.cc.titech.ac.jp by CNRI.Reston.VA.US id aa26554;
10 Nov 94 3:06 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 10 Nov 94 16:55:48 +0859
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9411100756.AA00271 at necom830.cc.titech.ac.jp>
Subject: Re: IPng Last Call -- Mobility
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Date: Thu, 10 Nov 94 16:55:46 JST
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <v03000702aae7679a2a55 at [128.102.17.23]>; from "Dave Crocker" at Nov 9, 94 10:07 pm
X-Mailer: ELM [version 2.3 PL11]
> >> 1. ease of adoption by pairwise host implementation rather than modifying
> >> the underlying Interent fabric
> >Pairwise means your mobile host can not communicate with mobiliity-unaware
> >host and is completely broken.
> there is no great magic in obtaining interoperability. You always need at
> least the participating end portions of the service to interoperate.
> However, by specifying the functionality in the IP layer, ALL IP modules
> will need to be updated.
Can somebody explain what Dave is talking about in the face of
mobility WG's proposal?
Is he just ignoring it?
> the only added state information is a modification to a connection table.
> Rather than listing one IP address for an endpoint, it may contain
> multiple.
What you are talking about is the IP layer EID based scheme requiring
NO connection table.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01110;
10 Nov 94 6:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01104;
10 Nov 94 6:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02931;
10 Nov 94 6:33 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01076;
10 Nov 94 6:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00990;
10 Nov 94 6:18 EST
Received: from mitsou.inria.fr by CNRI.Reston.VA.US id aa02752;
10 Nov 94 6:18 EST
Received: by mitsou.inria.fr
(5.65c8/IDA-1.2.8) id AA04204; Thu, 10 Nov 1994 12:21:37 +0100
Message-Id: <199411101121.AA04204 at mitsou.inria.fr>
To: bsimpson at morningstar.com
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: IPng Last Call -- serverless self-configuration
In-Reply-To: Your message of "Wed, 09 Nov 1994 13:49:59 GMT."
<3418.bill.simpson at um.cc.umich.edu>
Date: Thu, 10 Nov 1994 12:21:36 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Christian Huitema <Christian.Huitema at sophia.inria.fr>
Bill,
Since you quote me:
>When the SIP WG began, there was strong opposition to using an IEEE
>address for autoconfiguration. From Christian Huitema's unpublished
>paper of March 1993:
>
> Using the 48 bits IEEE address to identify one station
> within a local network that is not designed to
> accomodate more than a couple of thousands stations is
> somewhat of an overkill.
Let say that I am under the impression that this concern is well taken into
account by the "addrconf" working group. What you mention about the original
SIP and SIPP proposals is true - we believed that we could use "configured" 64
bits addresses in combination with "plug and play" addresses composed of a 16
bits prefix and a 48 bits IEEE address. However, it is indeed the case that 128
bits allows you to construct a global address out of a 80 bits prefix and a 48
bits IEEE address, while the "plug and play" addresses of SIP were not globally
routable.
If you combine this with the "H-ratio" computation which show that using 64
bits addresses in a very large Internet would have implied very stringent
address space management requirement, you will understand why I did accept the
consensus on 128 bits addresses for IPv6.
Christian Huitema
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01652;
10 Nov 94 8:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01646;
10 Nov 94 8:14 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04312;
10 Nov 94 8:14 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01637;
10 Nov 94 8:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01606;
10 Nov 94 8:11 EST
Received: from feta.cisco.com by CNRI.Reston.VA.US id aa04252;
10 Nov 94 8:11 EST
Received: (bstewart at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id FAA08696; Thu, 10 Nov 1994 05:11:41 -0800
Date: Thu, 10 Nov 1994 05:11:41 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <bstewart at cisco.com>
Message-Id: <199411101311.FAA08696 at feta.cisco.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: <9411091836.AA04584 at mailserv-D.ftp.com> (stev at ftp.com)
Subject: Re: IPng Last Call -- Mobility
>hmmm, let me try a different tack. i view broadcast packets as just a
>specific example of multicast packets. in a similar view, i view
>mobil hosts as a specific example of routing churn. routes appear in
>one location, they disappear, and they re-appear, possibly in the
>same location, possibly in a different one. in a world with millions
>of routes, this is going to be happening constantly. routes are going
>to be appearing and disappearing constantly. with a rationally
>designed routing architecture, the whole system does not have to
>understand this. local changes can (and do) occour without the layer
>above hearing about it.
Yeah, that. There's a major benefit in controlling complexity and
duplication of effort by keeping re-routing in the network layer. That's
not to say that we shouldn't let a bit more information cross between
transport and network. There are situations where network could work
smarter or transport get better service if at their mutual interface
transport could express what it really needs and network could express
aspects of reality that it can't hide. That's assuming of course that both
of them can react to that information in a useful way.
It strikes me that wives and husbands in traditional roles have exactly the
same problem. :-)} Solomon was right. Nothing is new under the sun.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02843;
10 Nov 94 8:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02837;
10 Nov 94 8:57 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05233;
10 Nov 94 8:57 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02824;
10 Nov 94 8:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02772;
10 Nov 94 8:55 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa05156; 10 Nov 94 8:55 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-16.dialip.mich.net [35.1.48.217]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id IAA20696 for <ietf at CNRI.Reston.VA.US>; Thu, 10 Nov 1994 08:55:25 -0500
Date: Thu, 10 Nov 94 11:48:01 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3421.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: IPng Last Call -- TreeWork
> Last Call: The Recommendation for the IP Next Generation Protocol
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
> 11 November.
>
The second in a series of comments on IPng. Please, just make
comments for posterity. Don't reply to other comments.
Here are my comments regarding the unplanned address hierarchy.
----
The IPng Recommendation does not sufficiently address routing hierarchy
and aggregation. The recommendation is internally inconsistent.
The recommendation specifically lists "more levels of addressing
hierarchy" as rationale for 128 bit addresses. Yet, in the same
sentence, it also lists "simpler auto-configuration":
* expanded addressing and routing capabilities - The IP address size
is increased from 32 bits to 128 bits providing support for a much
greater number of addressable nodes, more levels of addressing
hierarchy, and simpler auto-configuration of addresses.
Addressing hierarchy is a direct impediment to simplicity of
auto-configuration. In a robust internetwork, with a mesh of
interconnection, each level of hierarchy introduces another degree of
permutation of address. For example, the current 3 level hierarchy
results in (for a full mesh) a potential 3! (= 6) addresses per
node interface.
While 6 addresses per node is tractable, most sites do not install a
full mesh. Each subscriber is generally connected to only 1 to 3
providers, and those providers are interconnected at only the top level.
This results in only 2 or 3 real addresses per interface.
Historically, only _one_ such address is hand-configured. When the
single address is advertised in every direction, the routing tables have
exploded from the lack of aggregation. This routing table explosion is
one of the problems that IPng is supposed to solve.
A seven level hierarchy would require a maximum 7! (= 720) addresses per
interface. The fact that a subscriber would only connect to 1 to 3
providers would be overwhelmed by the need for the providers to
interconnect among themselves at several "levels" on the hierarchy to
provide robust and efficient service, resulting in at least 120
addresses per interface.
This is unimplementable. Most hosts do not have the resources to
support 120 to 720 addresses. Auto-configuration traffic would swamp
the configuration servers, and could constitute the majority of link
traffic.
Eight levels (= 5,760 addresses per interface) is unthinkable.
If common installation practice continues, and only one address is
hand-configured for each interface, the host would be unable to practice
provider selection, and internet routing would direct most traffic
through the "root" of the hierarchy. This would swamp the root,
introducing a single point of failure.
A "short" hierarchy mitigates this problem. Constraining the number of
levels at only 4 would significantly reduce the number of potential
addresses (6 to 24 for the above assumptions). This is easily within
the capabilities of envisioned auto-configuration and host resources.
A "fat" hierarchy of interconnection of 10,000 to 64,000 per network
locus is well within the reach of current technology.
Moreover, the network is not static. Each time that a link fails, the
effective address for dependent nodes in the hierarchy changes.
Changes in links nearer the root of a "tall, skinny" hierarchy will
result in massive changes! For example, if the root has
interconnections to only 256 links, when only one fails, 1/256 of the
hierarchy will be renumbered and suffer disruption. This could affect
hundreds of millions of nodes.
Based on current experience with MAE-East, such changes will occur on
the order of several times per week (or even per hour).
A "short, fat" hierarchy mitigates these problems. A root with
interconnections to 64,000 links, when only one fails, 1/64,000 of the
hierarchy will be renumbered and suffer disruption. This is a vast
improvement.
In Summary:
- the Internet is a NetWork, not a TreeWork.
- higher levels of hierarchy will cause routing table explosion in the
face of interconnection.
- failure to interconnect at all levels in a hierarchy will lead to
single points of failure.
- higher levels of hierarchy are incompatible with current
auto-configuration and host resources.
- failure to auto-configure all addresses in a hierarchy will lead to
single points of failure.
- higher levels of hierarchy will cause more widespread disruption
when links fail.
I recommend that the main principles of the IPng Recommendation be
accepted, but that the size of the address be returned to 64-bits, as in
the original design team's recommendation, including Deering's
recommendation of a "short, fat" address allocation.
Unless, of course, the IESG believes that host resources are sufficient,
and links don't fail.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03744;
10 Nov 94 10:03 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03740;
10 Nov 94 10:03 EST
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa07150;
10 Nov 94 10:03 EST
Received: from sdiv.cray.com (daemon at ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id IAA04096; Thu, 10 Nov 1994 08:44:55 -0600
Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA29796; Thu, 10 Nov 1994 08:44:49 -0600
Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA29787; Thu, 10 Nov 1994 08:44:47 -0600
Received: from MEDEA.BBN.COM (MEDEA.BBN.COM [128.89.5.128]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id IAA04022 for <telnet-ietf at cray.com>; Thu, 10 Nov 1994 08:44:45 -0600
Message-Id: <199411101444.IAA04022 at timbuk.cray.com>
To: Raghu Seshadri <seshadri at hpindda.cup.hp.com>
Cc: telnet-ietf at cray.com
Subject: Re: Query
In-Reply-To: Your message of Wed, 09 Nov 94 14:57:08 -0800.
<199411092257.AA045561827 at hpindda.cup.hp.com>
Date: Thu, 10 Nov 94 09:35:16 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Waitzman <djw at bbn.com>
Content-Length: 297
RFC1073 (negotiate about window size) was implemented by Dave Borman at
Cray for 4.4 BSD plus other systems. My PC running Linux 1.1 also has
it, but I do not know if the PC telnet is derived from Dave's code.
An early version of what became 1073 was implemented at CMU by Glenn
Marcy.
-david
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04745;
10 Nov 94 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04735;
10 Nov 94 10:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08272;
10 Nov 94 10:47 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04699;
10 Nov 94 10:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04529;
10 Nov 94 10:44 EST
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa08162; 10 Nov 94 10:44 EST
Received: from ftp.com by ftp.com ; Thu, 10 Nov 1994 10:44:21 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Thu, 10 Nov 1994 10:44:21 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA15562; Thu, 10 Nov 94 10:44:01 EST
Date: Thu, 10 Nov 94 10:44:01 EST
Message-Id: <9411101544.AA15562 at mailserv-D.ftp.com>
To: mohta at necom830.cc.titech.ac.jp
Subject: Re: IPng Last Call -- Mobility
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: dcrocker at mordor.stanford.edu, stev at ftp.com, ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Thu Nov 10 10:43:44 1994]
Originating-Client: d-cell.ftp.com
Content-Length: 2519
> >but mobility, to me, seems to be fundamentally a routing issue.
^^^^^^^^^^^^^^^
More precisely, an IP layer issue.
no, unless you consider routing an IP layer issue. personally, i dont.
routing is much to interesting to bog it down with bit twidlers:).
Dave, I'm tired of denying your broken suggesions so many times without
hearing any supporting reasoning.
it seems to me that dave mentioned either: a paper he and christian wrote, or
that both he and christian wrote papers about this issue. i forget which, but
i will soon be seeking them out to understand where they went wrong:)
At the part which identifies a host. That is, at the IP layer.
Absolutely not individual TCP connections.
before you state that the IP layer identifies a host, you shoudl
define a host. what about processors with more than one IP address?
what about several processors with one IP address?
No two TCP end points on a host make different movement.
i dont understand this statement. does this imply that once a connection
is made, the endpoints never leave the processor they are on? if so, i have
an encore multimax with 6 processors i can show you. processes move around
between processors *alot* when all the processors are loaded.
As all the TCP end points on a host moves as a whole, doing mobility
on each TCP is a total waste of effort (and you are also suggesting
to abandon UDP)..
whew! while it is currently true, as far as i know, that tcp
connections dont migrate across machines, i would rather not decide
now that this is a hard and fast rule about it. i have seen machines
in my distant past (was it ITS or TOPS?) that woudl allow you to
disconnect processes and log out, only to reconnect to them later,
even across reboots. i can certainly see a world where the machine
that returns from the reboot is a "different" machine . . .
> Can you provide some details for pursuing this as a routing topic,
You can't provide any reasons for your approach. Do it first.
while i appreciate your near religious conviction, i will note that i
have not seen enough details from you to support your position
either. it appears that mr crocker is either author or co-author of
a position paper, can you provide me with a location to retrieve
yours? to answer the obvious question, i dont have one. i answered
a request for comments from mr. crocker about his opinions . . . .
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04759;
10 Nov 94 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04751;
10 Nov 94 10:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08281;
10 Nov 94 10:47 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04701;
10 Nov 94 10:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04517;
10 Nov 94 10:44 EST
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa08153; 10 Nov 94 10:44 EST
Received: from ftp.com by ftp.com ; Thu, 10 Nov 1994 10:44:14 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Thu, 10 Nov 1994 10:44:14 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA15549; Thu, 10 Nov 94 10:43:52 EST
Date: Thu, 10 Nov 94 10:43:52 EST
Message-Id: <9411101543.AA15549 at mailserv-D.ftp.com>
To: dcrocker at mordor.stanford.edu
Subject: Re: IPng Last Call -- Mobility
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Thu Nov 10 10:43:41 1994]
Originating-Client: d-cell.ftp.com
Content-Length: 1134
Anyhow, the point is that the effort to replicate in the transport layer
may be inevitable, since (for example) I believe that transport needs to
modify its retransmission scheme to take advantage of the alternate paths.
It's the right place and time to decide to sent a packet out an alternate.
i am not sure what you mean by this. if you are talking about
something like "router fallback", where the tcp decides the
connection thru the current route is dead, and, since it is
configured to never give up, asks the ip to find another router, then
there is no reason to put the mobility code in the tcp. a few simple
modifications, which can be used for robust behavior in any
situation, solve the problem. the tcp needs an adaptive
retransmission scheme anyway. when you implement fallback, you
restart all the timers anyway, since the old data skews your averages.
on the other hand, maybe it is time to do some work on new
re-transmission timer paradigms . . .
anyway, while facinating, it suprises me that the list has not risen
up and told us to move this conversation to the mobile IP mailing
list . . .
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04771;
10 Nov 94 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04765;
10 Nov 94 10:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08289;
10 Nov 94 10:47 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04706;
10 Nov 94 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04518;
10 Nov 94 10:44 EST
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa08154; 10 Nov 94 10:44 EST
Received: from ftp.com by ftp.com ; Thu, 10 Nov 1994 10:44:18 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Thu, 10 Nov 1994 10:44:18 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA15556; Thu, 10 Nov 94 10:43:57 EST
Date: Thu, 10 Nov 94 10:43:57 EST
Message-Id: <9411101543.AA15556 at mailserv-D.ftp.com>
To: perry at imsi.com
Subject: Re: IPng Last Call -- Mobility
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: ietf at CNRI.Reston.VA.US, ji at cs.columbia.edu, karn at qualcomm.com
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Thu Nov 10 10:43:42 1994]
Originating-Client: d-cell.ftp.com
Content-Length: 1328
If we build a mobility support layer, are people going to go out there
and build a brand new mobile IP radio network? No. People who are
actually doing mobile computing fall into two categories -- those that
an interesting concept. all me to point out a potential weakness in it.
currently alot of people have cell phones. in general, they are
useful devices for people with specific needs. on the other hand, i
dont think i have found anyone (yet) who *only* has a cell phone.
people have regular phones at work and at home, *because of the cost*
of the cell. i was under the impression that motorola was working on
an interesting cell phone, one that woudl turn into a cordless phone
when it was close enough to it's bas station. as i recall, the base
station also called the phone system, and told it to route the cell
calls to it. this way, while you are at home, you arent paying extra to
use your phone.
i imagine that computer users will be like this. they will want to be
able to use their portables wherever they are, but will not want to
pay alot extra to use it in the office, in cost of in lower speed.
mobility in the IP *stack* may still prove important. hey, with DHCP,
i could migrate my laptop around the buildings here and drop into any
port. that woudl be useful . . . hmmmmmmm . . . .
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04821;
10 Nov 94 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04815;
10 Nov 94 10:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08305;
10 Nov 94 10:47 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04724;
10 Nov 94 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04537;
10 Nov 94 10:44 EST
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa08167; 10 Nov 94 10:44 EST
Received: from ftp.com by ftp.com ; Thu, 10 Nov 1994 10:44:29 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Thu, 10 Nov 1994 10:44:29 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA15569; Thu, 10 Nov 94 10:44:07 EST
Date: Thu, 10 Nov 94 10:44:07 EST
Message-Id: <9411101544.AA15569 at mailserv-D.ftp.com>
To: mohta at necom830.cc.titech.ac.jp
Subject: Re: IPng Last Call -- Mobility
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: dcrocker at mordor.stanford.edu, ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Thu Nov 10 10:43:44 1994]
Originating-Client: d-cell.ftp.com
Content-Length: 2527
> 1. ease of adoption by pairwise host implementation rather than modifying
> the underlying Interent fabric
Pairwise means your mobile host can not communicate with mobiliity-unaware
host and is completely broken.
while a scheme based on routing only works when the whole system
supports the changes. his way is hardly completely broken. i am not
sure it is the correct path in the long term, but it appears to be a
viable intermediate step. my only problem with steps like this is that
sometimes they work well enough in the short term that works stops
on the more complete answer, and the system breaks down eventally.
i dont necessarily think this will happen with dave's proposal though . . .
> 3. eliminating the claimed need for an EID by using domain names, instead
You can't say "domain names", as you throw away UDP.
excuse me? i have heard the common misconception linking IP networks
with domains, but never heard of linking DNS with UDP . . . or are
you thinking that because *most* DNS traffic is UDP based it he is
lost? there are several solutions to that. one is haing the DNS
server address be *magic*, which involves the routers understanding
where the nearest server is. this is sort of the BOOTP view of the
world. it is messy in that it involves basic infrastructure changes.
on the other hand, he could run his DNS traffic over TCP. it woudl be
a tad slower . . . or, i *suppose*, he could just *broadcast* his DNS
requests and hope for the best. this only requires magic in the
*mobile* networks, which may be a reasonable compromise . . . .
> (or with Huitema's proposal, using NO additional identifier at all!)
EID is an identification part of address and is not an additional
identifiier at all.
depends on who you talk to.
> 4. providing dual functionality for both mobility and higher transmission
> robustness during outage --
"higher transmission robustness during outage" is process migration
requires a lot of application specific state preservation and is
unrelated to mobiliy.
it can be process migration, which woudl be exceptionally cool, mind you.
this means my process could follow me around like my wife's dog does . .
> rather than adding a very significant change to its
> basic concepts
So, don't add it and pursue it elsewhere.
Masataka Ohta
do i detect a hostile tone to your note?
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04865;
10 Nov 94 10:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08346;
10 Nov 94 10:49 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04704;
10 Nov 94 10:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04353;
10 Nov 94 10:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07992;
10 Nov 94 10:37 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id ab04346;
10 Nov 94 10:37 EST
To: IETF-Announce: ;
Reply-To: ietf31-social at eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: ietf31-social at eng.sun.com
Subject: DECEMBER '94 IETF: Social Event
Date: Thu, 10 Nov 94 10:37:29 -0500
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9411101037.ab04346 at IETF.CNRI.Reston.VA.US>
Invitation for IETF 31 Social
Tuesday, December 6, 1994
7:00 pm to 10:00 pm
SunSoft invites you to join us for an evening of exploration, food and
drinks at the San Jose Tech Museum of Innovation the evening of Tuesday,
December 6, 1994. The Tech Museum, located at 145 W. San Carlos Street
(1 block from the San Jose Fairmont), allows visitors to touch and explore
new technologies and innovations emerging out of Silicon Valley.
Food and Beverages
- ------------------
Our buffet will include a pasta bar with Ravioli, Tortellini and Fusilli,
a Mexican bar with build it yourself nachos and fajitas and a fruit
bar complete with Chantilly cream, brown sugar and chocolate fondue.
One beverage ticket will be issued to each attendee which may be used
for soda, bottled water, non-alcholic beer, beer or wine.
Coffee, tea and delicious desserts will also be provided.
Additional beverages will be available from the cash bar.
Costs
- -----
US$35.00 per attendee. The ticket price covers food and one
beverage (entrance to the Tech Museum is courtesy of SunSoft).
To assure your space, your reservation must be received by November 30, 1994.
Receipt of payment at the time of reservation is appreciated but
reserved tickets may be paid for at the IETF.
Reservations
- ------------
To reserve your ticket to the social, please complete and return by
postal mail or electronic mail the reservation form
below. Payment at the time of reservation is appreciated.
Acceptable forms of payment are personal checks, bank checks, or
money orders payable to SunSoft; all funds must be in U.S.
dollars. (No purchase orders or credit cards accepted.)
Postal mail to:
SunSoft
Internet Engineering - IETF Social
2550 Garcia Avenue
M/S UMTV05-44
Mountain View, CA 94043
USA
Electronic mail to: <ietf31-social at Eng.Sun.COM>
Reservations will be accepted until we reach our capacity of 250, or until
November 30, 1994, whichever comes first. If we do not reach the 250
limit through mail-in reservations, additional tickets will be for
sale at the IETF on a first come, first served basis. Reserved tickets
must be purchased by NOON on Tuesday, December 6, 1994.
Cancellations and Refunds
- -------------------------
If you need to cancel a prepaid reservation, please provide
written notification to SunSoft before November 30, 1994 and your
money will be refunded.
Contacting SunSoft
- ------------------
If you have questions about the IETF Social, please contact us by
e-mail at ietf31-social at Eng.Sun.COM>.
- ------------ cut here ---------------
REGISTRATION FORM
-----------------
*** San Jose IETF Social, Tech Museum of Innovation ***
*** Tuesday, December 6, 1994 ***
Please complete this registration form and mail to
SunSoft
Internet Engineering
IETF Social voice: (415) 336-5660
2550 Garcia Avenue, MS MTV05-44 fax: (415) 336-6015
Mt. View, CA 94003 e-mail: ietf31-social at Eng.Sun.COM
USA
Personal checks, money orders, and bank checks in U.S. dollars are
acceptable. Credit cards and purchase orders can not be accepted.
NAME:_____________________________________________
ORGANIZATION:_____________________________________________
ADDRESS:_____________________________________________
_____________________________________________
_____________________________________________
PHONE:___________________ FAX:___________________
E-MAIL:_____________________________________________
Number of reservations requested: _____ (Please list the names of
your guests.)
________________________________________________________
________________________________________________________
________________________________________________________
Number of persons attending ______ x US$35.00 per person = US$_________
TOTAL DUE
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05246;
10 Nov 94 11:05 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05239;
10 Nov 94 11:05 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08691;
10 Nov 94 11:05 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05223;
10 Nov 94 11:05 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05187;
10 Nov 94 11:03 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa08639; 10 Nov 94 11:03 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-14.dialip.mich.net [35.1.48.215]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA01247 for <ietf at CNRI.Reston.VA.US>; Thu, 10 Nov 1994 11:03:05 -0500
Date: Thu, 10 Nov 94 14:34:25 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3423.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: IPng Last Call -- Mobility
Due to the large amount of traffic that has been generated under this
subject which has _not_ been related to the "IPng Last Call", I will
suspend my own request for no comments on comments, in order to clarify
a glaring inaccuracy (and personal attack) introduced by one participant:
> From: Matt Crawford <crawdad at fnal.fnal.gov>
> And a dose of flim-flam went into this magic figure. Compare
> Simpson's white paper's section 3.2:
>
> Mobile Nodes are expected to be able to change their point of
> attachment no more frequently than once per second.
>
> Changes in topology which occur more frequently must be handled at
> the link layer transparently to the internetwork layer. It is
> further noted that engineering margins may require the link layer to
> handle all changes at a frequency in the neighborhood of 10 seconds.
>
> with his 5.1:
>
> ... In order to meet the frequency requirement of changing
> point of attachment once per second, the registration messages must
> not total more than 120 bytes for a complete transaction, including
> link and internet headers.
>
> A requirement to support an operation at most once per second and
> perhaps once per 10 seconds was transmuted into a requirement to
> support it at *least* once per second.
>
That's correct.
If the required registration frequency maximum is once per second, then
the registration round trip MUST occur within a second. How else?
Perhaps magic?
It follows that if the messages are too long, then the once per second
requirement will not be met.
The link-layer itself may have engineering considerations which require
the link-itself to handle all changes on the order of 10 seconds.
EIA/TIA IS-41 comes to mind.
Never-the-less, I would not expect to restrict _all_ links, just because
_some_ links change at slower intervals.
I find it often helps to consider actual implementations, rather than
kibitzing from the sidelines....
> Note also the inconsistent assumptions about header prediction in
> sections 5, 5.2, and 5.3.
>
Pray enlighten us?
Bill.Simpson at um.cc.umich.edu
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05640;
10 Nov 94 11:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09214;
10 Nov 94 11:31 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05629;
10 Nov 94 11:31 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05006;
10 Nov 94 10:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-disc-01.txt
Date: Thu, 10 Nov 94 10:54:09 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9411101054.aa05006 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : SYNCHRONIZATION OPERATIONS FOR
DISCONNECTED IMAP4 CLIENTS
Author(s) : R. Austein
Filename : draft-ietf-imap-disc-01.txt
Pages : 8
Date : 11/09/1994
This note attempts to address some of the issues involved in building a
disconnected IMAP4 client. In particular, it deals with the issues of what
might be called the "driver" portion of the synchronization tool: the
portion of the code responsible for issuing the correct set of IMAP4
commands to synchronize the disconnected client in the way that is most
likely to make the human who uses the disconnected client happy.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-imap-disc-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-imap-disc-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-imap-disc-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19941109120118.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-disc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-disc-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941109120118.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05756;
10 Nov 94 11:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05750;
10 Nov 94 11:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09311;
10 Nov 94 11:35 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05741;
10 Nov 94 11:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05684;
10 Nov 94 11:33 EST
Received: from feta.cisco.com by CNRI.Reston.VA.US id aa09255;
10 Nov 94 11:33 EST
Received: (bstewart at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id IAA12041; Thu, 10 Nov 1994 08:33:23 -0800
Date: Thu, 10 Nov 1994 08:33:23 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <bstewart at cisco.com>
Message-Id: <199411101633.IAA12041 at feta.cisco.com>
To: stev at ftp.com
Cc: dcrocker at mordor.stanford.edu, jnc at ginger.lcs.mit.edu,
ietf at CNRI.Reston.VA.US
In-Reply-To: <9411101543.AA15549 at mailserv-D.ftp.com> (stev at ftp.com)
Subject: Re: IPng Last Call -- Mobility
>anyway, while facinating, it suprises me that the list has not risen
>up and told us to move this conversation to the mobile IP mailing
>list . . .
Er, ah, yeah, ah, hey, you guys, go take this specialized discussion to the
appropriate mailing list.
(It's been so quiet here I forgot to complain. And the discussion just sort
of crept in.)
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05933;
10 Nov 94 11:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05927;
10 Nov 94 11:46 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09537;
10 Nov 94 11:46 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05917;
10 Nov 94 11:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05865;
10 Nov 94 11:43 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa09439;
10 Nov 94 11:43 EST
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id IAA28387; Thu, 10 Nov 1994 08:42:56 -0800
Message-Id: <v0300070faae7f454049f at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 Nov 1994 08:43:02 -0800
To: stev at ftp.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng Last Call -- Mobility
Cc: ietf at CNRI.Reston.VA.US
Stev,
At 7:43 AM 11/10/94, stev at ftp.com wrote:
> may be inevitable, since (for example) I believe that transport needs to
> modify its retransmission scheme to take advantage of the alternate paths.
...
>connection thru the current route is dead, and, since it is
>configured to never give up, asks the ip to find another router, then
>there is no reason to put the mobility code in the tcp. a few simple
You're in the right ballpark, though the details of my proposal lead to a
different conclusion (or, for this discussion, I should perhaps say down a
different path...)
The premise is that the "fail-over" mechanism will only work quickly enough
if the alternate path(s) are already available and maybe even in use.
Waiting for routing protocol(s) to determine that a path is out won't be
quick enough.
In effect, it suggests using parallel paths -- known to the TCP code -- and
when it has to do a retransmission, it send out a different path than it
did before.
Further, the TCP code would keep track of retransmissions, etc. for each of
the paths and calculate 'goodness' of each. My guess is that this will be
at least as sensitive a calculation as the congestion stuff has proved to
be, and therefore will constitute a significant change to TCP. In any
event it requires state information and that makes it not so good to put at
the Internet layer.
A word about my use of 'path' -- probably redundant with an earlier note:
It equates into multiple IP address pairs, between the two hosts. This
does not guarantee parallelism inside the Internet fabric, of course, but
hosts that really care about this will configure their attachments to
increase the likelihood.
d/
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email: dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06128;
10 Nov 94 11:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06124;
10 Nov 94 11:56 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09736;
10 Nov 94 11:56 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <LAA01272 at pad-thai.cam.ov.com>; Thu, 10 Nov 1994 11:20:35 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA07698; Thu, 10 Nov 94 11:18:22 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id IAA15674; Thu, 10 Nov 1994 08:17:57 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA20640; Thu, 10 Nov 94 08:06:20 -0800
Date: Thu, 10 Nov 94 08:06:20 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9411101606.AA20640 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: P.V.McMahon at rea0803.wins.icl.co.uk
Subject: Re: MS Windows Bindings
Cc: cat-ietf at mit.edu, billg at ocsg.com, Joe Kovara <joe.kovara at ocsg.com>
Reply-To: dpg at ocsg.com
> > > > Is RFC 1509 and the Draft K5 Mech RFC going to be updated? If
> > > > they are not going to be updated then the Windows API should
> > > > remain consistent with them.
> > > As there are, as far as I am aware, no existing MS Windows
> > > GSS-API application consumers, I don't see any
> > > practical problem in fixing the API where it's currently
> > > (apparently) got problems.
> > There is an existing GSS-API for Windows in use.
>
> Good.
>
> Is it the same as RFC 1509? If so, it won't work in a 16 bit MS
> Windows 3.1 environment without at least the mods to use
> far and pascal, so I assume that it isn't.
>
The following is an example declaration. _GSS_DECL, CONST, and FAR
are defined depending upon the compile environment.
OM_uint32 _GSS_DECL
gss_display_status
_GSS_PROTO(
(OM_uint32 FAR*, /* minor_status OUT */
OM_uint32, /* status_value IN */
i_32, /* status_type IN */
CONST gss_OID, /* mech_type IN, OPTIONAL */
i_32 FAR*, /* message_context OUT */
gss_buffer_t /* status_string OUT */
));
> If it is the same as RFC 1509, then which of the two possible
> types does it use for time_req as input to
> gss_init_sec_context, and which type does it use for
> status_value as input to gss_display_status?
OM_uint32 _GSS_DECL
gss_init_sec_context
_GSS_PROTO(
(OM_uint32 FAR*, /* minor_status OUT */
CONST gss_cred_id_t, /* claimant_cred_handle IN, OPTIONAL */
gss_ctx_id_t FAR*, /* context_handle OUT */
CONST gss_name_t, /* target_name IN */
CONST gss_OID, /* mech_type IN, OPTIONAL */
i_32, /* req_flags IN */
OM_uint32, /* time_req IN */
CONST gss_cb_t, /* input_chan_bindings IN, OPTIONAL */
CONST gss_buffer_t, /* input_token IN */
gss_OID FAR* CONST, /* actual_mech_type OUT */
gss_buffer_t, /* output_token, OUT */
i_32 FAR*, /* ret_flags OUT, OPTIONAL */
OM_uint32 FAR* /* time_rec OUT, OPTIONAL */
));
OM_uint32 _GSS_DECL
gss_display_status
_GSS_PROTO(
(OM_uint32 FAR*, /* minor_status OUT */
OM_uint32, /* status_value IN */
i_32, /* status_type IN */
CONST gss_OID, /* mech_type IN, OPTIONAL */
i_32 FAR*, /* message_context OUT */
gss_buffer_t /* status_string OUT */
));
> Is its specification public? If so, can you post it, or the
> salient points, to the cat-ietf list?
>
CyberSAFE's Windows GSS-API DLL was developed and in
production use last July. There are many similarities
between CyberSAFE's implementation and the proposed
specification.
In the previous prototypes the tokens _GSS_DECL,
_GSS_PROTO, i_32, CONST, and FAR are determined at
*compile time* as is OM_uint32. If the CAT group is
interested in how these tokens are determined and the
modifications I have made to the GSS-API prototype
declarations then I ask for permission to release them.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07189;
10 Nov 94 13:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07183;
10 Nov 94 13:23 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11521;
10 Nov 94 13:23 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07173;
10 Nov 94 13:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07111;
10 Nov 94 13:21 EST
Received: from ns.Novell.COM by CNRI.Reston.VA.US id aa11472;
10 Nov 94 13:21 EST
Received: from by ns.Novell.COM (4.1/SMI-4.1)
id AB07412; Thu, 10 Nov 94 11:19:41 MST
Date: Thu, 10 Nov 94 11:19:41 MST
Message-Id: <9411101819.AB07412 at ns.Novell.COM>
X-Sender: minshall at optics.wc.novell.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: stev at ftp.com, dcrocker at mordor.stanford.edu,
mohta at necom830.cc.titech.ac.jp
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: greg_minshall at novell.com
Subject: Re: IPng Last Call -- Mobility
Cc: ietf at CNRI.Reston.VA.US
Stev, Dave, Masataka,
There *is* a "mobile IP" mailing list
(<mobile-ip-request at sunroof.Eng.Sun.COM> to bootstrap into signing up for
the list). Trying to invent protocols on the IETF list is silly; trying to
invent protocols from first principles when other people having been
looking at the problem for some time is almost always silly.
Greg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07820;
10 Nov 94 13:58 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07811;
10 Nov 94 13:58 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12337;
10 Nov 94 13:58 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07790;
10 Nov 94 13:58 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07722;
10 Nov 94 13:55 EST
Received: from RUTGERS.EDU by CNRI.Reston.VA.US id aa12239; 10 Nov 94 13:55 EST
Received: from texbell.sbc.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA09653; Thu, 10 Nov 94 13:53:36 EST
Received: from sauron.sbc.com by texbell.sbc.com (4.1/SMI-4.1)
id AA20762; Thu, 10 Nov 94 12:41:11 CST
Received: by sauron.sbc.com (/\==/\ Smail3.1.22.1 #22.6)
id <m0r5ece-000020C at sauron.sbc.com>; Thu, 10 Nov 94 12:53 CST
Received: by elvis.sbc.com (4.1/SMI-4.1)
id AA08615; Thu, 10 Nov 94 12:48:32 CST
Date: Thu, 10 Nov 94 12:48:32 CST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Scott M. Pfeffer" <sp9183 at elvis.sbc.com>
Message-Id: <9411101848.AA08615 at elvis.sbc.com>
To: dcrocker at mordor.stanford.edu, mohta at necom830.cc.titech.ac.jp
Subject: Re: IPng Last Call -- Mobility
Cc: ietf at CNRI.Reston.VA.US, stev at ftp.com
Masataka Ohta says:
:>
:> At the part which identifies a host. That is, at the IP layer.
:> Absolutely not individual TCP connections.
:>
:> No two TCP end points on a host make different movement.
At present this is true. However, perhaps now is not too bad a time
to consider applications on stationary hosts that may move between
systems, rather than just hosts that move with stationary applications.
Why not support both? Heretical, indeed!
:>
:> As all the TCP end points on a host moves as a whole, doing mobility
:> on each TCP is a total waste of effort (and you are also suggesting
:> to abandon UDP)..
:>
:> Masataka Ohta
--Scott
Scott Pfeffer "Can you SEE the lion's head"
Information Services
Southwestern Bell Telephone (314) 235-7213 sp9183 at swuts.sbc.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08268;
10 Nov 94 14:16 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08262;
10 Nov 94 14:16 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12911;
10 Nov 94 14:16 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08247;
10 Nov 94 14:16 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08200;
10 Nov 94 14:14 EST
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa12826; 10 Nov 94 14:14 EST
Received: from ftp.com by ftp.com ; Thu, 10 Nov 1994 14:14:12 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Thu, 10 Nov 1994 14:14:12 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA19528; Thu, 10 Nov 94 14:13:53 EST
Date: Thu, 10 Nov 94 14:13:53 EST
Message-Id: <9411101913.AA19528 at mailserv-D.ftp.com>
To: dcrocker at mordor.stanford.edu
Subject: Re: IPng Last Call -- Mobility
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Thu Nov 10 14:13:45 1994]
Originating-Client: d-cell.ftp.com
Content-Length: 2540
The premise is that the "fail-over" mechanism will only work quickly enough
if the alternate path(s) are already available and maybe even in use.
sure.
Waiting for routing protocol(s) to determine that a path is out won't be
quick enough.
this assumes that the routing protocol is throwing away all but the
best path, and not keeping the less optimal one around. *ofcourse*,
we *both* know that hosts shoudl not be involved in routing decisions
. . . it seems to me that keeping this failover decision in the IP
allows for an optimization that keeping it in the TCP doesnt. if it
is in the IP, when one route fails only one tcp needs to figure it out.
the others can ride along on the new route for free. now, this is
something that needs some Deep Thought(tm) to determine if it is the
Right Thing(sm) to do . . . .
In effect, it suggests using parallel paths -- known to the TCP code -- and
when it has to do a retransmission, it send out a different path than it
did before.
sorry, this sounds like my tcp is *much* to involved in my IP's business.
while i am not a strick layerist, i believe in keeping my protocols
"out of each others knickers".
Further, the TCP code would keep track of retransmissions, etc. for each of
the paths and calculate 'goodness' of each. My guess is that this will be
at least as sensitive a calculation as the congestion stuff has proved to
be, and therefore will constitute a significant change to TCP. In any
event it requires state information and that makes it not so good to put at
the Internet layer.
this is completely true. it seems to me that you are getting to the
point where you need something other than TCP, since you are going
to be interested in playing games with your transmissions to determine
(probably continuously) the best stragedy. useful for something like
a video stream . . . .
A word about my use of 'path' -- probably redundant with an earlier note:
It equates into multiple IP address pairs, between the two hosts. This
does not guarantee parallelism inside the Internet fabric, of course, but
hosts that really care about this will configure their attachments to
increase the likelihood.
the problem though is that i am not worried about the attachment
point my PC has to the net. i am *much* more worried about the
attachment point my net has to the world. i have found that alot more
of the connectivity problems i see are caused by something "out there".
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08416;
10 Nov 94 14:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08410;
10 Nov 94 14:24 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13112;
10 Nov 94 14:24 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08399;
10 Nov 94 14:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08367;
10 Nov 94 14:21 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa13047;
10 Nov 94 14:21 EST
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id LAA29340; Thu, 10 Nov 1994 11:17:28 -0800
Message-Id: <v0300071daae81eccfed0 at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 Nov 1994 11:17:35 -0800
To: greg_minshall at novell.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng Last Call -- Mobility
Cc: stev at ftp.com, mohta at necom830.cc.titech.ac.jp, ietf at CNRI.Reston.VA.US
Greg,
At 10:19 AM 11/10/94, greg_minshall at Novell.COM wrote:
>(<mobile-ip-request at sunroof.Eng.Sun.COM> to bootstrap into signing up for
thanks for giving folks the citation.
>the list). Trying to invent protocols on the IETF list is silly; trying to
Please forgive my sense of compulsion in clarifying: I was NOT trying to
invent a protocol. My proposal has been presented elsewhere and a version
specified. My original submission was in response to a "last call" message
and I was raising (only) a basic question of approach, seeking to
understand the degree of interest that might exist for alternative
medicine.
Note, for example, that the mobile-ip working group is -- not surprisingly
-- inventing a solution that entails changes to IP, rather than some other
part of the stack...
But yes, I agree that pursuit of the fine-grained details is not
appropriate for the IETF list.
d/
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email: dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08429;
10 Nov 94 14:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08425;
10 Nov 94 14:24 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13124;
10 Nov 94 14:24 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <NAA04502 at pad-thai.cam.ov.com>; Thu, 10 Nov 1994 13:54:58 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: P.V.McMahon at rea0803.wins.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA26625; Thu, 10 Nov 94 13:52:52 EST
X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed;
Thu, 10 Nov 1994 18:51:38 +0000
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2));
Relayed; Thu, 10 Nov 1994 18:49:17 +0000
Date: Thu, 10 Nov 1994 18:49:17 +0000
X400-Originator: P.V.McMahon at rea0803.wins.icl.co.uk
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;rea0803 0000016300011840]
Original-Encoded-Information-Types: undefined (0)
X400-Content-Type: P2-1984 (2)
Content-Identifier: 11840
Message-Id: <"11840*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS>
To: dpg at ocsg.com
Cc: cat-ietf at mit.edu, billg at ocsg.com, Joe Kovara <joe.kovara at ocsg.com>
In-Reply-To: <9411101606.AA20640 at war04.ocsg.com>
Subject: Re: MS Windows Bindings
> In the previous prototypes the tokens _GSS_DECL,
> _GSS_PROTO, i_32, CONST, and FAR are determined at
> *compile time* as is OM_uint32. If the CAT group is
> interested in how these tokens are determined and the
> modifications I have made to the GSS-API prototype
> declarations then I ask for permission to release them.
I wish you had mentioned it when I first polled for interest
months ago, as it could saved me inventing, and implementing,
a binding myself :-)
I would encourage you to identify any substantive
differences between what has been proposed to the list, and
what you have defined.
Observation:
I believe that you didn't have as a goal the binary
compatibility of different vendors' implementations as
you seem to require your credential and context types
(and others) to be recompiled into user applications.
Is this a fair comment?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10526;
10 Nov 94 16:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10518;
10 Nov 94 16:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15863;
10 Nov 94 16:06 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10508;
10 Nov 94 16:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10428;
10 Nov 94 16:04 EST
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa15807; 10 Nov 94 16:04 EST
Received: from ftp.com by ftp.com ; Thu, 10 Nov 1994 16:00:19 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Thu, 10 Nov 1994 16:00:19 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA21131; Thu, 10 Nov 94 15:59:50 EST
Date: Thu, 10 Nov 94 15:59:50 EST
Message-Id: <9411102059.AA21131 at mailserv-D.ftp.com>
To: dcrocker at mordor.stanford.edu
Subject: Re: IPng Last Call -- Mobility
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stev at ftp.com
Cc: greg_minshall at novell.com, stev at ftp.com, mohta at necom830.cc.titech.ac.jp,
ietf at CNRI.Reston.VA.US
X-Orig-Sender: stev at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Thu Nov 10 15:59:34 1994]
Originating-Client: d-cell.ftp.com
Content-Length: 232
Note, for example, that the mobile-ip working group is -- not surprisingly
-- inventing a solution that entails changes to IP, rather than some other
part of the stack...
and they are doing it in the routing area:)
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10718;
10 Nov 94 16:14 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16030;
10 Nov 94 16:14 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10700;
10 Nov 94 16:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10576;
10 Nov 94 16:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15915;
10 Nov 94 16:09 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10567;
10 Nov 94 16:09 EST
To: IETF-Announce: ;
Reply-To: ietf31-social at eng.sun.com
Subject: DECEMBER '94 IETF: Social (update)
Date: Thu, 10 Nov 94 16:09:49 -0500
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9411101609.aa10567 at IETF.CNRI.Reston.VA.US>
FYI,
For those of you who encountered difficulty in replying to
to the first social announcement, please try again. The problem
has been taken care of.
Megan
------- Forwarded Message
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04865;
10 Nov 94 10:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08346;
10 Nov 94 10:49 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04704;
10 Nov 94 10:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04353;
10 Nov 94 10:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07992;
10 Nov 94 10:37 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id ab04346;
10 Nov 94 10:37 EST
To: IETF-Announce: ;
Reply-To: ietf31-social at eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: ietf31-social at eng.sun.com
Subject: DECEMBER '94 IETF: Social Event
Date: Thu, 10 Nov 94 10:37:29 -0500
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9411101037.ab04346 at IETF.CNRI.Reston.VA.US>
Invitation for IETF 31 Social
Tuesday, December 6, 1994
7:00 pm to 10:00 pm
SunSoft invites you to join us for an evening of exploration, food and
drinks at the San Jose Tech Museum of Innovation the evening of Tuesday,
December 6, 1994. The Tech Museum, located at 145 W. San Carlos Street
(1 block from the San Jose Fairmont), allows visitors to touch and explore
new technologies and innovations emerging out of Silicon Valley.
Food and Beverages
- - ------------------
Our buffet will include a pasta bar with Ravioli, Tortellini and Fusilli,
a Mexican bar with build it yourself nachos and fajitas and a fruit
bar complete with Chantilly cream, brown sugar and chocolate fondue.
One beverage ticket will be issued to each attendee which may be used
for soda, bottled water, non-alcholic beer, beer or wine.
Coffee, tea and delicious desserts will also be provided.
Additional beverages will be available from the cash bar.
Costs
- - -----
US$35.00 per attendee. The ticket price covers food and one
beverage (entrance to the Tech Museum is courtesy of SunSoft).
To assure your space, your reservation must be received by November 30, 1994.
Receipt of payment at the time of reservation is appreciated but
reserved tickets may be paid for at the IETF.
Reservations
- - ------------
To reserve your ticket to the social, please complete and return by
postal mail or electronic mail the reservation form
below. Payment at the time of reservation is appreciated.
Acceptable forms of payment are personal checks, bank checks, or
money orders payable to SunSoft; all funds must be in U.S.
dollars. (No purchase orders or credit cards accepted.)
Postal mail to:
SunSoft
Internet Engineering - IETF Social
2550 Garcia Avenue
M/S UMTV05-44
Mountain View, CA 94043
USA
Electronic mail to: <ietf31-social at Eng.Sun.COM>
Reservations will be accepted until we reach our capacity of 250, or until
November 30, 1994, whichever comes first. If we do not reach the 250
limit through mail-in reservations, additional tickets will be for
sale at the IETF on a first come, first served basis. Reserved tickets
must be purchased by NOON on Tuesday, December 6, 1994.
Cancellations and Refunds
- - -------------------------
If you need to cancel a prepaid reservation, please provide
written notification to SunSoft before November 30, 1994 and your
money will be refunded.
Contacting SunSoft
- - ------------------
If you have questions about the IETF Social, please contact us by
e-mail at ietf31-social at Eng.Sun.COM>.
- - ------------ cut here ---------------
REGISTRATION FORM
-----------------
*** San Jose IETF Social, Tech Museum of Innovation ***
*** Tuesday, December 6, 1994 ***
Please complete this registration form and mail to
SunSoft
Internet Engineering
IETF Social voice: (415) 336-5660
2550 Garcia Avenue, MS MTV05-44 fax: (415) 336-6015
Mt. View, CA 94003 e-mail: ietf31-social at Eng.Sun.COM
USA
Personal checks, money orders, and bank checks in U.S. dollars are
acceptable. Credit cards and purchase orders can not be accepted.
NAME:_____________________________________________
ORGANIZATION:_____________________________________________
ADDRESS:_____________________________________________
_____________________________________________
_____________________________________________
PHONE:___________________ FAX:___________________
E-MAIL:_____________________________________________
Number of reservations requested: _____ (Please list the names of
your guests.)
________________________________________________________
________________________________________________________
________________________________________________________
Number of persons attending ______ x US$35.00 per person = US$_________
TOTAL DUE
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11506;
10 Nov 94 16:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11500;
10 Nov 94 16:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16741;
10 Nov 94 16:47 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11488;
10 Nov 94 16:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11458;
10 Nov 94 16:45 EST
Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa16719;
10 Nov 94 16:45 EST
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA24453; Fri, 11 Nov 1994 08:13:51 +1100 (from kre at munnari.OZ.AU)
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: IPng Last Call -- Mobility
In-Reply-To: Your message of "Wed, 09 Nov 1994 18:36:02 -0800."
<v03000705aae733cc0726 at [128.102.17.23]>
Date: Fri, 11 Nov 1994 08:13:40 +1100
Message-Id: <13001.784502020 at munnari.OZ.AU>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Robert Elz <kre at munnari.oz.au>
Date: Wed, 9 Nov 1994 18:36:02 -0800
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Message-ID: <v03000705aae733cc0726 at [128.102.17.23]>
1. ease of adoption by pairwise host implementation rather than modifying
the underlying Interent fabric
If we were doing this five years ago, or five years hence, this
would be a strong argument. Right now its silly, we're already
in the process of ripping apart the entire Internet fabric and
changing all the hosts, if we can slot in whatever is needed
now it will cost essentially nothing to achieve it everywhere,
and in fact, would be one more selling point to get IPv6 more
widely adopted more quickly.
Pairwise implementation will just make mobile hosts second
class citizens, able only to talk to a small number of specially
modified other hosts. Whatever we do, expecting me to upgrade
my hosts so your mobile host can communicate just isn't going
to work, all you'll end up being able to talk to in general
will be your own home base.
3. eliminating the claimed need for an EID
The claimed need for an EID is not for mobility - mobility
just seems to be one place where the presence of an EID may
be of some assistance. That there may be other ways in that
particular case is not terribly significant.
I sent a note to Big-Internet last month, in which I asked
how we were planning to administer the in-addr.arpa (or its
equiv) domain if we're using IPv6 addresses for number -> name
mapping, given we're also planning to have the prefixes assigned
to sites vary over time as topology changes. I am yet to
see even a suggestion of a reply - it looks to me as if no-one
has wanted to think about this.
kre
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12097;
10 Nov 94 17:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12087;
10 Nov 94 17:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17247;
10 Nov 94 17:12 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12075;
10 Nov 94 17:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12036;
10 Nov 94 17:10 EST
Received: from ns.Novell.COM by CNRI.Reston.VA.US id aa17222;
10 Nov 94 17:10 EST
Received: from by ns.Novell.COM (4.1/SMI-4.1)
id AB02558; Thu, 10 Nov 94 15:10:04 MST
Date: Thu, 10 Nov 94 15:10:04 MST
Message-Id: <9411102210.AB02558 at ns.Novell.COM>
X-Sender: minshall at optics.wc.novell.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: perry at imsi.com, ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: greg_minshall at novell.com
Subject: Re: IPng Last Call -- Mobility
Cc: ji at cs.columbia.edu, karn at qualcomm.com
Perry,
>If we build a mobility support layer, are people going to go out there
>and build a brand new mobile IP radio network? No. People who are
>actually doing mobile computing fall into two categories -- those that
>are doing it in a local area, who will appear to be on a radio lan
>like one of the several commercial ones available who will simply be
>able to use the normal IP stack via a router to the radio lan base
>station and who will appear stationary to the IP network, and those
>who will be using the cellular phones network and who will again
>appear to be stationary with respect to the IP network.
The pushes for IP mobility are different for LAN and WAN mobility.
For LAN mobility, your model breaks down when someone walks from one "radio
lan base" (rlb) to another rlb, and the two rlb's are on separate subnets.
At that point, all communications stop. IP mobility, as defined by the
mobile-ip wg, solves this (or purports to).
For WAN mobility, the *real* benefit of IP mobility comes *when* we figure
out how to short cut the "dogleg" (aka, "triangular") routing. (Both the
end user and the provider will benefit by this short cutting.)
Greg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12241;
10 Nov 94 17:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12231;
10 Nov 94 17:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17396;
10 Nov 94 17:19 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12210;
10 Nov 94 17:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12176;
10 Nov 94 17:17 EST
Received: from sundance.itd.nrl.navy.mil by CNRI.Reston.VA.US id aa17354;
10 Nov 94 17:17 EST
Subject: Process migration (was: Re: IPng Last Call -- Mobility)
To: ietf at CNRI.Reston.VA.US
Date: Thu, 10 Nov 1994 17:17:19 -0500 (EST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan McDonald <danmcd at sundance.itd.nrl.navy.mil>
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1282
Message-ID: <9411102217.aa24842 at sundance.itd.nrl.navy.mil>
Masataka Ohta says:
:> No two TCP end points on a host make different movement.
Scott Pfeffer replies:
>At present this is true. However, perhaps now is not too bad a time
>to consider applications on stationary hosts that may move between
>systems, rather than just hosts that move with stationary applications.
>Why not support both? Heretical, indeed!
^^^^^^^^^^^^^^^^^^^^
Because process migration is not (IMHO) a pure networking issue, it is an
overall operating system issue.
Much research was done on process migration in the 1980's with projects such
as Sprite (UC-Berkeley: Ousterhout, et. al.), V (Stanford: Cheriton,
et. al.), and Amoeba (Vrij U., Netherlands: Tanenbaum, et. al.). It's a
hard problem, especially in the face of heterogenous computing resources.
Read any papers on those three operating systems if you are interested in
what they learned.
Once the research is in on this, then maybe we as engineers can start to
argue about it.
--
Daniel L. McDonald | Mail: danmcd at itd.nrl.navy.mil -------------------------+
Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html |
Naval Research Lab | Phone: (202) 404-7122 #include <disclaimer.h> |
Washington, DC | "Rise from the ashes, A blaze of everyday glory" - Rush +
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22942;
11 Nov 94 0:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22936;
11 Nov 94 0:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24426;
11 Nov 94 0:00 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22922;
11 Nov 94 0:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22850;
10 Nov 94 23:58 EST
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa24374;
10 Nov 94 23:58 EST
Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14468(1)>; Thu, 10 Nov 1994 20:58:42 PST
Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Thu, 10 Nov 1994 20:58:29 -0800
To: bsimpson at morningstar.com
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: IPng Last Call -- TreeWork
In-reply-to: bill.simpson's message of Thu, 10 Nov 94 03:48:01 -0800.
<3421.bill.simpson at um.cc.umich.edu>
Date: Thu, 10 Nov 1994 20:58:20 PST
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <94Nov10.205829pst.34050 at swallow.parc.xerox.com>
> From: William Allen Simpson <bill.simpson at um.cc.umich.edu>:
>
> I recommend that the main principles of the IPng Recommendation be
> accepted, but that the size of the address be returned to 64-bits, as in
> the original design team's recommendation, including Deering's
> recommendation of a "short, fat" address allocation.
Bill,
I hate to have to do this: You are citing me out of context.
Yes, if it were up to me, I would still recommend 64-bit addresses for IPng,
and yes, I think a "short, fat" hierarchy is the way to go, but *not* for
the reasons you gave. In particular, I disagree with your contention
that having many levels of hierarchy necessarily implies a choice between
a "treework", explosion of routing table size at the top of the hierarchy,
or many addresses per interface. I proposed, for example, a geographic
addressing hierarchy that (a) was not a treework (clusters at each level of
the hierarchy could be interconnected in an arbitrary topology), (b) had
small table size at the top level of the hierarchy, and (c) required only
one address per interface in the common case (that case being where a
subscriber's connections to each of its providers occurred in the same
metropolitan area). I proposed a relatively shallow hierarchy (country,
metro, subscriber, host), but the same properties would hold if it were
a deeper hierarchy (e.g., continent, country, province, metro, subscriber,
host).
I think the following statement of yours indicates some misunderstanding
of hierarchical routing/addressing:
> If common installation practice continues, and only one address is
> hand-configured for each interface...internet routing would direct
> most traffic through the "root" of the hierarchy. This would swamp
> the root, introducing a single point of failure.
It is true that routing to the most topologically distant destinations
will be handled by routers with a copy of the top-level prefixes in their
routing tables, but there may reasonably be a large number of such routers,
geographically dispersed around the globe, and interconnected in an
arbitrary topology - not what anyone would call "a single point of failure"
or a "root" subject to being "swamped".
The reasons I favor wide, shallow hierarchies are: (a) better quality
routes, (b) fewer levels of address administration, (c) more efficient
use of address space, (d) less frequent need to change addresses as a
result of topological changes, and (e) fewer constraints on the topology.
I also think you misinterpreted the claim of "simpler autoconfiguration"
for 128-bit addresses: it is "simpler" in that one can autoconfigure a
globally-unique and globally-routable address by the "simple" approach
of glueing together a subnet prefix and an (e.g.) IEEE address; in the
case of 64-bit addresses, autoconfiguring a globally-unique and globally-
routable address is a multi-step process, involving a server, which is
less "simple". This has nothing to do with the number of levels of
address hierarchy (as long as that hierarchy doesn't grow into the low-order
48 bits (or so) of the address.
I'm delighted to see your efforts to record objections to the IPng decision
on address size, but I wish you'd get the arguments right! :-)
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23705;
11 Nov 94 1:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23699;
11 Nov 94 1:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26181;
11 Nov 94 1:56 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23688;
11 Nov 94 1:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23636;
11 Nov 94 1:54 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa26102;
11 Nov 94 1:54 EST
Received: by ginger.lcs.mit.edu
id AA29040; Fri, 11 Nov 94 01:54:18 -0500
Date: Fri, 11 Nov 94 01:54:18 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9411110654.AA29040 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: IPng Last Call -- TreeWork
Cc: deering at parc.xerox.com, jnc at ginger.lcs.mit.edu
From: Steve Deering <deering at parc.xerox.com>
It is true that routing to the most topologically distant destinations
will be handled by routers with a copy of the top-level prefixes in their
routing tables, but there may reasonably be a large number of such routers,
geographically dispersed around the globe, and interconnected in an
arbitrary topology
Hmm. What's your guess as to how many of these top-level routers there will
be, worldwide, by, say, 2010?
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24088;
11 Nov 94 2:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24078;
11 Nov 94 2:51 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26948;
11 Nov 94 2:51 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24063;
11 Nov 94 2:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23981;
11 Nov 94 2:30 EST
Received: from [131.112.32.132] by CNRI.Reston.VA.US id aa26689;
11 Nov 94 2:30 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 11 Nov 94 16:21:52 +0859
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9411110722.AA01590 at necom830.cc.titech.ac.jp>
Subject: Re: IPng Last Call -- TreeWork
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Date: Fri, 11 Nov 94 16:21:51 JST
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com, jnc at ginger.lcs.mit.edu
In-Reply-To: <9411110654.AA29040 at ginger.lcs.mit.edu>; from "Noel Chiappa" at Nov 11, 94 1:54 am
X-Mailer: ELM [version 2.3 PL11]
If the requirement to IPng is to support 10^15 hosts, note that
48*LOG2(1)=14.4<15.
That is, 48bit MAC can not be globally unique.
Is it OK?
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00395;
11 Nov 94 3:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00389;
11 Nov 94 3:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00898;
11 Nov 94 3:54 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00373;
11 Nov 94 3:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00304;
11 Nov 94 3:42 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa00602;
11 Nov 94 3:42 EST
Received: by ginger.lcs.mit.edu
id AA00103; Fri, 11 Nov 94 03:41:59 -0500
Date: Fri, 11 Nov 94 03:41:59 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9411110841.AA00103 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US, perry at imsi.com
Subject: Re: IPng Last Call -- Mobility
Cc: jnc at ginger.lcs.mit.edu
From: "Perry E. Metzger" <perry at imsi.com>
It may be heretical to say this, but I suspect that the IP suite will
ultimately have nothing to do with the way real world mobility gets
implemented.
I find it always pays to give serious consideration to heretical thoughts...
In short, I think this is going to be handled in the layers below IP. Real
users aren't going to care about the IP mobility support because they'll
just be using the built in IP support in their CDMA phones ... The mobility
support will go in far below the IP layer and none of our IP mobility work
will matter.
If they have built truly global systems (to allow large-scale scope for
mobility), they're going to wind up recreating all the mechanism of the
internetwork at the network (Data Link) layer, just like ATM.
I know there are practical arguments as to why this gets done; service
providers don't want to tie their flag to a technology that i) they don't
control, and ii) may not do what they want. However, *in the long run*, as we
upgrade the capability of the basic internetwork architecture, I think the
replication of mechanism at multiple layers will prove a complication and
expense we can do without.
I thus persist in thinking we should attack it at the internetwork layer,
not below. We'll see, I guess.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01590;
11 Nov 94 8:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01584;
11 Nov 94 8:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04450;
11 Nov 94 8:26 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01573;
11 Nov 94 8:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01532;
11 Nov 94 8:22 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa04392;
11 Nov 94 8:22 EST
Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-19)
id <AA12379>; Fri, 11 Nov 1994 05:22:45 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bmanning at isi.edu
Posted-Date: Fri, 11 Nov 1994 05:21:38 -0800 (PST)
Message-Id: <199411111321.AA07301 at zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-4)
id <AA07301>; Fri, 11 Nov 1994 05:21:38 -0800
Subject: in-addr for v6
To: Robert Elz <kre at munnari.oz.au>
Date: Fri, 11 Nov 1994 05:21:38 -0800 (PST)
Cc: dcrocker at mordor.stanford.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: <13001.784502020 at munnari.OZ.AU> from "Robert Elz" at Nov 11, 94 08:13:40 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 525
>
> I sent a note to Big-Internet last month, in which I asked
> how we were planning to administer the in-addr.arpa (or its
> equiv) domain if we're using IPv6 addresses for number -> name
> mapping, given we're also planning to have the prefixes assigned
> to sites vary over time as topology changes. I am yet to
> see even a suggestion of a reply - it looks to me as if no-one
> has wanted to think about this.
>
Well some people are think of how to do this. Just nothing worth putting
done on phosphor yet.
--bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01795;
11 Nov 94 8:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01789;
11 Nov 94 8:46 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04717;
11 Nov 94 8:46 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01767;
11 Nov 94 8:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01743;
11 Nov 94 8:45 EST
Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa04700; 11 Nov 94 8:45 EST
Received: by rodan.UU.NET
id QQxpog10350; Fri, 11 Nov 1994 08:44:45 -0500
Message-Id: <QQxpog10350.199411111344 at rodan.UU.NET>
To: bmanning at isi.edu
cc: Robert Elz <kre at munnari.oz.au>, dcrocker at mordor.stanford.edu,
ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Louis A. Mamakos" <louie at alter.net>
Subject: Re: in-addr for v6
In-reply-to: Your message of "Fri, 11 Nov 1994 05:21:38 PST."
<199411111321.AA07301 at zed.isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10349.784561485.1 at rodan.UU.NET>
Date: Fri, 11 Nov 1994 08:44:45 -0500
X-Orig-Sender: louie at uunet.uu.net
> >
> > I sent a note to Big-Internet last month, in which I asked
> > how we were planning to administer the in-addr.arpa (or its
> > equiv) domain if we're using IPv6 addresses for number -> name
> > mapping, given we're also planning to have the prefixes assigned
> > to sites vary over time as topology changes. I am yet to
> > see even a suggestion of a reply - it looks to me as if no-one
> > has wanted to think about this.
> >
>
> Well some people are think of how to do this. Just nothing worth putting
> done on phosphor yet.
Personally, I'd like to see an architecture which didn't require this
ugly reverse-mapping thing. Judging from how often this IN-ADDR.ARPA
thing gets done wrong or just plain forgetten today, it would be nice
to think of ways to build the system which didn't require this.
Off the top of my head: how about a well-know UDP-like service that
you could bounce a packet off which would return the name of the host
at that address? Thinking about this, you can trust this information
about as much as you can trust the equivilent response from a name
server for the IN-ADDR.ARPA domain name. It's very likely that
specific addreses that you're interested in will have IP connectivity.
And you can certainly cache this information localally.
Just a thought,
Louis A. Mamakos louie at alter.net
UUNET Technologies, Inc. uunet!louie
3110 Fairview Park Dr., Suite 570 Voice +1 703 204 8023
Falls Church, Va 22042 Fax +1 703 204 8001
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02058;
11 Nov 94 9:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02052;
11 Nov 94 9:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05110;
11 Nov 94 9:10 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02043;
11 Nov 94 9:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01995;
11 Nov 94 9:09 EST
Received: from panix.com by CNRI.Reston.VA.US id aa05066; 11 Nov 94 9:09 EST
Received: by panix.com id AA21663
(5.67b/IDA-1.5 for ietf at CNRI.Reston.VA.US); Fri, 11 Nov 1994 09:05:42 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Hawkinson <jhawk at panix.com>
Message-Id: <199411111405.AA21663 at panix.com>
Subject: Re: in-addr for v6
To: "Louis A. Mamakos" <louie at alter.net>
Date: Fri, 11 Nov 1994 09:05:42 -0500 (EST)
Cc: bmanning at isi.edu, kre at munnari.oz.au, dcrocker at mordor.stanford.edu,
ietf at CNRI.Reston.VA.US
In-Reply-To: <QQxpog10350.199411111344 at rodan.UU.NET> from "Louis A. Mamakos" at Nov 11, 94 08:44:45 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 873
> From: "Louis A. Mamakos" <louie at alter.net>
> Personally, I'd like to see an architecture which didn't require this
> ugly reverse-mapping thing. Judging from how often this IN-ADDR.ARPA
> thing gets done wrong or just plain forgetten today, it would be nice
> to think of ways to build the system which didn't require this.
>
> Off the top of my head: how about a well-know UDP-like service that
> you could bounce a packet off which would return the name of the host
> at that address?
How much of this is a complaint about DNS's implementation, rather
than it's protocol? After all, if named generated .in-addr.arpa (or
.ip6.int. or whatever) zones all by its lonesome (assuming that somehow
the problems of delegation and differences between IP allocations versus
domain names were worked out), wouldn't this be the same thing?
--
John Hawkinson
jhawk at panix.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02227;
11 Nov 94 9:20 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02217;
11 Nov 94 9:20 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05302;
11 Nov 94 9:20 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02206;
11 Nov 94 9:20 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02163;
11 Nov 94 9:18 EST
Received: from FRED.BBN.COM by CNRI.Reston.VA.US id aa05259; 11 Nov 94 9:18 EST
To: Thomas Pfenning <pfenning at epcc.ed.ac.uk>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: IPng Job mobility
In-reply-to: Your message of Wed, 09 Nov 94 20:45:57 +0000.
<9411092046.ZM1996 at epcc.ed.ac.uk>
Date: Fri, 11 Nov 94 09:03:16 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at bbn.com>
Message-ID: <9411110918.aa05259 at CNRI.Reston.VA.US>
Hi Thomas:
There's a pretty extensive literature on the problem of migrating jobs.
Most of those solutions involve having forwarding points that notify
communicating entities that the job has migrated. (An exception is the
VMTP protocol). I'm travelling this week, but if you remind me, I can
send you a list of references when I get home.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02740;
11 Nov 94 10:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02734;
11 Nov 94 10:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06103;
11 Nov 94 10:06 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02713;
11 Nov 94 10:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02669;
11 Nov 94 10:04 EST
Received: from wintermute.imsi.com by CNRI.Reston.VA.US id aa06042;
11 Nov 94 10:04 EST
Received: from relay.imsi.com by wintermute.imsi.com
id KAA21291; Fri, 11 Nov 1994 10:04:31 -0500
Received: from snark.imsi.com by relay.imsi.com
id KAA12624; Fri, 11 Nov 1994 10:04:30 -0500
Received: by snark.imsi.com (4.1/SMI-4.1)
id AA26427; Fri, 11 Nov 94 10:04:29 EST
Message-Id: <9411111504.AA26427 at snark.imsi.com>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US, karn at qualcomm.com, ji at cs.columbia.edu
Subject: Re: IPng Last Call -- Mobility
In-Reply-To: Your message of "Fri, 11 Nov 1994 03:41:59 EST."
<9411110841.AA00103 at ginger.lcs.mit.edu>
Reply-To: perry at imsi.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 11 Nov 1994 10:04:28 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Perry E. Metzger" <perry at imsi.com>
This is going to look like a rant. I apologize in advance. I don't
mean to offend people who have been working hard on Mobile IP. I just
mean to ask a hard and heretical question.
Noel Chiappa says:
> In short, I think this is going to be handled in the layers
> below IP. Real users aren't going to care about the IP mobility
> support because they'll just be using the built in IP support in
> their CDMA phones ... The mobility support will go in far below
> the IP layer and none of our IP mobility work will matter.
>
> If they have built truly global systems (to allow large-scale scope for
> mobility), they're going to wind up recreating all the mechanism of the
> internetwork at the network (Data Link) layer, just like ATM.
Certainly but, remember that they have to. The cellular phone network
*is* a network, not just a data link layer, and thats because their
customers demand to be able to reach people :-). The cellular phone
network is already going global.
Certainly it might be argued that the cellphone people are
re-implementing the network layer, but it might also be argued by
cellphone people that we are just re-creating all the cellular
techniques that they have already mastered. I think they understand
how to do these things better than we do. They have practical
experience with a mobile network of millions of users and we don't.
There are lots of real advantages to letting the cellphone people
worry about this, by the way. Also remember that many of them grok
internetworking fairly well. Phil Karn works for Qualcomm.
The real question is this -- where will Mobile IP lead? Are people
going to deploy whole new radio networks worldwide to provide mobile
IP nodes with service? Are there people out there who are going to
sell this service to people? No. There are cellphone networks being
built, though. The "radio ethernet" systems I've seen don't face the
wide area scaling problems deeply enough to need the cell-handoff
sledgehammer applied to them.
I believe (just as many of the rest of the internet crowd do) that our
technology is going to take over all communications of all
sorts. However, we are building a solution in search of a problem. NO
ONE IS GOING TO BUILD THESE NETWORKS. No one is going to spend the
very real billions of dollars that ubiquitous Mobile IP networks would
cost, and no one is even worrying about issues like "what frequencies
do we use" and "what radio modems do we standardize on". Some have
said that these issues aren't important, that they are data link layer
problems, but the point is that unless people actually standardize on
those things all the cute roaming features of Mobile IP will be
useless because no two people will have the same hardware and everyone
with Mobiles other than cellphones will be stuck within a few hundred
yards of their base stations that they deployed at their research
lab. Without data link standards, Mobile IP will be as useful as
owning one ethernet card.
In my opinion, the digital cellphone people will provide us with
connectivity just as the landline phone people provide us with our
leased lines right now. As I see it, Mobile IP's greatest benefits
have been to researchers who've gotten to write lots of good
papers. As a former researcher, I do not denigrate the value of things
that never leave the lab -- they are often very enlightening
experiments -- but I do think that they don't really need
standardization.
Perry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03141;
11 Nov 94 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03135;
11 Nov 94 10:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06782;
11 Nov 94 10:47 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03124;
11 Nov 94 10:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03055;
11 Nov 94 10:45 EST
Received: from fnal.fnal.gov by CNRI.Reston.VA.US id aa06724;
11 Nov 94 10:45 EST
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id
<01HJCKC2PBRK00G1SZ at FNAL.FNAL.GOV>; Fri, 11 Nov 1994 09:45:00 CDT
Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA08220;
Fri, 11 Nov 94 09:44:39 CST
Date: Fri, 11 Nov 1994 09:44:38 -0600
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Matt Crawford <crawdad at fnal.fnal.gov>
Subject: Re: IPng Last Call -- TreeWork
In-reply-to: Your message of Fri,
11 Nov 94 16:21:51 +0900. <9411110722.AA01590 at necom830.cc.titech.ac.jp>
X-Orig-Sender: crawdad at munin.fnal.gov
To: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Cc: ietf at CNRI.Reston.VA.US
Message-id: <9411111544.AA08220 at munin.fnal.gov>
Content-transfer-encoding: 7BIT
> If the requirement to IPng is to support 10^15 hosts, note that
> 48*LOG2(1)=14.4<15.
I don't know why 48*log2(1) is a figure of interest. but its value is
0, not 14.4.
> That is, 48bit MAC can not be globally unique.
Oh, so you're saying 2^48 < 10^15. (Actually 2^46 is a more relevant
number.) Yes, that's certainly true. And almost no one expects the
IEEE MAC address to actually *be* unique, even with 10^7 hosts. What
of it?
_________________________________________________________
Matt Crawford crawdad at fnal.gov Fermilab
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03361;
11 Nov 94 11:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03355;
11 Nov 94 11:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07162;
11 Nov 94 11:08 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03345;
11 Nov 94 11:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03315;
11 Nov 94 11:07 EST
Received: from [13.1.64.93] by CNRI.Reston.VA.US id aa07137; 11 Nov 94 11:07 EST
Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14409(1)>; Fri, 11 Nov 1994 08:06:48 PST
Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Fri, 11 Nov 1994 08:06:40 -0800
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: IPng Last Call -- TreeWork
In-reply-to: jnc's message of Thu, 10 Nov 94 22:54:18 -0800.
<9411110654.AA29040 at ginger.lcs.mit.edu>
Date: Fri, 11 Nov 1994 08:06:37 PST
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <94Nov11.080640pst.34050 at swallow.parc.xerox.com>
Noel,
> Hmm. What's your guess as to how many of these top-level routers there will
> be, worldwide, by, say, 2010?
I haven't a clue -- the politics and economics of Internet routing are too
unpredictable for anyone to know, I think. But in any case, there ought to
be enough of them to not be "a single point of failure" or a bottleneck.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04110;
11 Nov 94 12:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04104;
11 Nov 94 12:30 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08636;
11 Nov 94 12:30 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04092;
11 Nov 94 12:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04052;
11 Nov 94 12:28 EST
Received: from mwunix.mitre.org by CNRI.Reston.VA.US id aa08574;
11 Nov 94 12:28 EST
Return-Path: lazear at dockside.mitre.org
Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id MAA23192; Fri, 11 Nov 1994 12:27:07 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: lazear at dockside.mitre.org
Received: from dockside.mitre.org by gateway.mitre.org (4.1/SMI-4.1)
id AA02029; Fri, 11 Nov 94 12:27:04 EST
Received: by dockside.mitre.org (4.1/SMI-4.1)
id AA07062; Fri, 11 Nov 94 12:23:06 EST
Message-Id: <9411111723.AA07062 at dockside.mitre.org>
To: "Louis A. Mamakos" <louie at alter.net>
Cc: bmanning at isi.edu, Robert Elz <kre at munnari.oz.au>,
dcrocker at mordor.stanford.edu, ietf at CNRI.Reston.VA.US,
lazear at dockside.mitre.org
Subject: Re: in-addr for v6
In-Reply-To: Your message of "Fri, 11 Nov 94 08:44:45 EST."
<QQxpog10350.199411111344 at rodan.UU.NET>
Date: Fri, 11 Nov 94 12:22:59 -0500
Louis A. Mamakos writes:
>Off the top of my head: how about a well-know UDP-like service that
>you could bounce a packet off which would return the name of the host
>at that address?
One could even imagine the returned name being part
of the behavior of "ping" in the brave new world of
IPv6. Ping a host, learn its name.
Walt
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04292;
11 Nov 94 12:43 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04282;
11 Nov 94 12:43 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08867;
11 Nov 94 12:43 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04264;
11 Nov 94 12:43 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04192;
11 Nov 94 12:41 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa08820;
11 Nov 94 12:41 EST
Received: by ginger.lcs.mit.edu
id AA01503; Fri, 11 Nov 94 12:41:20 -0500
Date: Fri, 11 Nov 94 12:41:20 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9411111741.AA01503 at ginger.lcs.mit.edu>
To: deering at parc.xerox.com, jnc at ginger.lcs.mit.edu
Subject: Re: IPng Last Call -- TreeWork
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
From: Steve Deering <deering at parc.xerox.com>
> What's your guess as to how many of these top-level routers there will
> be, worldwide, by, say, 2010?
I haven't a clue -- the politics and economics of Internet routing are too
unpredictable for anyone to know, I think.
How about a guess to within an order of magnitude or two? The overhead of
running the routing is something we need to think about, and without any
idea of how big a system it will be, it's hard to estimate that.
But in any case, there ought to be enough of them to not be "a single
point of failure" or a bottleneck.
Right, but that wasn't what I was thinking about.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04312;
11 Nov 94 12:43 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04306;
11 Nov 94 12:43 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08883;
11 Nov 94 12:43 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04275;
11 Nov 94 12:43 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04213;
11 Nov 94 12:41 EST
Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa08825;
11 Nov 94 12:41 EST
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA06815; Sat, 12 Nov 1994 04:41:24 +1100 (from kre at munnari.OZ.AU)
To: John Hawkinson <jhawk at panix.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: in-addr for v6
In-Reply-To: Your message of "Fri, 11 Nov 1994 09:05:42 CDT."
<199411111405.AA21663 at panix.com>
Date: Sat, 12 Nov 1994 04:41:01 +1100
Message-Id: <13112.784575661 at munnari.OZ.AU>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Robert Elz <kre at munnari.oz.au>
Date: Fri, 11 Nov 1994 09:05:42 -0500 (EST)
From: John Hawkinson <jhawk at panix.com>
Message-ID: <199411111405.AA21663 at panix.com>
How much of this is a complaint about DNS's implementation,
rather than it's protocol?
Its actually neither, its the convention used for in-addr
mapping, which has almost nothing to do with DNS implementation
(the resolver knows the convention as it has to use it), and
nothing at all to do with the protocol.
After all, if named generated .in-addr.arpa (or .ip6.int. or
whatever) zones all by its lonesome
Unfortunatelty, that's not possible, as there is no relationship
between forward & reverse zones, they are independant objects.
If this would work, then the original DNS "iquery" would work
(probably), and none of this would be needed at all.
(assuming that somehow the problems of delegation
This is, of course, the problem I was alluding to - if we can
get the delegation right, all the rest could be automated, the
question is how we manage to automate the delegations in the
face of radically shifting numbers. There's also the problem
of (necessary) glue in forward delegations that needs to be
altered when addresses alter, however that one I think can be
handled with a suitably secure DNS.
and differences between IP allocations versus
domain names were worked out),
I'm not sure what you mean here, it could be you're thinking of
legislating away, somehow, the independance of forward and
reverse zones. That's simply not on, making IP addresses
somehow dependant on domain names has the same effect as
making domain names dependant on IP addresses, and is absolutely
not what we want to do.
wouldn't this be the same thing?
Perhaps, but the "assuming that somehow" is the problem to be
solved I suspect.
kre
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04893;
11 Nov 94 13:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04886;
11 Nov 94 13:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09731;
11 Nov 94 13:31 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04860;
11 Nov 94 13:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04748;
11 Nov 94 13:29 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa09663; 11 Nov 94 13:29 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-23.dialip.mich.net [35.1.48.224]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA21969 for <ietf at CNRI.Reston.VA.US>; Fri, 11 Nov 1994 12:55:47 -0500
Date: Fri, 11 Nov 94 14:40:48 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3426.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: IPng Last Call -- H Factor
> Last Call: The Recommendation for the IP Next Generation Protocol
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
> 11 November.
>
The fourth in a series of comments on IPng. Please, just make
comments for posterity. Don't reply to other comments.
Here are my comments regarding the H(uman) Factor.
----
The IPng Recommendation fails to take Human Factors into account.
RFC-1715 describes the "H Ratio":
log (number of objects)
H = -----------------------
available bits
This ranges from 0 through 0.30103 (log base 10 of 2).
Several examples of addresses which required expansion are given
(including IPv4). The H Ratios for these were:
0.26 DECnet IV (5 digits)
0.26 French telephones (9 digits)
0.24 North American telephones (10 digits)
0.23 IPv4 addresses (16+ digits, depending on representation)
Two outliers were cited:
0.18 IEEE 802.5 numbers. This space is not yet saturated, and no
expansion has been required. The expected lifetime is
unlimited, as the numbers apply only to local links. This
number will therefore improve asymtotically to 0.30.
0.14 SITA (no explanation). This uses ASCII fixed length tokens.
Again, the space has not been saturated. This, however, is
a fine example of badly managed space which was designed for
humans, instead of machines.
Despite the clever idea, RFC-1715 is seriously flawed in its conclusion:
"128 bits is entirely safe for the next 30 year." [sic]
This would also be true for such numbers as 160 bits and 256 bits. But,
we are not looking for the _safety_ of 128 bits. We should determine
the least number of bits which meets the criteria.
The target is 1E15 nodes, and 1E12 networks. Since the projected human
population is 8.5E9 during the lifetime of IPng, this represents more
than 10,000 nodes and 100 networks per person.
These numbers were deliberately chosen to be unrealistically high. It
is very unlikely that each and every single human will personally manage
100 networks, or personally assign 10,000 nodes, in their lifetime. It
is even more unlikely that computing resources will be evenly
distributed among all people.
Human Factors shows that:
- an average human cannot consistently remember a number sequence
(address) of more than 5 figures.
- a 1 standard deviation human cannot consistently remember a number
sequence (address) of more than 7 figures.
- a 3 standard deviation human cannot consistently remember a number
sequence (address) of more than 10 figures.
This explains the apparent variation of the examples. The longer
the sequence attempted by human comprehension, the poorer the human
managability, resulting in a decreasing H Ratio.
This is easily demonstrated by our own experience with IPv4. When the
addresses were divided along tidy boundaries for human comprehension, the
utilization was extremely poor. Assigning the addresses according to
the needs of machine aggregation greatly improved utilization.
Although the number of points are too few for accurate extrapolation,
plotting the expansion in representation of each 2 additional digits
against a standard deviation curve would drastically reduce the expected
"H Ratio". This direction is verified by the 47 digit (160 bit) NSAP
deployment, which currently yields the "H Ratio" of only 0.03 or less.
The inescapable conclusion is that humans cannot comprehend or manage
1e15 addresses, no matter how sparsely allocated.
Assuming machine assignment and management, however, returns the problem
to tractability. Through dynamic reassignment which adapts to actual
topological constraints, machine assignment should easily exceed the
human management of the telephone system, for example.
Pessimistic (0.24) Likely (0.26) Optimistic (0.28)
32 bits 4.8 E+7 2.1 E+8 9.1 E+8
64 bits 2.3 E+15 4.4 E+16 8.3 E+17
80 bits 1.6 E+19 6.3 E+20 2.5 E+22
128 bits 5.2 E+30 1.9 E+33 6.9 E+35
(There was an error in RFC-1715 for 80 bits.)
I recommend that the main principles of the IPng Recommendation be
accepted, but that the size of the address be returned to 64-bits, as in
the original design team's recommendation, including the recommendation
of dynamic reassignment.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04914;
11 Nov 94 13:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04907;
11 Nov 94 13:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09746;
11 Nov 94 13:31 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04858;
11 Nov 94 13:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04728;
11 Nov 94 13:28 EST
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa09653;
11 Nov 94 13:28 EST
Received: by gw.home.vix.com id AA17120; Fri, 11 Nov 94 10:28:42 -0800
Date: Fri, 11 Nov 94 10:28:42 -0800
X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul A Vixie <paul at vix.com>
Subject: Re: in-addr for v6
Organization: Vixie Enterprises
Message-Id: <VIXIE.94Nov11102840 at gw.home.vix.com>
References: <199411111405.AA21663 at panix.com>
Nntp-Posting-Host: gw.home.vix.com
In-Reply-To: jhawk at panix.com's message of 11 Nov 1994 06:45:09 -0800
Address-to-host mapping in a CIDRized IPv4 world is already a problem.
Doing it in IPv6 is just the same problem with more bits.
SRA and I have been thinking about an elegant solution to both. Expect
to hear more about it at the DNSIND WG in San Jose, or at the bar if
Randy holds us to some kind of agenda :-).
--
Paul Vixie
La Honda, CA
<paul at vix.com>
decwrl!vixie!paul
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05043;
11 Nov 94 13:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05037;
11 Nov 94 13:38 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09900;
11 Nov 94 13:38 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05028;
11 Nov 94 13:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04986;
11 Nov 94 13:36 EST
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa09841;
11 Nov 94 13:36 EST
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14527(2)>; Fri, 11 Nov 1994 10:35:36 PST
Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Fri, 11 Nov 1994 10:35:28 -0800
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: IPng Last Call -- TreeWork
In-reply-to: jnc's message of Fri, 11 Nov 94 09:41:20 -0800.
<9411111741.AA01503 at ginger.lcs.mit.edu>
Date: Fri, 11 Nov 1994 10:35:15 PST
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <94Nov11.103528pst.12173 at skylark.parc.xerox.com>
Noel,
> > What's your guess as to how many of these top-level routers there will
> > be, worldwide, by, say, 2010?
>
> I haven't a clue -- the politics and economics of Internet routing are
> too unpredictable for anyone to know, I think.
>
> How about a guess to within an order of magnitude or two?
No fewer than 100. No more than 10,000.
> But in any case, there ought to be enough of them to not be "a single
> point of failure" or a bottleneck.
>
> Right, but that wasn't what I was thinking about.
But that's all I was writing about.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05560;
11 Nov 94 14:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05554;
11 Nov 94 14:22 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10714;
11 Nov 94 14:22 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05545;
11 Nov 94 14:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05501;
11 Nov 94 14:20 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa10638;
11 Nov 94 14:20 EST
Received: by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA08751>; Fri, 11 Nov 1994 11:20:06 -0800
Date: Fri, 11 Nov 1994 11:20:06 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Postel <postel at isi.edu>
Message-Id: <199411111920.AA08751 at zephyr.isi.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: in-addr for v6
Hi.
How about modeling it after the RFC 1706 approach to the same problem for
NSAPs ?
--jon.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05597;
11 Nov 94 14:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05593;
11 Nov 94 14:23 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10750;
11 Nov 94 14:23 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <NAA29097 at pad-thai.cam.ov.com>; Fri, 11 Nov 1994 13:51:50 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from gatekeeper.icl.co.uk by MIT.EDU with SMTP
id AA11227; Fri, 11 Nov 94 13:39:36 EST
Received: by gatekeeper.icl.co.uk (4.1/UNIPALM-Vevision: 1.3 gatekeeper.icl.co.uk)
id AA24451; Fri, 11 Nov 94 18:42:23 GMT
Received: from unknown(145.227.14.59) by gatekeeper via smap (V1.3mjr)
id sma024443; Fri Nov 11 18:42:09 1994
Received: from trojan.oasis.icl.co.uk by ming.oasis.icl.co.uk
id AA23573; Fri, 11 Nov 94 18:40:01 GMT
Message-Id: <9411111840.AA29771 at getafix.oasis.icl.co.uk>
Date: Fri, 11 Nov 94 18:40:57 GMT
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: MS Windows Bindings
To: dpg at ocsg.com
Cc: cat-ietf at mit.edu
Cc: billg at ocsg.com
Cc: joe.kovara at ocsg.com
When I asked if your windows spec supported binary compatibility
of GSS-API implementations provided by different vendors, you said:
> our goal was RFC 1509 compliance
I guess this is to be interpreted as "RFC 1509 plus fars and
pascals in the obvious places".
RFC 1509 compliance (using the above interpretation) would imply
that application source code written to RFC 1509 would work
when re-compiled against an arbitrary vendor's gssapi.h, and link
with the same arbitrary vendor's GSS-API library / object code.
The envisaged binary compatibility (in the pending I-D) means
that GSS-API-users application binaries can link with arbitrary
vendors' GSS-API DLLs.
Binary compatibility means additional prescriptive specification
to that given in RFC 1509, rather than something in conflict.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05695;
11 Nov 94 14:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05689;
11 Nov 94 14:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10895;
11 Nov 94 14:33 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05679;
11 Nov 94 14:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05634;
11 Nov 94 14:30 EST
Received: from ns.Novell.COM by CNRI.Reston.VA.US id aa10855;
11 Nov 94 14:30 EST
Received: from [130.57.64.153] by ns.Novell.COM (4.1/SMI-4.1)
id AA24367; Fri, 11 Nov 94 12:30:33 MST
Date: Fri, 11 Nov 94 12:30:32 MST
Message-Id: <9411111930.AA24367 at ns.Novell.COM>
X-Sender: minshall at optics.wc.novell.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: lazear at dockside.mitre.org
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: greg_minshall at novell.com
Subject: Re: in-addr for v6
Cc: ietf at CNRI.Reston.VA.US
>IPv6. Ping a host, learn its name.
Ping a host, get back an echo of what you sent the host. Want to learn a
host's name? Send a DNS packet to something; not ping. Bah.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06056;
11 Nov 94 15:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06050;
11 Nov 94 15:07 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11500;
11 Nov 94 15:07 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06025;
11 Nov 94 15:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05963;
11 Nov 94 15:05 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11458;
11 Nov 94 15:05 EST
Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-19)
id <AA25476>; Fri, 11 Nov 1994 12:05:09 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bmanning at isi.edu
Posted-Date: Fri, 11 Nov 1994 12:03:53 -0800 (PST)
Message-Id: <199411112003.AA08176 at zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-4)
id <AA08176>; Fri, 11 Nov 1994 12:03:53 -0800
Subject: Re: in-addr for v6
To: Paul A Vixie <paul at vix.com>
Date: Fri, 11 Nov 1994 12:03:53 -0800 (PST)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <VIXIE.94Nov11102840 at gw.home.vix.com> from "Paul A Vixie" at Nov 11, 94 10:28:42 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 103
Well, there is always the tweek to RFC 1706 that should serve this purpose.
(I think...:)
--
--bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06201;
11 Nov 94 15:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06197;
11 Nov 94 15:25 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11803;
11 Nov 94 15:25 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA27742 at pad-thai.cam.ov.com>; Fri, 11 Nov 1994 12:54:21 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA05268; Fri, 11 Nov 94 12:42:06 EST
Received: from sickly.cybersafe.com (sickly.cybersafe.com [192.156.168.11]) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with SMTP id JAA23502; Fri, 11 Nov 1994 09:41:53 -0800
Received: by sickly.cybersafe.com (NX5.67d/NX3.0S)
id AA12069; Fri, 11 Nov 94 09:41:51 -0800
Date: Fri, 11 Nov 94 09:41:51 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <dennisg at sickly.cybersafe.com>
Message-Id: <9411111741.AA12069 at sickly.cybersafe.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: P.V.McMahon at rea0803.wins.icl.co.uk
Subject: Re: MS Windows Bindings
Cc: cat-ietf at mit.edu, billg at ocsg.com, Joe Kovara <joe.kovara at ocsg.com>
> > In the previous prototypes the tokens _GSS_DECL,
> > _GSS_PROTO, i_32, CONST, and FAR are determined at
> > *compile time* as is OM_uint32. If the CAT group is
> > interested in how these tokens are determined and the
> > modifications I have made to the GSS-API prototype
> > declarations then I ask for permission to release them.
>
> I wish you had mentioned it when I first polled for
> interest months ago, as it could saved me inventing, and
> implementing, a binding myself :-)
>
I was interested and I read the e-mail exchanges too. I am not a
Windows kind-of-guy so my value, to the Windows clientele, is
limited.
> I would encourage you to identify any substantive
> differences between what has been proposed to the list,
> and what you have defined.
>
I added two functions, gss_open() and gss_close(), to
CyberSAFE's GSS-API primarily targeted for DOS,
Windows, and Macintosh applications. They have other
advantages too. The CAT group may want to consider the
functions gss_open() and gss_close() as part of a future
standard. They address a deficiency.
The functions gss_open() and gss_close() provide the
developer with choices. Here are two applications I
found the gss_open() and gss_close() useful.
* On initialization a mechanism may need to use
inaccessible network resources. For example, a
Kerberos mechanism may need to communicate with a KDC
located on the opposite end of a PPP link -- or use DNS to
form a principal. The application needs to insure the PPP
link is established before initializing the GSS-API and
its mechanisms.
* A technique to further reduce security risk -- the
compromise of credential cache files for example --
would be: initialize the GSS-API and its mechanisms;
perform a task, then release the resources.
The function gss_close() has proven useful in various
operating systems that do not release memory
allocations when an application exits. The function
gss_close() gives the GSS-API and its mechanisms the
opportunity to release those resources.
> Observation:
> I believe that you didn't have as a goal the binary
> compatibility of different vendors' implementations as
> you seem to require your credential and context types
> (and others) to be recompiled into user applications.
> Is this a fair comment?
>
Our goal was RFC-1509 compliance.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06272;
11 Nov 94 15:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06266;
11 Nov 94 15:28 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11850;
11 Nov 94 15:28 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06255;
11 Nov 94 15:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06212;
11 Nov 94 15:26 EST
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa11826;
11 Nov 94 15:26 EST
Received: from UW-Gateway.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA22478; Fri, 11 Nov 94 12:26:32 -0800
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA16342; Fri, 11 Nov 94 12:26:24 -0800
Date: Fri, 11 Nov 1994 11:52:14 -0800 (PST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: re: IPng Last Call -- H Factor
To: bsimpson at morningstar.com
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <3426.bill.simpson at um.cc.umich.edu>
Message-Id: <MailManager.784583534.12429.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Let me say up front that this proposal is with tongue firmly in cheek. I have
no intention of trying to derail IPng, and in this 64 vs 128 question I come
down firmly on the 128 side.
Rather, I'm just doing to go on the record now, so that a decade or two later
I can say ``I told you so!!!!!'' With any luck, by the time this happens my
mortgage will be paid, my retirement funds will be fattened, and I will be
able to escape actually having to *implement* it.
On Fri, 11 Nov 94 14:40:48 GMT, William Allen Simpson wrote:
> This would also be true for such numbers as 160 bits and 256 bits. But,
> we are not looking for the _safety_ of 128 bits. We should determine
> the least number of bits which meets the criteria.
My belief is that the minimum number of bits needed is 512, and that if IPng
uses an inadequate 128 we'll only end up having to come back and do IPnng in
another decade or two. The more I read these conversations, the more
convinced I am that 128 vs 64 are both rear-guard actions; 128 is a futile
attempt to prevent a need for IPnng, and 64 is a futile attempt to keep IP
numbers memorable.
Let me make a heretical observation:
In all likelihood there is only one way to bury IN-ADDR.ARPA -- bury DNS.
That is, as long as we have a system in which there are names for humans to
use, and numbers for machines to use, there will be a need to translate names
to numbers and numbers to names.
But the underlying beliefs behind these translations are flawed. They are not
reversible operations. Name-to-number can give you a set of numbers, or not a
number at all but rather a ``try this set of names''. The application level
is expected to sort this mess out, and determine which number it should use.
Number-to-name may give you a completely different name and this may not be a
bug at all (the false expectations of certain FTP servers and mailers
notwithstanding).
Even my little Panda.COM domain and 192.107.14 network exhibit both phenomena;
that is, multihoming and multiple A records for the same address (and no, I
can NOT use a CNAME because there isn't 100% overlap of addresses between the
two names).
Every day, I get to see how poorly applications sort it all out. Even if
multiple IP addresses are value, not all IP addresses are created equal. For
all its vaunted features, UNIX maintains a statue in the Hall of Shame; you
end up having to create and maintain a *host table* to override the IP address
selections that would happen from DNS, and certain tools (most notably mount
and mountd) get very confused by multi-homing and multi-naming.
This has led me to believe that
Numbers Are Evil And Should Be Abolished
The source and destination addresses in IP headers should be <roll drums>
====> NAMES <====
not numbers!
We went from 8 to 32 a little over a decade ago. 32 to 128 is a new factor of
four increase and will probably see us through another decade or so. With
only an additional factor of four (which IPnng will have to do anyway), we
could chose names and be done with it.
Of course, that glosses over routing. But, I can't imagine router developers
objecting to something that will guarantee them full employment into
perpetuity. Application developers benefit too; they can totally ignore
routing issues (which, at present, they can not).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06822;
11 Nov 94 16:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06816;
11 Nov 94 16:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12647;
11 Nov 94 16:18 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06798;
11 Nov 94 16:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06762;
11 Nov 94 16:16 EST
Received: from BBN.COM by CNRI.Reston.VA.US id aa12615; 11 Nov 94 16:16 EST
Received: from GAAK.BBN.COM by BBN.COM id aa00338; 11 Nov 94 16:08 EST
Date: Fri, 11 Nov 1994 16:08:36 EST
Message-ID: <map=1994Nov11160836 at gaak.bbn.com>
To: kre at munnari.oz.au
CC: jhawk at panix.com, ietf at CNRI.Reston.VA.US
In-reply-to: <13112.784575661 at munnari.OZ.AU> (message from Robert Elz on Sat, 12 Nov 1994 04:41:01 +1100)
Subject: Re: in-addr for v6
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Michael A. Patton" <MAP at bbn.com>
Reply-To: "Michael A. Patton, special reply address" <MAP=Reply at bbn.com>
Date: Sat, 12 Nov 1994 04:41:01 +1100
From: Robert Elz <kre at munnari.oz.au>
Date: Fri, 11 Nov 1994 09:05:42 -0500 (EST)
From: John Hawkinson <jhawk at panix.com>
After all, if named generated .in-addr.arpa (or .ip6.int. or
whatever) zones all by its lonesome
Unfortunatelty, that's not possible, as there is no relationship
between forward & reverse zones, they are independant objects.
I agree with you to a certain extent (I'm always trying to explain how
the two heirarchies don't have to correspond, and even have an RFC in
the works that speaks to this very point. However, while the address
delegation and the name delegation are conceptually completely
independant, both follow some administrative delegation model, there
is thus often at least a loose correlation. While at MIT I was
working on a tool which (among other things) would take the name of an
in-addr domain (in the form of an address written front-wards if you
want) to generate and a list of all the forward domains that might
contain hosts in that portion of the address space. It would then
search those forward domains for addresses in the desired zone and
write the in-addr.arpa zone file. I suspect that this would be a
simple way to handle 99 and 44/100ths percent of all cases. (apologies
to Ivory :-).
If this would work, then the original DNS "iquery" would work
(probably), and none of this would be needed at all.
Not quite. "iquery" would have required resolvers and servers
(programs) to know the loose correlation. This _is_ a pretty
intractable problem. For a technique like I described above, the zone
administrator (a human, presumably at least marginally intelligent)
needs to know (and tell the program). I bet most zone administrators
_do_ know this.
-MAP
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07450;
11 Nov 94 17:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07442;
11 Nov 94 17:24 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13819;
11 Nov 94 17:24 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07429;
11 Nov 94 17:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07397;
11 Nov 94 17:22 EST
Received: from deathstar.epilogue.com by CNRI.Reston.VA.US id aa13767;
11 Nov 94 17:22 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rob Austein <sra at epilogue.com>
X-Orig-Sender: sra at deathstar.epilogue.com
To: ietf at CNRI.Reston.VA.US
In-reply-to: Jon Postel's message of Fri, 11 Nov 1994 11:20:06 -0800 <199411111920.AA08751 at zephyr.isi.edu>
Subject: Re: in-addr for v6
Date: Fri, 11 Nov 94 17:22:01 -0500
Message-ID: <9411111722.aa19188 at deathstar.epilogue.com>
Date: Fri, 11 Nov 1994 11:20:06 -0800
From: Jon Postel <postel at isi.edu>
How about modeling it after the RFC 1706 approach to the same problem for
NSAPs ?
RFC-1706 grew out of the same basic ideas that we used as a starting
point, but Paul and I think we may have a slightly more elegant
solution. As Paul says, check the DNSIND meeting, or maybe the bar.
--Rob Austein <sra at epilogue.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07518;
11 Nov 94 17:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07512;
11 Nov 94 17:29 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13907;
11 Nov 94 17:29 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07503;
11 Nov 94 17:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07444;
11 Nov 94 17:24 EST
Received: from necom830.cc.titech.ac.jp by CNRI.Reston.VA.US id aa13814;
11 Nov 94 17:24 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 12 Nov 94 07:16:13 +0900
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9411112216.AA00307 at necom830.cc.titech.ac.jp>
Subject: Re: IPng Last Call -- TreeWork
To: Matt Crawford <crawdad at fnal.bitnet>
Date: Sat, 12 Nov 94 7:16:11 JST
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9411111544.AA08220 at munin.fnal.gov>; from "Matt Crawford" at Nov 11, 94 9:44 am
X-Mailer: ELM [version 2.3 PL11]
> > If the requirement to IPng is to support 10^15 hosts, note that
> > 48*LOG2(1)=14.4<15.
>
> I don't know why 48*log2(1) is a figure of interest. but its value is
> 0, not 14.4.
Oops, 48*log2(10).
> And almost no one expects the
> IEEE MAC address to actually *be* unique, even with 10^7 hosts. What
> of it?
Everyone assuumes factory configured IEEE MAC unique within ones LAN.
If not, even intra-LAN communication is impossible.
In the autoconfigured world of IPv6, no one should be forced to manally
set MAC addresses.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08124;
11 Nov 94 18:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08118;
11 Nov 94 18:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15100;
11 Nov 94 18:40 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08107;
11 Nov 94 18:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08067;
11 Nov 94 18:38 EST
Received: from tipper.oit.unc.edu by CNRI.Reston.VA.US id aa15060;
11 Nov 94 18:38 EST
Received: from LOCALHOST.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02)
id AA11402; Fri, 11 Nov 94 18:38:29 EST
Message-Id: <9411112338.AA11402 at tipper.oit.unc.edu>
To: greg_minshall at novell.com
Cc: lazear at dockside.mitre.org, ietf at CNRI.Reston.VA.US
Subject: Re: in-addr for v6
In-Reply-To: Your message of "Fri, 11 Nov 94 12:30:32 MST."
<9411111930.AA24367 at ns.Novell.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Nov 94 18:38:28 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
Actually, as an optimisation, couldn't the DNS name be used as a compressed
form of the address :-)
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08682;
11 Nov 94 19:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08672;
11 Nov 94 19:30 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15889;
11 Nov 94 19:30 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08610;
11 Nov 94 19:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08513;
11 Nov 94 19:28 EST
Received: from pluto.ulcc.ac.uk by CNRI.Reston.VA.US id aa15846;
11 Nov 94 19:28 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Peter Furniss <cziwprf at pluto.ulcc.ac.uk>
Message-Id: <5995.9411120028 at pluto.ulcc.ac.uk>
Subject: Re: IPng H Factor & in-addr for v6 (and vN)
To: ietf <ietf at CNRI.Reston.VA.US>
Date: Sat, 12 Nov 1994 00:28:48 +0000 (GMT)
In-Reply-To: <MailManager.784583534.12429.mrc at Ikkoku-Kan.Panda.COM> from "Mark Crispin" at Nov 11, 94 11:52:14 am
Reply-To: P.Furniss at ulcc.ac.uk
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 883
Two recent threads seem to have crossed over. My comment is perhaps
the result of a short-circuit
> That is, as long as we have a system in which there are names for humans to
> use, and numbers for machines to use, there will be a need to translate names
> to numbers and numbers to names.
You do not need to translate numbers to names if you follow the OSI
upper-layer pattern of being able, if you wish, to carry the name of
the source and destination. The receiver can (if wants to) do name to
number look-up to see if the source number is plausible - or, if it is
wiser, can use the name to lookup public-key.
This of course needs a middleware layer between transport and specific
application. It doesnt need all the glory of OSI upper-layers (not
even as much as is in the thinosi cookbook = rfc1698).
Were the OSI architects right - in-addr won't scale ?
Peter Furniss
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08994;
11 Nov 94 19:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08988;
11 Nov 94 19:55 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16263;
11 Nov 94 19:55 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08979;
11 Nov 94 19:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08952;
11 Nov 94 19:54 EST
Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa16230;
11 Nov 94 19:54 EST
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA18363; Sat, 12 Nov 1994 10:14:20 +1100 (from kre at munnari.OZ.AU)
To: "Michael A. Patton, special reply address" <MAP=Reply at bbn.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: in-addr for v6
In-Reply-To: Your message of "Fri, 11 Nov 1994 16:08:36 EST."
<map=1994Nov11160836 at gaak.bbn.com>
Date: Sat, 12 Nov 1994 10:14:16 +1100
Message-Id: <13233.784595656 at munnari.OZ.AU>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Robert Elz <kre at munnari.oz.au>
Date: Fri, 11 Nov 1994 16:08:36 EST
From: "Michael A. Patton" <MAP at BBN.COM>
Message-ID: <map=1994Nov11160836 at gaak.bbn.com>
For a technique like I described above, the zone
administrator (a human, presumably at least marginally intelligent)
needs to know (and tell the program).
This is exactly the problem - the system you describe will
probably work well enough now that it could be very useful.
With IPv6, addresses are supposed to be able to dynamically
change - if that is how it turns out, we can't really be relying
on humans updating files all over the place, both because the
volume of work will be too great, and because some will get
forgotten, leading to an almighty mess.
If this is to work at all, it has to be totally automated,
and not rely on humans, however intelligent we can assume they
are.
There have been (in other messages) a couple of references to
rfc1706 on this topic. The techniques in rfc1706 are just fine
(rfc1706 relates to nsap reverse mapping), and something like
that can doubless solve the technical issues of how to
represent the address for lookups, and the formats of RR's,
etc. We could discuss the details, but not here, but there's
no question that the DNS techniques are a tractable problem, and
not even a difficult one.
Its the dynamics that make this hard, not the bit twiddling.
kre
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09164;
11 Nov 94 20:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09158;
11 Nov 94 20:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16447;
11 Nov 94 20:06 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09138;
11 Nov 94 20:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09107;
11 Nov 94 20:05 EST
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa16419;
11 Nov 94 20:05 EST
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14497(4)>; Fri, 11 Nov 1994 17:04:59 PST
Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Fri, 11 Nov 1994 17:04:52 -0800
To: Mark Crispin <MRC at panda.com>
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: IPng Last Call -- H Factor
In-reply-to: MRC's message of Fri, 11 Nov 94 11:52:14 -0800.
<MailManager.784583534.12429.mrc at Ikkoku-Kan.Panda.COM>
Date: Fri, 11 Nov 1994 17:04:48 PST
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <94Nov11.170452pst.12173 at skylark.parc.xerox.com>
Mark,
I know you said your message was tongue-in-cheek, but just to keep the
other cheek honest...
> ...64 is a futile attempt to keep IP numbers memorable.
No, it was a futile attempt to prevent gargantuan packet headers. But the
payload lobby doesn't have much influence in this community.
32-bit addresses are already too big for me to remember.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09319;
11 Nov 94 20:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09313;
11 Nov 94 20:23 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16698;
11 Nov 94 20:23 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09304;
11 Nov 94 20:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09270;
11 Nov 94 20:22 EST
Received: from [35.1.1.42] by CNRI.Reston.VA.US id aa16684; 11 Nov 94 20:22 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm035-07.dialip.mich.net [141.211.7.18]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id UAA24603 for <ietf at CNRI.Reston.VA.US>; Fri, 11 Nov 1994 20:22:13 -0500
Date: Sat, 12 Nov 94 01:00:12 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3432.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: IPng Last Call -- TreeWork
> From: Steve Deering <deering at parc.xerox.com>
> The reasons I favor wide, shallow hierarchies are: (a) better quality
> routes, (b) fewer levels of address administration, (c) more efficient
> use of address space, (d) less frequent need to change addresses as a
> result of topological changes, and (e) fewer constraints on the topology.
>
> I'm delighted to see your efforts to record objections to the IPng decision
> on address size, but I wish you'd get the arguments right! :-)
>
Your points are excellent.
My arguments are not quite the same as yours, yet arrive at the same
results.
For example, when you say:
> ... but there may reasonably be a large number of such routers,
> geographically dispersed around the globe, and interconnected in an
> arbitrary topology ...
>
I assume that since this is a change in topology, a new expanded root,
then _all_ the subordinate addresses will change to match!
Thus making autoconfiguration harder, rather than easier, and changes
more likely, rather than less.
Anyway, thanks for registering your Last Call comments.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09584;
11 Nov 94 20:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09578;
11 Nov 94 20:55 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17158;
11 Nov 94 20:55 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09566;
11 Nov 94 20:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09539;
11 Nov 94 20:53 EST
Received: from deathstar.epilogue.com by CNRI.Reston.VA.US id aa17111;
11 Nov 94 20:53 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rob Austein <sra at epilogue.com>
X-Orig-Sender: sra at deathstar.epilogue.com
To: ietf at CNRI.Reston.VA.US
In-reply-to: Peter Furniss's message of Sat, 12 Nov 1994 00:28:48 +0000 (GMT) <5995.9411120028 at pluto.ulcc.ac.uk>
Subject: Re: IPng H Factor & in-addr for v6 (and vN)
Date: Fri, 11 Nov 94 20:53:30 -0500
Message-ID: <9411112053.aa19431 at deathstar.epilogue.com>
From: Peter Furniss <cziwprf at pluto.ulcc.ac.uk>
Date: Sat, 12 Nov 1994 00:28:48 +0000 (GMT)
You do not need to translate numbers to names if you follow the OSI
upper-layer pattern of being able, if you wish, to carry the name of
the source and destination. The receiver can (if wants to) do name to
number look-up to see if the source number is plausible - or, if it is
wiser, can use the name to lookup public-key.
Other than the public keys, this sounds pretty much like what Mark
Crispin and I did when we added DNS support to the TOPS-20 mailsystem,
back around 1986.
This of course needs a middleware layer between transport and specific
application. It doesnt need all the glory of OSI upper-layers (not
even as much as is in the thinosi cookbook = rfc1698).
This needs a middleware layer? That's odd, I could have sworn I saw
it working just fine with SMTP over a TCP connection.
Were the OSI architects right - in-addr won't scale ?
No. IN-ADDR is a problem because the tools people are using are
inadaquate, not because the architecture is flawed.
There are reaons why somebody might look up an address other than
because they want to know about a current connection. To do so on a
global scale requires some kind of index. Either the index is
precomputed (a la IN-ADDR) or it's the network itself (ask the machine
who it thinks it is). There are arguments for doing it either way,
but if you want to get into that, the discussion should move to
Namedroppers, it doesn't really belong on the IETF list.
--Rob Austein <sra at epilogue.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09758;
11 Nov 94 21:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09752;
11 Nov 94 21:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17610;
11 Nov 94 21:10 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09740;
11 Nov 94 21:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09711;
11 Nov 94 21:08 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa17571;
11 Nov 94 21:08 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA23813>; Fri, 11 Nov 1994 18:08:20 -0800
Message-Id: <199411120208.AA23813 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: ietf at CNRI.Reston.VA.US
Subject: Internet Monthly Report - October 1994
Reply-To: cooper at isi.edu
Date: Fri, 11 Nov 94 18:08:20 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
October 1994
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
This report is for Internet information purposes only, and is not
to be quoted in other publications without permission from the
submitter.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to:
Ann Westine Cooper (Cooper at ISI.EDU)
NSF Regional reports - To obtain the procedure describing how to
submit information for the Internet Monthly Report, send an email
message to mailserv at is.internic.net and put "send imr-procedure" in
the body of the message (add only that one line; do not put a
signature).
Requests to be added or deleted from the Internet Monthly report list
should be sent to "imr-request at isi.edu".
Details on obtaining the current IMR, or back issues, via FTP or
EMAIL may be obtained by sending an EMAIL message to "rfc-
info at ISI.EDU" with the message body "help: ways_to_get_imrs". For
example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
Cooper [Page 1]
Internet Monthly Report October 1994
TABLE OF CONTENTS
INTERNET RESEARCH REPORTS . . . . . . . . . . . . . . . . page 3
RESOURCE DISCOVERY AND DIRECTORY SERVICE . . .. . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
INTERNET PROJECTS
ANSNET/NSFNET BACKBONE ENGINEERING . . . . . . . . . . . page 8
BOLT BERANEK AND NEWMAN, INC., . . . . . . . . . . . . . page 11
CSUNET. . . . . . . . . . . . . . . . . . . . . . . . . . page 13
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 14
ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 19
MERIT/NSFNET ENGINEERING. . . . . . . . . . . . . . . . . page 31
MIDNET. . . . . . . . . . . . . . . . . . . . . . . . . . page 33
NORTHWESTNET . . . . . . . . . . . . . . . . . . . . . . page 35
PREPNet . . . . . . . . . . . . . . . . . . . . . . . . . page 37
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 38
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . page 40
Rare List of Meetings . . . . . . . . . . . . . . . . . page 44
Cooper [Page 2]
Internet Monthly Report October 1994
INTERNET RESEARCH REPORTS
-------------------------
RESOURCE DISCOVERY AND DIRECTORY SERVICE
----------------------------------------
The Internet Research Task Force Research Group on Resource
Discovery (IRTF-RD) has made its Harvest software system
available on the Internet.
Harvest is an integrated set of tools to gather, extract,
organize, search, cache, and replicate relevant information
across the Internet. With modest effort users can tailor
Harvest to digest information in many different formats, and
offer custom search services on the Internet. Moreover, Harvest
makes very efficient use of network traffic, remote servers, and
disk space.
We have built a number of content indexes with Harvest,
including an index of AT&T's 1-800 phone numbers, an index of
WWW home pages, and an index of over 24,000 Computer Science
technical reports from around the world.
We have been beta testing Harvest for four months, and starting
today are making the software available on the Internet. You
can get to demonstrations, papers, software and documentation at
http://harvest.cs.colorado.edu/.
Mike Schwartz, IRTF-RD Chair
Mike Schwartz (schwartz at latour.cs.colorado.edu)
INTERNET ENGINEERING REPORTS
----------------------------
1. Let me remind everyone that the next IETF meeting will be in San
Jose, California from December 5-9, and the Registration
Reception will held on Sunday, December 4th. San Jose logistic
information and draft agendas have already been sent to the IETF
announcement list and made available via gopher and on the Web.
The IETF meetings for 1995 are starting to firm up. The IETF
will be meeting in Danvers, Massachusetts (a suburb of Boston)
from April 3-7, 1995. The summer IETF meeting will be held in
Stockholm, Sweden the week of July 17-21, 1995. Due to the
meeting costs, the IETF attendance fee for the Stockholm meeting
will be US$300.
Cooper [Page 3]
Internet Monthly Report October 1994
The final meeting for 1995 will be held in Dallas, Texas. Once
all the arrangements have been made, notifications will be sent
to the IETF Announcement list. Remember that information on
future IETF meetings can be always be found in the file 0mtg-
sites.txt which is located on the IETF shadow directories. This
information can also be viewed from the IETF Home Page on the
Web. The URL is:
http://www.ietf.cnri.reston.va.us/home.html
2. The minutes of the IESG teleconferences have been publicly
available on the IETF Shadow directories since 1991. These files
are placed in the /ftp/iesg directory.
The following IESG minutes have been added:
September 22, 1994 (iesg.94-09-22)
October 6, 1994 (iesg.94-10-06)
3. The IESG approved or recommended the following five Protocol
Actions during the month of October, 1994:
o AppleTalk Management Information Base II for publication as
a Proposed Standard.
o IEEE 802.5 MIB for publication as a Draft Standard.
o Introducing Project Long Bud: Internet Pilot Project for the
Deployment of X.500 Directory Information in Support of X.400
Routing be published as an Informational RFC.
o Requirements for Internet gateways has been reclassified as
Historic.
o BGP4/IDRP for IP---OSPF Interaction is a Proposed Standard.
4. The IESG issued three Last Calls to the IETF during the month
of October, 1994:
o Connection-less Lightweight Directory Access Protocol
<draft-ietf-osids-cldap-01> for consideration as a Proposed
Standard.
o The Recommendation for the IP Next Generation Protocol
<draft-ipng-recommendation-01> for consideration as a
Proposed Standard.
o Definitions of Managed Objects for SNA Data Link Control:
SDLC <draft-ietf-snadlc-sdlc-mib-05> for consideration as a
Cooper [Page 4]
Internet Monthly Report October 1994
Proposed Standard.
5. Four Working Groups were created or reactivated during this
period:
SNMP Version 2 (snmpv2)
Authenticated Firewall Traversal (aft)
TFTP Extensions (tftpexts)
Responsible Use of the Network (run)
Additionally, one Working Groups was concluded:
Minimal OSI Upper-Layers (thinosi)
6. A total of 45 Internet-Draft actions were taken during the month
of October, 1994:
(Revised draft (o), New Draft (+))
(idr) o BGP4/IDRP for IP---OSPF Interaction
<draft-ietf-idr-bgp4ospf-interact-08.txt>
(none) o IP and ARP on Fibre Channel (FC)
<draft-rekhter-fibre-channel-04.txt>
(none) o Randomness Requirements for Security
<draft-ietf-security-randomness-02.txt>
(uri) o Uniform Resource Locators (URL)
<draft-ietf-uri-url-08.txt>
(snadlc) o Definitions of Managed Objects for SNA Data Link
Control: SDLC <draft-ietf-snadlc-sdlc-mib-05.txt>
(none) o Simple Object Look-up protocol (SOLO)
<draft-huitema-solo-01.txt>
(rmonmib) o Remote Network Monitoring Management Information
Base <draft-ietf-rmonmib-rmonmib-03.txt>
(imap) o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
<draft-ietf-imap-imap4-06.txt>
(none) o IMSP -- Internet Message Support Protocol
<draft-myers-imap-imsp-01.txt>
(uri) o Functional Requirements for Uniform Resource Names
<draft-ietf-uri-urn-req-01.txt>
(none) o MIME/ESMTP Profile for Voice Messaging
<draft-vaudreuil-umig-mime-voice-01.txt>
(cat) o The Simple Public-Key GSS-API Mechanism (SPKM)
<draft-ietf-cat-spkmgss-01.txt>
(ifmib) o IEEE 802.5 MIB
<draft-ietf-ifmib-tokenringmib-01.txt>
(snanau) o Definitions of Managed Objects for APPC
<draft-ietf-snanau-appcmib-01.txt>
(ospf) o OSPF MD5 Authentication <draft-ietf-ospf-md5-02.txt>
Cooper [Page 5]
Internet Monthly Report October 1994
(none) o An Architecture for IPv6 Unicast Address Allocation
<draft-rekhter-ipng-arch-IPv6-addr-01.txt>
(none) o A Convention for Human-Readable 128-bit Keys
<draft-mcdonald-readable-keys-01.txt>
(uri) o Relative Uniform Resource Locators
<draft-ietf-uri-relative-url-01.txt>
(none) o IP Multicast over UNI 3.0 based ATM Networks.
<draft-armitage-ipatm-ipmc-01.txt>
(tftpexts) o TFTP Option Extension
<draft-ietf-tftpexts-option-ext-01.txt>
(ifmib) o IEEE 802.5 Station Source Routing MIB
<draft-ietf-ifmib-ssr-mib-01.txt>
(tftpexts) o TFTP Blocksize Option
<draft-ietf-tftpexts-blksize-opt-01.txt>
(none) o The Recommendation for the IP Next Generation
Protocol <draft-ipng-recommendation-01.txt>
(none) + IPv6 Neighbor Discovery -- Processing
<draft-simpson-ipv6-discov-process-00.txt>
(none) + DNS Extensions to support IP version 6
<draft-thomson-ipng-dns-00.txt>
(none) + IP Next Generation Addressing Architecture
<draft-hinden-ipng-addr-00.txt>
(none) + ICMP and IGMP for the Internet Protocol Version 6
(IPv6) <draft-conta-ipv6-icmp-igmp-00.txt>
(none) + IPv6 Program Interfaces for BSD Systems
<draft-gilligan-ipv6-bsd-api-00.txt>
(none) + IP Next Generation Overview
<draft-hinden-ipng-overview-00.txt>
(none) + Simple Internet Transition Overview
<draft-gilligan-ipv6-sit-overview-00.txt>
(st2) + Internet Stream Protocol Version 2 (ST2) Protocol
Specification - Version ST2Plus
<draft-ietf-st2-spec-00.txt, .ps>
(none) + Internet Perceptions <draft-carpenter-percep-00.txt>
(isn) + Ways to Define User Expectations
<draft-ietf-isn-expectations-00.txt>
(none) + Connection Oriented and Connectionless IP Forwarding
Over ATM Networks
<draft-esaki-co-cl-ip-forw-atm-00.txt>
(sdr) + Explicit Routing Protocol (ERP) for IPv6
<draft-ietf-sdr-erp-00.txt>
(asid) + Schema Publishing in X.500 Directory
<draft-ietf-asid-schema-00.txt>
(none) + Internet Protocol, Version 6 (IPv6) Specification
<draft-hinden-ipng-ipv6-spec-00.txt>
(none) + Discussion paper for nosi BOF
<draft-carpenter-ipng-nosi-00.txt>
(none) + ISO Transport Service over TCP RFC1006 extension
Cooper [Page 6]
Internet Monthly Report October 1994
<draft-pouffary-tcp-00.txt>
(opstat) + The Opstat Client-Server Model for Statistics
Retrieval <draft-ietf-opstat-client-server-00.txt>
(ipsec) + Simple Key-Management For Internet Protocols (SKIP)
<draft-ietf-ipsec-aziz-skip-00.txt>
(aft) + SOCKS Protocol Version 5
<draft-ietf-aft-socks-protocol-v5-00.txt>
(none) + Scalable Multicast Key Distribution
<draft-ballardie-mkd-00.txt, .ps>
(trainmat) + Catalogue of Network Training Materials
<draft-ietf-trainmat-catalogue-00.txt>
(none) + OSI NSAP usage in IP6
<draft-houldsworth-ip6-nsap-use-00.txt>
7. There were 12 RFC's published during the month of October, 1994:
RFC St WG Title
------- -- -------- -------------------------------------
RFC1698 I (thinosi) Octet Sequences for Upper-Layer OSI to
Support Basic Communications Applications
RFC1700 S (none) ASSIGNED NUMBERS
RFC1701 I (none) Generic Routing Encapsulation (GRE)
RFC1702 I (none) Generic Routing Encapsulation over IPv4
networks
RFC1703 I (none) Principles of Operation for the TPC.INT
Subdomain: Radio Paging -- Technical
Procedures
RFC1704 I (none) On Internet Authentication
RFC1705 I (none) Six Virtual Inches to the Left: The
Problem with IPng
RFC1706 I (none) DNS NSAP Resource Records
RFC1707 I (none) CATNIP: Common Architecture for the
Internet
RFC1708 I (none) NTP PICS PROFORMA For the Network Time
Protocol Version 3
RFC1710 I (sipp) Simple Internet Protocol Plus White Paper
RFC1711 I (none) Classifications in E-mail Routing
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( E) Experimental
( I) Informational
Steve Coya (scoya at nri.reston.va.us)
Cooper [Page 7]
Internet Monthly Report October 1994
INTERNET PROJECTS
-----------------
ANSNET/NSFNET BACKBONE ENGINEERING
----------------------------------
Network Status Summary
=======================
ANSnet total packet traffic increased by about 14% in October '94.
An increase in the ANSnet forwarding table size of 0.58% was
observed during the month of October.
August Backbone Traffic Statistics
==================================
The total inbound packet count for the ANSnet (measured using SNMP
interface counters) was 85,499,744,741 on T3 ENSS interfaces, up
15.82% from September. The total packet count into the network
including all ENSS serial interfaces was 96,279,824,426 up 14.30%
from September.
Router Forwarding Table Statistics
==================================
The maximum number of destinations announced to ANSnet during
October was 18,886 up .58% from September.
The number of network destinations configured for announcement to
the ANSnet but never announced (silent nets) during October was
19,877.
BGP-4/CIDR Deployment Status
============================
As of November 4th '94, we have observed the withdrawal of 9,261
class based destinations from the ANSnet router forwarding tables
that are now represented by 2,014 configured aggregates. Among
these configured aggregates:
1,651 of these are top-level aggregates (not nested in
another aggregate).
1,270 of these are actively announced to ANSnet.
990 of these have at least one subnet configured (the
Cooper [Page 8]
Internet Monthly Report October 1994
other 280 may be saving the Internet future subnet
announcements).
906 of these have resulted in the withdrawal of at
least one configured more specific route.
894 of these have resulted in the withdrawal of 50%
of their configured more specific routes.
837 of these have resulted in the withdrawal of most
(80%+) of their more specific routes.
For up-to-date information is available from merit.edu:
pub/nsfnet/cidr/cidr_savings.
For further details on these CIDR aggregates, see
merit.edu:pub/nsfnet/cidr/nestings.announced for full listings.
Routing Stability Measured on the T3 Network
============================================
Internal routing stability measurements are made by monitoring
short term disconnect times (disconnects of five minutes duration
or less). This is intended as a measure of overall system
stability rather than complete connectivity.
If all nodes are considered, October 1994 had the most instability
ever recorded on ANSNET. This is due to the criteria of
considering stability to be the amount of time that 100% of ANSNET
is not undergoing routing change and due mostly to a persistant
problem with a single T1 circuit. There were other problems, most
notably an FDDI problem at the Hayward POP. If the one node
affected is excluded, October was approximately as stable as
September.
The problem circuit was an Ameritec leg of a T1 tail circuit
provisioned through MCI which turned out to be a bad smartjack at
the customer premise. This caused a very high level of packet
loss.
MONTH overall excluding configs
-------- -------- ------------------
January 99.1% 99.5%
February 99.0% 99.5%
March 97.5% 99.1%
April 96.1% 97.2%
May 97.4% 98.0%
Cooper [Page 9]
Internet Monthly Report October 1994
June 95.5% 96.6%
July 97.3% 97.7%
August 97.5% 97.9%
September 98.1% 98.5%
October 98.0% 98.3%
November 97.2% 97.9%
December 96.6% 96.8%
January 98.7% 99.0%
February 96.6% 97.6%
...
June 99.5% 99.7%
July 98.7% 99.5%
August 99.7% 99.7%
September 99.4% 99.5%
October 99.5% ** 99.6%
** - excluding one T1 ENSS
Monthly histograms of the number of nodes experiencing instability
follows. ENSS212 had 107 hours of instability (4.9 days). If this
node is excluded from the data, very little instability in the
other nodes was evident. Large packet bursts coupled with
transient link outages induced some congestion problems as link
utilizations grew to 60%+ on T3 links at the NY, DC, Chicago and
Cleveland POPs. These problems have been corrected by deploying
new router adapter code that more efficiently allocates packet
buffering memory. CNSS32 had 36 minutes of routing instability due
to the congestion problems.
MONTH >5 hr >2 hr > 1hr >30 min >15 min <= 15min
<98.7% <99.7% <99.87% <99.93% <99.97% >=99.97%
----------------------------------------------------------------
January 0 0 1 8 19 55
February 0 0 1 24 19 41
March 0 4 18 23 23 22
April 2 2 3 13 12 57
May 0 4 33 32 15 5
June 3 21 35 18 12 3
July 0 12 28 44 6 1
August 1 5 28 21 17 15
September 1 38 25 10 4 13
October 0 3 3 10 25 50
November 1 2 15 25 24 26
December 0 8 24 46 9 3
January 0 0 4 9 15 54
February 0 4 6 23 40 20
...
June 0 0 0 5 5 67
Cooper [Page 10]
Internet Monthly Report October 1994
July 0 7 55 11 10 7
August 0 0 0 0 0 67
September 0 0 0 1 14 57
October 0 0 0 1 3 61 **
** - excluding one T1 ENSS
External route flap reports are described in:
ftp.ans.net:/pub/info/routing-stats/daily-reports/README
Notable Outages in October '94
==============================
E134 (Boston) suffered an extended outage due to power problems on
10/03
E144 (FIXWEST) suffered an extended outage due to router crash on
10/19
E128 (Palo Alto) was unreachable via T3 due to router crash on
10/19
E141 (Boulder) and E142 (Salt Lake City) were unreachable via T3
due to scheduled maintenance on 10/26
Jordan Becker <becker at ans.net>
BOLT BERANEK AND NEWMAN INC.
----------------------------
Scalability
This month, in preparation for analysis of DIS traffic
characteristics during the STOW-Europe exercises, BBN investigated
the issue of post-processing time synchronization among
participating sites. Sychronization of host clocks in distributed
simulation affords two major benefits:
1 - Application PDUs are being logged in a distributed manner by
deploying a logging host at each site. No single repository of all
PDUs generated during the exercise will exist. Therefore, in order
to enable an accurately sequenced after-action review, we will need
to have a way to ensure consistency among time stamps on the
separately logged PDUs.
2 - Time synchronization among hosts exchanging data during the
exercise will provide us with measurements of one-way end-to-end
delay. These measurements will give us a baseline of DSI
Cooper [Page 11]
Internet Monthly Report October 1994
performance against which to measure improvement afforded by future
communications architectures, and they will enable us to calibrate
network simulators used to predict performance of the DSI in the
presence of distributed simulation traffic.
We are investigating the applicability of tools developed by Greg
Troxel (BBN) as part of his Ph.D. work at MIT. These tools enable
us to correct for clock differences after the fact, even, to some
extent, when no attempt at real-time synchronization (for example,
running NTP) was being made. If NTP is used during the exercise,
Greg's tools will be even more effective at correcting for
inaccuracies that might have resulted from asymmetric delays. Greg
has been refining and testing his programs and analysis techniques
during September and October, and next month we expect to be
applying them to STOW-E data.
Flow Synchronization Protocol
Over the past two months we prepared for and presented a
demonstration of flow synchronization across the Internet. The two
main issues we tackled were porting the synchronization code to
new, more powerful platforms (Sparc 10s and SS 20's) and
interoperability between video flows and music flows for
synchronization. We added to our software a Graphical User
Interfaces and other tools to facilitate use and development.
Regarding video and music interoperability, previous tests
addressed only the synchronization of video streams with voice
streams. Since synchronizing multiple music streams has special
requirements in the ways it adapts delays, it became necessary to
create a version of the video software tailored to the music
requirements.
On October 20th, 1994, we became the first research group to
demonstrate topology-independent tight synchronization of
multimedia flows over wide area networks using the Internet and
geographically dispersed sites across the continental US.
The public demonstration, at the ACM Multimedia 94 Conference, San
Francisco, consisted of synchronizing three music audio flows and a
video flow from sites in Boston and San Francisco playing a Hayden
piano Trio in G major. The set up served to demonstrate audio-
video synchronization and tight audio-audio synchronization among
the flows from the players. The audience on site and through the
Mbone was shown the contrast between unsynchronized and
synchronized flows.
The live players were Martha Steenstrup (BBN) in Boston and Eve
Cooper [Page 12]
Internet Monthly Report October 1994
Schooler (Cal Tech, formerly at ISI) in San Francisco. We used a
piano recording to act as a "conductor" or metronome. Its sound
was delivered at the same time to both players, who played along on
keyboards the parts of the other two instruments (cello, violin).
The piano recording was also delivered to a repeater site. All
three music flows plus motion video from Martha Steenstrup in
Boston were sent and played out synchronized at the demo room in
San Francisco.
The synchronization protocol used for this demonstration was
developed with ARPA funding. It made use of the Network Time
Protocol to obtain clock synchronization, and it used Nevot for
audio flows and PVP to NV for the video flow. Synchronization to
within a few tens of milliseconds or better is necessary for music
synchronization in this demo.
We also demonstrated a Graphics User Interface for the protocol
use, built as an extension of the Nevot Graphics User Interface.
During regular operation, it simply calls for a button to set or
unset synchronization. For experimentation and testing, it allows
protocol parameters to be set and protocol delays to be displayed
and tracked.
Joshua P Seeger <jseeger at BBN.COM>
CSUNET
------
In order to provide regional connectivity for the Pacific Internet
Consortium (CSUnet, Los Nettos, WestREN) for southern California,
CSUnet and Los Nettos requested MCInet networking services be
ordered by WestREN/BARRnet. The northern California portion is
already in place and undergoing testing.
MCInet expects to provide the southern California connectivity at
the end of November. CSUnet and Los Nettos will begin testing and
expect to cutover production traffic to the new connection as soon
as it is stable.
Mike Marcinkevicz
CSUnet Engineering (mdm at csu.net)
Cooper [Page 13]
Internet Monthly Report October 1994
INTERNIC
--------
INFORMATION SERVICES
Contact Information:
Reference Desk Information
Phone +1 619 455-4600
email info at internic.net
Fax +1 619 455-4640
InterNIC Suggestions or Complaints
Suggestions suggestions at internic.net
Complaints complaints at internic.net
NSF Network News
newsletter subscriptions newsletter-request at internic.net
newsletter comments newsletter-comments at internic.net
NICLink
General Information info at internic.net
Problems/bugs niclink-bugs at is.internic.net
InterNIC Seminar Series
General Information seminars at internic.net
Listserv lists
net-happenings majordomo at is.internic.net
net-resources majordomo at is.internic.net
scout-report majordomo at is.internic.net
InfoGuide
Host Name is.internic.net
Host Address 192.153.156.15
URL: http://www.internic.net/
Postal address
InterNIC Information Services
General Atomics
P.O. BOX 85608
San Diego, CA 92186-9784
THE InterNIC INFOGUIDE
The InterNIC InfoGuide is a comprehensive online information
service which provides information about the Internet and online
Internet resources. Accessible through gopher and the WorldWideWeb,
Cooper [Page 14]
Internet Monthly Report October 1994
the InterNIC InfoGuide replaces the older InterNIC information
server, the InfoSource. The InfoGuide includes new services such as
the Scout Report and an online hypertext version of the _NSF
Network News_.
To access the InterNIC InfoGuide, point your WorldWideWeb client
to:
http://www.internic.net/infoguide.html
or your gopher client to:
is.internic.net
NET-HAPPENINGS
The net-happenings list is a service of InterNIC Information
Services and the list moderator, Gleason Sackman of North Dakota's
SENDIT Network. The purpose of the list is to distribute to the
community announcements of interest to network staffers and end
users. This includes conference announcements, call for papers,
publications, newsletters, network tools updates, and network
resources. Net-happenings is a moderated, announcements-only
mailing list which gathers announcements from many Internet sources
and concentrates them onto one list.
To access net-happenings, point your gopher client to:
is.internic.net
and search the InterNIC InfoGuide for Net-Happenings.
THE SCOUT REPORT:
A Weekly Summary of Internet Highlights
Presently the Scout Report is now reaching over 14,000 subscribers
and the HTML versions on the InfoGuide are receiving thousands of
accesses each week. A new mailing list was created for easier
distribution of the HTML Scout Report, which is located at scout-
report-html.
The Scout Report is a weekly publication offered to the Internet
community as a fast, convenient way to stay informed on network
activities. Its purpose is to combine in one place the highlights
of new resource announcements and other news which occurred on the
Internet during the previous week.
Cooper [Page 15]
Internet Monthly Report October 1994
The Scout Report is released every Friday in multiple formats --
electronic mail, gopher, and WorldWideWeb. WorldWideWeb versions
of the Report include links to all listed resources allowing
instantaneous browsing of items of interest. Comments and
contributions to the Scout Report are encouraged and can be sent to
scout at internic.net.
How to Get the Scout Report
To receive the electronic mail version of the Scout Report each
Friday, join the scout-report mailing list. This mailing list will
be used only to distribute the Scout Report once a week. Send mail
to: majordomo at is.internic.net
In the body of the message, type:
subscribe scout-report youremailaddress
To access the hypertext version of the Report, point your WWW
client to: http://www.internic.net/infoguide.html
nnGopher users can tunnel to: is.internic.net/Information Services
THE InterNIC SEMINAR SERIES
"Learning the Whole Internet" is now available for users needing
Internet training. The InterNIC has already presented a beta
version of the course which includeded a copy of _The Whole
Internet_ as well as class handouts of the PowerPoint presentation.
NSF NETWORK NEWS
The _NSF Network News_ Vol. 1, No. 4 (September/October 1994) is
scheduled for publication within the next two weeks. The
newsletter will spotlight K-12 resources on the Internet.
Highlights will include: how to evaluate Internet resources;
examples of cyber-field trips; lesson plans found on the Internet;
a seminar spotlight; and the regular features of the _NSF Network
News_ such as the InterNIC Event Calendar and updates from InterNIC
partners. To subscribe, send email to newsletter-
request at internic.net.
The July/August issue of the _NSF Network News_ is available on the
WorldWideWeb at
http://www.internic.net/newsletter/jul-aug94/index.html
The newsletter is also available via gopher to the InterNIC
Cooper [Page 16]
Internet Monthly Report October 1994
InfoGuide at is.internic.net and mailserv to
mailserv at is.internic.net with the following text in the body of the
message:
get /about-internic/newsletter/nsfnews-aug94.txt
REFERENCE DESK
The following table gives a summary of Reference Desk contacts for
October:
Method Contacts % of Total
------- -------- ---------
Email 267 46
Phone 388 31
Fax 181 21
US Mail 14 2
Referral 2 <1
------- -------- ---------
Total 852 100.0
by Anna Knittle <aknittle at is.internic.net>
INTERNIC DIRECTORY AND DATABASE SERVICES
AIDS Patent Database
In October, CNIDR (Clearinghouse for Networked Information
Discovery and Retrieval), the US Patent and Trademark Office, and
Directory and Database Services made available a collection of
AIDS-related patents on World Wide Web. The patents are searchable
in free text or boolean queries, and the collection can also be
browsed (but be warned - it is a large collection). The US Patent
Classifications can also be browsed. All the figures and diagrams
associated with the patents are available. On our server
(ds0.internic.net), the patent database is available under
"InterNIC Database Services (Public Databases)".
Printed Copies of the Directory of Directories
Directory and Database Services maintains a Directory of
Directories which is available on-line through WAIS, Gopher, World
Wide Web, FTP, telnet, and via electronic mail request. Over time,
we have had a number of requests for a printed version in addition
to the on-line versions, and a printed version is now available.
Cooper [Page 17]
Internet Monthly Report October 1994
To order a printed copy of the Directory of Directories, call 800-
432-6600. The order number is 451-206, and the price is $43.20.
The current version is 806 pages long. We will make a new printed
version available every 6 months. There will be no automatic
updates.
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories.
by Rick Huber <rvh at ds.internic.net>
REGISTRATION SERVICES
Progress Report for period October 1, 1994 through October 31, 1994
I. Significant Events
InterNIC Registration Services assigned over 8,173 network
addresses and registered over 2,747 domains. One top-level country
domain was unregistered during the month; Czechoslovakia.
II. Current Status
During the month of October 1994, InterNIC Registration Services
received communications as shown below. The majority of the
correspondence concerned the assignment and re-assignment of
network numbers and the registration or change of domain names.
E-mail 7,614 (hostmaster at internic.net)
Postal/Fax 301 (primarily IP number requests)
Phone 2,631
The Registrations Services host computer supported a large volume
of information retrieval requests during the month of October.
Connections Retrievals
Gopher 71,916 41,648
WAIS 67,957 67,160
FTP 11,487 53,027
Mailserv 3,326
Cooper [Page 18]
Internet Monthly Report October 1994
In addition, for WHOIS the number of queries were:
Client Server
267,730 1,140,537
Debbie Fuller <debbief at internic.net>
ISI
---
NETSTATION
==========
Performance Testing of TCP/IP Protocol Suite
--------------------------------------------
We have compared some experimental implementations of optimized
TCP/IP in the ATOMIC LAN environment. Here we present the results
of a fast-TCP compared to "as-shipped" TCP. We compared the
transmission of 4,096 byte packets (with 40-byte headers) between
two SPARC2 workstations, using an optimized TCP and TCP as-shipped,
with IP checksumming both enabled and disabled. In addition we
measured the performance of loopback taking place at various levels
in the protocol stack using both SPARC20 and SPARC10 workstations.
For these comparisons we used Myricom's implementation of the
ATOMIC host interfaces. There were two versions of the interface
available: the first supported only programmed I/O, and the second
had integrated DMA and hardware IP checksum. The performance
measures for the former were performed at ISI, and the latter were
performed at ISI by Myricom.
We measured different kernel buffer size areas over host-host,
loopback at the Mosaic interface, and loopback above the Atomic
driver, at the IP level in the kernel.
TCP between two hosts runs at 25 Mbps on a Sparc-2, regardless of
whether the optimized implementation or as-shipped was used.
Turning off the IP checksum increased the rate to 29 Mbps.
Mosaic loopback performed less well, because a single host was
involved in both the send and receive functions. We expected the
useful bandwidth would drop to half the host-host rates, and this
was verified.
We performed a kernel loopback, to measure the protocol processing
overhead independent of the cost of the data movement. We expected
the as-shipped TCP to become approximately five times faster (100
Cooper [Page 19]
Internet Monthly Report October 1994
instructions per TCP header + 1000 instructions per context switch
+ 4000 instructions for programmed I/O = 5100 instructions, which
drops to 1100 without the data movement). We also expected this to
be an upper-bound on the speed of the protocol in DMA-mode, which
newer ATOMIC boards from Myricom support.
We found that the as-shipped TCP increased to 24 Mbps (30 without
checksum). This is only a factor of two increase, back to values
seen for host-host transfers. The optimized TCP was more sensitive
to kernel buffer sizes, ranging 35-55 Mbps (50-100 without
checksum). The non-checksum case is a fair measure of the
bandwidth, because checksumming can occur in parallel with data
movement at low cost. The optimized non-checksum TCP was increased
by a factor of four, which is within our estimate.
The kernel loopback of the as-shipped TCP on the Sparc-10 was
nearly as effective as the optimized TCP on the Sparc-2. We
measured 45-50 Mbps (50-70 without checksum).
In conjunction with Myricom, we measured the performance of the
Sparc-2 TCP versions on a DMA-capable ATOMIC interface. We
expected to see performance near the kernel loopback values,
because the DMA transfers can be overlapped with other operations.
We found the as-shipped TCP host-host bandwidth was 40 Mbps (45
with checksumming in hardware, which is nearly equivalent to
"checksumming off"). The optimized TCP achieved 45 Mbps (70 with
hardware checksumming). These results verified our predictions.
We conclude that some of the optimizations we tested are useful,
but did not fully utilize the board capabilities of 440 Mbps
through the DMA channel. We believe that there is a potential for
a 2- to 3-fold increase by hardware modifications, but that the
preponderance of speedup potential is in the operating system.
Annette Deschon <deschon at isi.edu>
ATOMIC-2
--------
The ATOMIC-2 project extends the results of the ATOMIC, which
developed a LAN from supercomputer chips. ATOMIC-2 was originally
charged with augmenting the ATOMIC LAN lab prototypes into a
production office environment, replacing the Ethernet LAN in the
entire HPCC Division of ISI, and developing a number of host
interfaces. Myricom was formed to commercialize the ATOMIC LAN, and
so the ATOMIC-2 project has been redirected to address LAN
interconnection over WAN ranges, integrated service issues, and
network peripherals. All subsequent ATOMIC-2 work will be link-
Cooper [Page 20]
Internet Monthly Report October 1994
compatible with Myricom's Myrinet.
We are currently developing an ATOMIC-ATM IP-level gateway. We are
also developing an ATOMIC network disk server. We are continuing
efforts to deliver a significant portion of ATOMIC's 640 Mbps
network bandwidth to the user application, subject to host
backplane limitations.
We are serving as an alpha test-site for Myricom's production
software.
Joe Touch <touch at isi.edu>, Annette DeSchon <deschon>
Hong Xu <xu at isi.edu>, Ted Faber <faber at isi.edu>
PC-ATOMIC
---------
Design of 486-based VL-Bus ATOMIC interface.
We completed the PC-ATOMIC prototype card, a i486 VL-Bus (VESA)
interface supporting channel-level compatibility with the Myrinet
LAN. The card supports programmed I/O reads at 88 Mbps and writes
at 144 Mbps. It also supports DMA, currently under testing. The
board has hardware support for IP checksums during either DMA or
programmed I/O. The checksum is performed during reads or writes,
with zero overhead, and can be enabled via a control register bit.
The communications interface has been tested, and found to have
zero errors over 10 million packets in, on-board pre-driver
loopback, on-board post-driver loopback, i486-i486, and i486 to
MyriCom S-Bus interface. All tests involved zero errors over 10
million packets.
A limited number of these boards will be available shortly in small
quantities.
In addition, we have performed some experiments regarding the
programmed-I/O bandwidth capabilities of the PC-ATOMIC boards,
including a comparison to Myricom's 2.x SPARC S-Bus interface
cards.
Graphs show read (from host to board) and write (from board to
host) programmed I/O bandwidth. Note that the READ bandwidth is
more critical because it is the bottleneck in programmed I/O mode.
Cooper [Page 21]
Internet Monthly Report October 1994
LEGEND:
ISI's PC-Atomic = ***
Myricom's SPARC SBus v2.x = ###
Bandwidth (Mbps) READ Bandwidth
100 ++--+----+--++---+----+--++---+-----+-+-+---+----+--++---+----+--++
+ + + + + +
| ******* |
80 ++ **** ++
| **************########### |
| ******** |
60 ++ #**** ++
| #** |
| #** |
| ##* |
40 ++ ##** ++
| ##** |
| ##** |
20 ++ ##** ++
| #** |
+ * + + + + +
0 ++--+----+--++---+----+--++---+-----+-+-+---+----+--++---+----+--++
1 10 100 1K 10K 100K
Packet size (bytes)
Bandwidth (Mbps) WRITE Bandwidth
200 ++--+----+--++---+----+--++---+-----+-+-+---+----+--++---+----+--++
+ + + + + +
| ####################### |
| #### |
150 ++ ### ********************* ++
| ###***** * |
| ##*** **** |
| ##** |
100 ++ #*** ++
| #** |
| ** |
| ** |
50 ++ ** ++
| *** |
| ** |
+ ** + + + + +
0 ++--+----+--++---+----+--++---+-----+-+-+---+----+--++---+----+--++
1 10 100 1K 10K 100K
Packet size (bytes)
Cooper [Page 22]
Internet Monthly Report October 1994
All graphs have been computed with 90% confidence intervals which
are near +/- 2 Mhz for each data point. The i486 PC-ATOMIC system
performance degrades at 8K byte packets, due to crossing page
boundaries. These performance numbers are for programmed I/O only;
DMA numbers will be higher.
Joe Touch <touch at isi.edu>, Annette DeSchon <deschon>
Hong Xu <xu at isi.edu>, Ted Faber <faber at isi.edu>
Jeff LaCoss <lacoss at isi.edu, Mike Gorman <mgorman at isi.edu>
RSVP PROJECT
============
RSVP (ReserVation Protocol) and traffic control, as well as the
MBONE, were demonstrated at the ACM Multimedia '94 Conference in
San Francisco. This demo was accomplished by a collaboration of
researchers at ISI, MIT, PARC, UDEL, and LBL. A number of vendors
provided equipment in support of this demo: Sun, HP, DEC, and SGI
provided workstations, and Fore provided ATM switches. PAC Bell
provided the DS3 line from the hotel to a BAGNET switch in an
Oakland central office, and BAGNET provided a dedicated PVC from
there to Palo Alto.
The demo used an unloaded DS3 link (using ATM, as described later)
between the conference network and a DARTnet router (Sparc) at
PARC. RSVP and traffic control were running in DARTnet. DARTnet
was flooded with background traffic, causing speech carried by VAT
to be broken up in the absence of RSVP reservations, but clear with
RSVP reservations in place.
The DARTnet routers were running a SunOS kernel that included a
packet scheduler implementing a simple subset of the CSZ service
model. Specifically, it implemented two levels of Predictive
service, essentially two priority levels. The routers also ran the
ISI implementation of RSVP, which was invoked through modified VAT
modules.
Cooper [Page 23]
Internet Monthly Report October 1994
Here is a simplified picture, to illustrate the demo schenario:
---------------- DARTnet -------------------
Xerox T1
<------ PARC --------> |
|
_____ __|__|_
| | | | |
SF Hotel |--| PARC|----X----| AMES |----- Y -->
MM '94 | |_____| |_______| To rest
_____ ______ | | of DARTnet
| | | PARC | | |
| mm94|-.-.-.-.-.-.| THa |--| |
|_____| |______| | T2
|
______ |
| PARC | |
| THb |--|
|______| |
|
All the boxes shown are Sparcstations.
mm94: represents demo computer in demo room of SF hotel
-.-.-. : represents link between hotel and PARC
An HP workstation connected the show Ethernet to a
Fore Switch in the hotel. The Fore switch drove a DS3
line to a BAGNET switch in Oakland. The little cells
then traversed BAGNET to Palo Alto, where they crossed
a short hop to a BADLAN switch within PARC. The
BADLAN switch was then connected to an ATM card in the
DARTnet test host THa. This provided an unloaded,
high speed path from DARTnet to the show Ethernet.
The intermediate switches did not run RSVP or traffic
control and were effectively transparent to the demo.
PARC THa, PARC THb: Test hosts on test Ethernet at PARC.
PARC THa ran RSVP (but not traffic control, as it happens).
PARC THb served only as a sink for flooding traffic from
traffic generators T1 and T2.
PARC: DARTnet router at PARC.
Cooper [Page 24]
Internet Monthly Report October 1994
AMES: DARTnet router at NASA Ames.
Traffic generators T1 and T2 at other DARTnet sites not
shown each sent about 800Kb/s of UDP junk traffic to
sink at PARC THb. The result was to saturate the link
marked X towards MM 94; measurement tools showed link X
loaded very close to its full capacity of 1.344Mbps.
The link marked Y leads to the rest of DARTnet, including ISI and
MIT, which were multicasting VAT audio traffic towards MM 94. This
traffic collided with the background traffic from T1 and T2 in the
AMES router, in the output driver for link X. Basically the packet
scheduling kernel established two output queues, one for reserved
traffic and one for the rest.
The mm94 machine was running a version of VAT that not only invoked
RSVP, but also had a "big button" that could disable or enable RSVP
for the demo. With RSVP invoked, Resv messages were traveling from
mm94 upstream through DARTnet towards all the senders that were
sending Path messages downstream (in this case, MIT and ISI). This
caused the packet scheduler in the AMES router to give the VAT
stream higher priority than the background traffic.
In addition to the VAT reservation, there was a (small) reservation
established for RSVP traffic, so that Path and Resv messages also
used the high-priority queue. This demo made extensive use of the
automatic tunneling capability of RSVP.
Jim Berson <berson at isi.edu>, Bob Braden <braden at isi.edu>,
Steve Casner <casner at isi.edu>
INFRASTRUCTURE
Paul Mockapetris attended IAB's IIA Workshop in Reston, Virginia,
and was keynote speaker at the Colorado Internet Meeting. Joyce
Reynolds, attended the IAB's IIA Workshop in Tysons Corner,
Virgina. Steve Berson, attended the ACM Multimedia Conference in
San Francisco, California.
12 RFCS WERE PUBLISHED THIS MONTH.
1698 Octet Sequences for Upper-Layer OSI to Support Basic
Communications Applications. P. Furniss. October 1994.
1700 ASSIGNED NUMBERS. J. Reynolds,J. Postel. October 1994.
(Obsoletes RFC1340) (Also STD0002)
Cooper [Page 25]
Internet Monthly Report October 1994
1701 Generic Routing Encapsulation (GRE). S. Hanks, T. Li, D.
Farinacci, P. Traina. October 1994.
1702 Generic Routing Encapsulation over IPv4 networks.
S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994.
1703 Principles of Operation for the TPC.INT Subdomain:
Radio Paging -- Technical Procedures. M. Rose.
October 1994. (Obsoletes RFC1569)
1704 On Internet Authentication. N. Haller & R. Atkinson.
October 1994.
1705 Six Virtual Inches to the Left: The Problem with IPng.
R. Carlson & D. Ficarella. October 1994.
1706 DNS NSAP Resource Records. B. Manning & R. Colella.
October 1994, (Obsoletes RFC1637)
1707 CATNIP: Common Architecture for the Internet.
M. McGovern & R. Ullmann. October 1994.
1708 NTP PICS PROFORMA - For the Network Time Protocol
Version 3. D., Gowin. October 1994.
1710 Simple Internet Protocol Plus White Paper. R. Hinden.
October 1994.
1711 Classifications in E-mail Routing. J. Houttuin.
October 1994.
THE US DOMAIN
=============
THE US DOMAIN ADMINISTRATIVE INFORMATION
----------------------------------------
EMAIL/FAX 648
PHONE 95
----------------------------
Total Contacts 743
DELEGATIONS 94
DIRECT REGISTRATIONS: 29
OTHER US DOMAIN MSGS: 620
---------------------------
Total 743
Cooper [Page 26]
Internet Monthly Report October 1994
OTHER US DOMAIN MESSAGES INCLUDE: modifications, application
requests, discussion and clarification of the requests, questions
about names, referrals to other subdomains or to/from the InterNic,
resolving technical problems with zone files and name servers, and
whois listings.
The list of delegations below does not reflect the entire number of
registrations and delegations in the whole US Domain. Many
subdomains have been delegated and administrators of those
subdomains register applicants in their domains. Below are direct
registrations in the US Domain.
To obtain a copy of the list of other delegated localities and
subdomains you can ftp the file in-notes/us-domain-delegated.txt
from venera.isi.edu, via anonymous ftp.
Third Level US Domain Delegations this month
--------------------------------------------
K12.HI.US Hawaii, K12 schools
K12.SD.US South Dakota K12 Schools
K12.WY.US Wyoming K12 Schools
TEC.SD.US South Dakota Technical Schools
TEC.MN.US Minnesota Technical Schools
CC.HI.US Hawaii, Community Colleges
CC.MN.US Minnesota Community College
CC.SD.US South Dakota Community Colleges
STATE.HI.US State of Hawaii, gov't agencies
LIB.HI.US Hawaii Libraries
LIB.SD.US South Dakota Technical Schools
MUS.TX.US Texas, Museums
GEN.TX.US Texas, general independent entities
FERC.FED.US Federal Energy Regulatory Commission
THETA-DELTA-CHI.DNI.US Theta-Delta-Chi Fraternity
COCONINO.AZ.US Coconino, AZ, locality
EDWARDS.CA.US Edwards, CA, locality
UKIAH.CA.US Ukiah, California, locality
AURURA.CO.US City of Aurora Colorado, gov't agencies
CONIFER.CO.US Conifer, CO, locality
THORTON.CO.US Thornton, Colorado, locality
TERRA.CO.US Terra, Colorado, locality
OAHU.HI.US Oahu, Hawaii, locality
MAUI.HI.US Maui, Hawaii, locality
KAUAI.HI.US Kauai, Hawaii, locality
LANAI.HI.US Lanai, Hawaii, locality
HAWAII.HI.US Hawaii, Hawaii, locality
MOLOKAI.HI.US Molokai, Hawaii, locality
HNL.HI.US Honolulu, Hawaii, locality
Cooper [Page 27]
Internet Monthly Report October 1994
BOISE.ID.US Boise, Idaho, locality
GLENVIEW.IL.US Glenview, Illinois, locality
NORTHBROOK.IL.US Village of Northrook, IL, locality
FAY.NC.US Fay, North Carolina, locality
STATE.NJ.US New Jersey State gov't agencies
POTSDAM.NY.US Potsdam, New York, locality
LEXINGTON.OH.US Lexington, Ohio, locality
STEUBENVILLE.OH.US Steubenville, Ohio, locality
STRONGSVILLE.OH.US Strongsville, Ohio, locality
TULSA.OK.US Tulsa, Oklahoma, locality
MOCITY.TX.US Missouri City, Texas, locality
Other US Domain Delegations this month
--------------------------------------
GSA.TUSCALOOSA.AL.US Geological Survey of Alabama
MAYBECK.BERKELEY.CA.US Maybeck High School in Berkeley
PAN.SF.CA.US Pan Inc, San francisco, CA
STOCKTON.LIB.CA.US Stockton-San Joaquin Country Library
SJVLS.LIB.CA.US San Joaquin Valley Library System
DRS.STATE.CT.US Department of Revenue Services
STRATFRDPL.LIB.CT.US Stratford Library Association
NORWALKPL.LIB.CT.US Norwalk Public Library
CTHISTSOC.LIB.CT.US Connecticut Historical Society Library
CTSTATELIB.LIB.CT.US Connecticut State Library
STAMFORDPL.LIB.CT.US Ferguson Lirary, Stamford, CT
SHELTONPL.LIB.CT.US Plumb Memorial Library
NBRANFRDPL.LIB.CT.US North Branfrd Public Library
NWCANAANPL.LIB.CT.US New Canaan Library
HARTFORDPL.LIB.CT.US Hartford Public Library
GROTONPL.LIB.CT.US Groton Public Library
WATERBURYPL.LIB.CT.US Silas Bronson Public Library
HEBRONPL.LIB.CT.US Douglas Library
COLUMBIAPL.LIB.CT.US Saxton B. Little Library
BRDGPRTPL.LIB.CT.US Bridgeport Public Library
ANDOVERPL.LIB.CT.US Andover Public Library
UNEWHANEN.LIB.CT.US University of New Haven Library
CCSU.LIB.CT.US Central Connecticut State. Univ.
MSPORTERSC.FARMINGTON.PVT.K12.CT.US Miss Porter School, CT
STMRGRETM.WATERBORU.PVT.K12.CT.US St. Margaget McTernam School
LISBONCENS.LISBON.K12.CT.US Lisbon Central School
EASTLYMEHS.EASTLYME.K12.CT.US East Lyme High School Library
FLANDERS.EASTLYME.K12.CT.US Flanders Elementary School Library
CONARDHS.W-HARTFORD.K12.CT.US Conard High School
AMERSCHDEL.W-HARTFORD.PVT.K12.CT.US American School of the Deaf
PLAINFLDHS.PLAINFIELD.K12.CT.US Plainfield High School
ALA.NE.DC.US American Library Association
YARCOMM.SF.CA.US Yar Communications, CA
Cooper [Page 28]
Internet Monthly Report October 1994
IAT.NORCROSS.GA.US Arena Electronics, Inc.
MILLEDGEVILLE.GA.US City of Milledgeville, GA
JOHNCO.CC.KS.US Johnson County Community College, KS
CCC.CC.KS.US Coffeyville Community College, KS
JOHNCO.CC.KS.US Johnson County Community College
ASTRO.LOU.KY.US AstroSphere Graphics Group
SHARON.LIB.MA.US Sharon Public Library
WALPOLE.LIB.MA.US Walpole Public Library
SLUG-ST-LOUIS.MO.US St. Louis Users Group for the PC
ICON.ST-LOUIS.MO.US St. Louis Internet Connection
HAVEN.BOSTON.MO.US Personal computer, MA
MUSIC.GEN.MT.US College Music Society, Missoula, MT
ROSE.CC.OK.US Rose State College, Oklahoma
DARKMATTER.NORMAN.OK.US Vapourspace Communications
FPLP.LIB.PA.US Free Public Library of Philiadelphia
ECTI.TEC.PA.US Erie County Technical Institute
LCLS.ERIE.LIB.PA.US Erie County Library System
AAPA.ALEXANDRIA.VA.US American Academy of Physician Assistants
PUB-LIB.CI.ARLINGTON.TX.US Arlington Public Library
NICHOLSON-PL.CI.GARLAND.TX.US Nicholson Memorial Library
SW-ENG.FALLS-CHURCH.VA.US Ada Inforamtion Clearinghouse
DELEGATED ZONES UNDER .US
K12 CC TEC STATE LIB MUS GEN
-----------------------------------------------------------
AK X
AL X
AR X X
AZ X X X X X
-----------------------------------------------------------
CA X X X
CO X X X X X X X
CT
DC X
-----------------------------------------------------------
DE X
FL X X X X X X X
GA X X X X
HI X X X X X X X
-----------------------------------------------------------
IA X X X X
ID X X X X X X X
IL X X X X X
IN X X X X X X X
Cooper [Page 29]
Internet Monthly Report October 1994
K12 CC TEC STATE LIB MUS GEN
-----------------------------------------------------------
KS X X
KY X X X X X X X
LA X X X X X
MA X X
-----------------------------------------------------------
MD X X X X
ME X X
MI X X X X X
MN X X X X X X X
-----------------------------------------------------------
MO X X X X X X
MS X X X X
MT X
NC X X X X X
-----------------------------------------------------------
ND X X X X X X X
NE X X X X
NH X X
NJ X X
-----------------------------------------------------------
NM X X X
NV
NY X X X X X X X
OH X X X X X X X
-----------------------------------------------------------
OK
OR X X X X X X X
PA X X
RI X X X
-----------------------------------------------------------
SC X X X X X X X
SD X X X X X X X
TN X
TX X X X X X X X
-----------------------------------------------------------
UT X X X X
VA X X X X
VI
VT X
-----------------------------------------------------------
WA X
WI X X X
WV X X X X X X X
WY X X
===========================================================
Cooper [Page 30]
Internet Monthly Report October 1994
For more information about the US Domain please request an
application via the RFC-INFO service. Send a message to RFC-
INFO at ISI.EDU with the contents "Help: us_domain_application". For
example:
To: RFC-INFO at ISI.EDU
Subject: US Domain Application
help: us_domain_application
Ann Westine Cooper (Cooper at ISI.EDU)
MERIT/NSFNET ENGINEERING
------------------------
This report summarizes recent activities of Merit's Internet
Engineering and Network Management groups with regard to the NSFNET
Backbone Service Project and the Routing Arbiter Project.
Bill Norton and Enke Chen continue implementation of the Network
Management System for the Routing Arbiter architecture. The
distributed architecture will support bilingual SNMP (V1/V2), out-
of-band access and router discovery algorithms. Laurent Joncheray
has ported PGP ('Pretty Good Privacy') 2.6 into the RIPE routing
registry software. PGP is a public key encryption method which
provides for authentication of the sender of a message and,
optionally, encryption of the message contents. PGP is being
evaluated by the RIPE team as one method for securing Routing
Registry databases.
Andy Adams and Rick Riolo of Merit, in collaboration with Cengiz
Alaettinoglu of ISI, have implemented a RIPE-181 policy language
analysis library that parses RIPE-181 policy syntax and makes
queries to the Routing Arbiter Database to produce output such as
AS lists and net lists. The output is suitable for all sorts of
configuration file formats, in addition to the Route Server's
configuration files.
The routines will also be very useful for policy analysis, both for
the Routing Arbiter's use and for others. For example, the code
can be used to normalize and compare policy expressions or minimize
policy expressions. The code could parse a complex policy in
RIPE-181 syntax and output an equivalent, more compact expression,
such as 'Accept ANY'. If this was not the intended meaning, the
developer could redo the policy to express the correct meaning.
Other network providers have shown interest in using this code, in
the form of libraries, to generate their own configuration files.
Cooper [Page 31]
Internet Monthly Report October 1994
Merit hosted the North America Network Operators Group (NANOG)
meeting on October 24th and 25th. The focus of the meeting was the
transition from an NSFNET-provided backbone service to an
architecture based on Network Access Points for multiple backbone
providers. Elise Gerich updated the group on the NSFNET transition
and on the migration from the Policy Routing Data Base (PRDB) to a
Global Routing Registry. The Routing Arbiter panel of Bill Manning
(ISI), Yakov Rekhter (IBM) and Elise Gerich answered questions
concerning different aspects of the collaborative project. John
Scudder presented an NSFNET traffic analysis with projected NAP
traffic loads, which was based on work by Scudder and Sue Hares.
Curtis Villamizar (ANS) presented results from the joint ANS-
Bellcore NAP testbed and a study on TCP performance. Paul Vixie
(vix.com) discussed DNS security considerations. Peter Lothberg
introduced the European Operator's Forum and the interconnectivity
of its principal participants. Yakov Rekhter (IBM) provided an
update on CIDR aggregation. Sean Doran (Sprint) discussed their
backbone reengineering. Andy Schmidt (Ameritech) discussed their
NAP Laboratory. The San Francisco NAP status, testbed results and
future ATM/NAP plans were presented by PacBell representatives
Frank Liu, Al Broscius and Chin Yuan. Tim Salo (Minnesota
Supercomputer Center and SPRINT-NAP Co-PI) discussed ATM
implementation problems and future directions.
Several of the presented papers, the NANOG charter, meeting minutes
and related documents are available on the Merit-IE World Wide Web
server RA Info page, http://www.ra.net/rainfo.html and/or for
anonymous FTP from merit.edu in the directory
/pub/nanog/presentations.
A recurrent problem on the ANS/NSFNET backbone has involved the
dropping of BGP peer sessions with midlevel network peers. The
problem was particularly evident during the twice-weekly GateD
reconfigurations. The configuration files are fairly large and
primarily composed of statements controlling the export of routing
information to the midlevel peers. Since many of the midlevels are
learning many of these routes from other midlevel peers at the same
ENSS, it is not necessary for them to also receive these routes
from the ENSSs. At ENSS 136, the problem became acute with a
configuration file of over 120,000 lines. By working with the ENSS
136 peers we were able to initially remove 5,000 lines with more to
follow. Merit also has begun work with peers of ENSSs 144 and 145,
which also have large configuration files and many peering
sessions. By working with these peers, and especially NSI as it
migrated from EGP to BGP and consolidated into a single AS, almost
20,000 lines were removed from the ENSS 144 configuration file.
Cooper [Page 32]
Internet Monthly Report October 1994
These changes should improve overall routing performance and reduce
problems seen during routing updates. If you peer with other
networks at these or other primary ENSSs, please consider a review
of your AS policies to help us eliminate redundant network
announcements.
Merit staff are also continuing work with midlevel networks to
promote CIDR aggregation of their routing announcements. Several
files on current aggregation status are maintained for anonymous
FTP from merit.edu in the directory /pub/nsfnet/cidr. The
configured and announced aggregates, potential aggregates and
potential savings are all available. The information and related
charts and tools are available on the Merit-IE World Wide Web
server; http://www.ra.net/home.html is the entry point to the web
collection.
Version 1.0 of the InterDomain Routing Protocol implementation for
the FAA has been released. This release provides a fully functional
and hopefully stable IDRP implementation. Gated-IDRP version 1.1,
which supports more advanced policy descriptions, will be available
shortly. Version 1.0 is available for anonymous FTP from merit.edu
in the file /pub/iso/idrp/faa/gated-idrp-1.0.tar.Z . The FAA is
funding this research on advanced features of IDRP in GateD as a
cooperative effort of the FAA, Merit and MITRE Corporation.
Jessica Yu and Enke Chen hosted a delegation from CERNet, the
Chinese National Education and Research Network, on October 31.
The program included presentations by Merit's President Eric
Aupperle, Elise Gerich, Bill Norton, Sheri Repucci, and Jessica Yu.
Merit staff shared their experiences with building MichNet and the
NSFNET backbone. The Chinese delegation presented its engineering
plan to build a national, research and education, TCP/IP-based
network to serve the 1,093 universities in China.
Kenneth T. Latta, II (klatta at merit.edu)
MIDNET
------
*MIDnet Brings Enhanced Internet Services to St. Louis*
In early October of this year, MIDnet upgraded its services for St.
Louis customers with an additional connection to the national
network backbone.
"We have significantly increased the capacity of MIDnet's St. Louis
connection to the Internet with the establishment of a high-speed
(45 Mbps) hub," said Mary McLaughlin, executive director of MIDnet.
Cooper [Page 33]
Internet Monthly Report October 1994
"St. Louis, with its core of technology-based businesses and
organizations, is an important market for us. By providing a direct
hop to the Internet, we are giving our St. Louis customers even
faster, more reliable access to the Internet."
In support of the St. Louis facility, a Sales Center was also
established at MIDnet's headquarters in Lincoln, Nebraska. The
Sales Center can be reached through a toll-free number, 1-800-682-
5550. "We want to make it as easy as possible for members and
prospective clients to reach us," states Carol Farnham, Director of
Member Services. "Providing a central point of contact for
information lets us be more effective in responding. We feel the
Sales Center will benefit our current members as well as promote
interest in the Internet."
*MIDnet NIC Fully Staffed*
MIDnet's Network Information Center has been operational and fully
staffed since July of this year. The NIC staff, consisting of three
full-time employees and a student assistant, devotes its time to
supporting the information services needs of MIDnet members, and to
promoting use and understanding of the Internet through educational
presentations. Since its establishment, the NIC has produced and
distributed MIDnet's first member newsletter, coordinated
arrangements for the semi-annual member conference held in Lincoln,
and sponsored several Internet presentations. The NIC staff is also
heavily involved in the design and development of mechanisms to
facilitate resource discovery on the Internet. The deployment of
these mechanisms will occur in mid-November when Midnet announces
its FTP, Gopher, and WWW servers to the Internet.
MIDnet's NIC can be reached via e-mail at: nic at mid.net.
*MIDnet Security Seminars*
MIDnet has announced a series of one-day seminars focusing on
Internet security. The seminars, entitled "A Practical Guide to
Secure Internet Connections", will be held in St. Louis, Kansas
City, and Chicago on November 29, 30, and December 1, respectively.
For additional seminar information, send e-mail to security at mid.net
or call 1-800-709-5550.
*MIDnet Fall Conference*
Lincoln, Nebraska was the site of MIDnet's semi-annual membership
meeting, held October 3-4, 1994. Conference participation was at an
all-time-high, with more than 150 members in attendance.
Cooper [Page 34]
Internet Monthly Report October 1994
The meeting opened with a "State of MIDnet" address given by Mary
Eileen McLaughlin, MIDnet's Executive Director. The keynote speech,
"The NSF Transition", was delivered by David Staudt of NSFNET. The
second day featured a plenary session focusing on Internet
security, with Robert Darden of Trusted Information Systems as
guest speaker. Additional conference activities included
educational sessions on Sendmail, Kerberos, PGP, DNS, ATM, and
SNMP. Panel discussion topics included Trends in K-12 Networking,
Sorting Out Campus ATM Deployment Strategies, Trends in Campus
Computing, and Trends in Government Computing and Networks.
Information on MIDnet services can be requested by calling 1-800-
682-5550, or by sending e-mail to: info at mid.net
MIDnet NIC <info at mid.net>
NORTHWESTNET
------------
Eighth Annual Meeting Nov. 8-10
===============================
NorthWestNet's Eighth Annual Meeting will be held in Portland
Oregon from November 8-10. Some of the scheduled speakers and
presenters include:
Laura Breeden Director TIIAP, Dept. of Commerce
Mayor Liz Kniss City of Palo Alto
Stephen Wolff Director DNCRI, National Science Foundation
Robert Gillespie Principal, Robert Gillespie Associates
Elise Gerich Manager Internet Engineering Group, MERIT
Andy Beecher Telecommunications Planner Analyst, TCI
Eric Hood Executive Director & CEO, NorthWestNet
and President, FARNET
Mark McCahill Gopherspace Engineer, Univ. of Minnesota
Clifford Neuman Scientist/Research Asst. Prof, Univ.
of Southern California Information
Sciences Institute (ISI)
Joan Feldman President, Computers Forensics Inc.
Thomas Longstaff Technical Staff, Computer Emergency
Response Team (CERT)
Mitchell London President & CEO, ConnectSoft
Russ Jones Internet Program Manager, DEC
Chuck Pettis Principal, Floathe Johnson
For more information about the meeting:
Gopher: gopher.nwnet.net 3333
9. NorthWestNet's Eighth Annual Meeting
Cooper [Page 35]
Internet Monthly Report October 1994
or, contact NorthWestNet at info at nwnet.net.
The Internet Passport: NorthWestNet's Guide to Our World Online
5th Ed.
===============================================================
Novices and experts alike appreciate the clarity and accuracy of
"The Internet Passport"--both as a how-to manual and as a
remarkably complete reference. Now in its fifth edition, "The
Internet Passport" is fully updated--and all resources have been
newly verified. Brand-new coverage includes a detailed guide to
becoming an information provider, and a comprehensive catalog of
Internet health care resources. "The Internet Passport" is ideal
for MIS Managers, Information professional, students and teachers,
medical practitioners, scientists, government officials and anyone
else responsible for accessing the Internet
For the past several years, NorthWestNet has self-published this
popular Internet resource guide. To better serve the demand for the
book and to reach a wider audience, NorthWestNet has signed with
Prentice Hall PTR division to publish the fifth edition. The book
is in production now and is expected to be available in late
December. For more information about the book, contact Prentice
Hall at 1-800-382-3419.
NorthWestNet Internet Training Series
======================================
October saw the completion of a new training module for the
NorthWestNet Internet Training Series. "Travelling the World Wide
Web" was beta-tested this month and will be formally introduced at
a preconference workshop at the November NorthWestNet Annual
Meeting. This class will appear on future public class schedules.
Standard training classes open to the public were held at the
NorthWestNet training facility as they have been in previous
months. For more information:
Gopher: gopher.nwnet.net port 3333
directory: 5. NorthWestNet Information and Resources
1. NorthWestNet Internet Training Series
FTP Host: ftp.nwnet.net
directory: /training
filename: course-descriptions.txt
Cooper [Page 36]
Internet Monthly Report October 1994
-----------------
NorthWestNet E-mail: info at nwnet.net
15400 SE 30th Place, Suite 202 Phone: (206) 562-3000
Bellevue, WA 98007 Fax: (206) 562-4822
Dr. Eric S. Hood, Executive Director
Jan Eveleth, Director of User Services
Dan L. Jordt, Director of Technical Services
Anthony Naughtin, Director of Member Relations
NorthWestNet serves the six state region of Alaska, Idaho, Montana,
North Dakota, Oregon, and Washington.
PREPNET
-------
New PREPnet Members
-------------------
- Internet Securities Pittsburgh, PA
- The Dickinson School of Law, Carlisle, PA
- Infobahn International, Inc, Pittsburgh, PA
- Flower Franchising, Lebanon, PA
- St. Vincent College, Latrobe, PA
- CityNet, Pittsburgh, PA
- Automation News Network, Pittsburgh, PA
- Pennsylvania College of Technology, Williamsport, PA
- ERIENET, Erie, PA
- Lancaster - Lebanon Intermediate Unit, East Petersburg, PA
With this addition, PREPnet now totals 201 members.
PREPnet News
------------
Conferences
-----------
Felicia Ferlin attended the Commonwealth Libraries 10th Annual
Technology Conference in Lancaster, Pa. on Oct. 24.
Meetings
--------
Marsha Perrott attended NANOG in Ann Arbor, Mi. on Oct. 24 and 25.
Cooper [Page 37]
Internet Monthly Report October 1994
Training
--------
On Oct. 25, Felicia Ferlin, conducted PREPnet's Introduction to the
Internet training session:
Oct. 25 Telebase Systems, Inc.
Oct. 26 Bucks County Intermediate Unit
For information regarding connectivity options in the Commonwealth
of Pennsylvania, contact the PREPnet NIC:
305 S. Craig St. E-Mail: nic at prep.net
2nd Floor Telephone: (412) 268-7870
Pittsburgh, PA 15213
UCL
----
J Crowcroft attended ACM Multimedia and spoke on a panel session
about video mediated communication.
A paper was presented at the UK Unix User Group meeting on a future
architecture for multimedia applications on multiservice networks:
http://www.cs.ucl.ac.uk/people/jon/skynet/skynet.html
THe BT funded research project in the area of Management of
Multiservice Networks, on the UK SuperJANET network had its
inaugural technical meeting. This involves:
UCL Computer Science Department
Cambridge Computer Lab
Department of Computing, Imperial College
Lancaster Computing Department
Loughborough University of Technology
Oxford Brookes University
Three of the sites have a private ATM network infrastructuer
(currently at 34Mbps), while all 6 are connecvted via the UKERNA IP
over SMDS network.
Research work includes;
i) Configuration Management - graphical tools to support the
initial construction and subsequent dynamic change of the software
components of the network services, the management system itself
and distributed applications.
Cooper [Page 38]
Internet Monthly Report October 1994
ii) Policy Based Traffic Management - This will provide a language
and associated tools for specifying policy which can be used to
modify the behaviour of automated manager agents to enable them to
deal with network congestion in real-time.
iii) Quality of Service Management - this will permit multi-media,
application specific QoS requirements to be specified and mapped
onto the required support mechanisms in the underlying services.
iv) Traffic Monitoring and Measurement - distributed traffic
monitoring using statistical algorithms will be provided as well as
a traffic source based on a multi-bitrate video and audio service
to evaluate performance.
v) Security - an architecture for assuring secure and authenticated
signalling will be developed, as well as a unified approach for
authenticating end-user traffic flows based on virtual channels.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
Cooper [Page 39]
Internet Monthly Report October 1994
CALENDAR
--------
Last update 11/9/94
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at cnri.reston.va.us>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
FYI - New Dates for Email World Spring 1995
- New Dates for U.S. APPC/APPN (AATC) Technical Conf. moved from
July to May.
************************************************************************
1994
------------
Nov. 7-11 IEEE P802.11 Plenary Incline Village, NV
Nov. 8-10 7th IFIP WG6.1 Wkshp on
Protocol Test Systems Tokyo, Japan
Nov. 8-11 OPENNET '94 German Soc. of
Internet Users Munich
Nov. 11-14 ICCCN '94 San Francisco, CA
Nov. 14-15 CEC Cist 237 M-media Vienna, Austria
Nov. 14-16 ISDN User Forum Copenhagen, Denmark
Nov. 14-18 Supercomputing '94 Washington, DC
Nov. 14-18 USENIX/ACM SIGOPS Monterey, CA
Nov. 15-16 CEN/CENELEC/ETSI Conf. Brussels
Nov. 18-29 Nerdathon '94 - Windows into
the Internet Lake Tahoe
Nov. 21-22 ATM: Real Choices Wkshp Univ. Md. Baltimore
Nov. 28-29 ICT Standardization Pol. Wkshp Belgium
Nov. 28-30 Ntwk. Svs. Conf. (NSC'94) London, UK
Nov. 28-Dec. 1 GLOBECOM '94 San Francisco, CA
Nov. 28-Dec. 2 Email World Boston, MA
Nov. 28-Dec. 2 Windows Solutions Frankfurt, Germany
Nov. 29-Dec. 2 ATM Forum Kyoto, Japan
Nov. 29-Dec. 2 Cause
Dec. 1-2 RARE Working Groups London, UK
Dec. 1-2 Wkshp on European Reqs for
Internationalisation of IT
Cooper [Page 40]
Internet Monthly Report October 1994
and Charset Technology Luxembourg
Dec. 5-7 Australian Telecom Networks and
Applications Conf. ATNAC 94 Melbourne, AU
Dec. 5-9 31st IETF (Definite) San Jose, CA
Dec. 5-9 ANSI X3T11 San Jose, CA
Dec. 5-9 10th Comp. Sec. Applications Orlando, FL
Dec. 7-9 Windows Solutions Tokyo, JP
Dec. 7-9 IEEE R/T Systems Symposium San Juan, Puerto Rico
Dec. 12-16 OIW (Firm)
Dec. 30-Jan. 2 IFIP Intl. Conf. Networks Madras, India
1995
---------
Dec. 30-Jan. 2 IFIP Intl. Conf. Networks Madras, India
Jan. 16-20 USENIX New Orleans, LA
Feb. 5-10 ATM Forum San Francisco, CA
Feb. 5-11 IS&T/SPIE Symposium on
Electronic Imaging San Jose, CA
Feb. 6-10 ANSI X3T11 St. Petersburg Bch, FL
Feb. 16-17 ISOC Symposium on Ntwk &
Distribruted System Security San Diego, CA
Feb. 20 Int'l Internet OGs Meetings San Diego
Feb. 20-24 UniForum Dallas CC, Dallas, TX
Feb. 21-22 Int'l Internet Ops Conference San Diego
Feb. 22-24 ICODP '95 Brisbane
Feb. 26-Mar. 3 SHARE (IBM) Los Angeles, CA
Mar. 6-10 IEEE 802 Plenary (Firm) West Palm Beach, FL
Mar. 6-10 SNMP Test Summit III
Mar. 13-17 OIW (Firm)
Mar. 13-24 ISO/IEC JTC1/SC6 Tokyo, JP
Mar. 16-19 3rd Intntl Telecom. Systems
Modelling & Analysis Nashville, TN
Mar. 27-31 NetWorld+Interop Las Vegas, NV
Mar. 28-31 Seybold Seminars Boston, MA
Apr. 2-6 IEEE Infocom '95 Boston, MA
Apr. 3-7 ANSI X3T11 Monterey, CA
Apr. 3-7 32nd IETF (Definite) Danvers, MA
Apr. 4-5 Federal Networking Council
Advisory Committee Arlington, VA
Apr. 9-14 ATM Forum Denver, CO
Apr. 17-21 Email World (Firm) Santa Clara, CA
Apr. 19-21 5th Network & Operating System
Support (NOSSADV) Workshop Boston, MA
Apr. 24-25 IFIP TC6 Wkshp Personal
Wireless Commun. Prague, Czech Republic
May 15-19 Joint European Ntwkg Conf. Tel Aviv, Israel
May 18-19 RARE Council of Admin. Tel Aviv, Israel
Cooper [Page 41]
Internet Monthly Report October 1994
May 22-25 APPC/APPN Tech. Conf. (AATC) Chicago, IL
May 28-Jun. 2 NetWorld+Interop '95 Frankfurt, Germany
Jun. ATM Forum Europe
Jun. 5-7 Digital World Los Angeles, CA
Jun. 5-9 ANSI X3T11 Rochester, MN
Jun. 12-16 OIW (Firm)
Jun. 13-16 IFIP WG6.1 PSTV-XV Warsaw
Jun. 16-17 CCIRN Singapore
Jun. 18-22 ICC '95 Seattle, WA
Jun. 18-24 ISOC Developing Country Wkshp Hawaii
Jun. 25-27 ISOC K-12 Workshop Hawaii
Jun. 26-27 ISOC Trustees & Council Hawaii
Jun. 28-30 INET '95 Hawaii
Jul. 4 Independence Day
Jul. 10-13 IEEE 802 Plenary (Firm) Maui, HI
JULY 14 BASTILLE DAY
Jul. 17-21 33rd IETF Stockholm, Sweden
Jul. 17-21 NetWorld+Interop Tokyo, Japan
Jul. 17-Aug. 3 ISO/IEC JTC 1/SC 21 Ottawa, Ontario
Aug. 6-11 ATM Forum Toronto, CA
Aug. 7-11 ANSI X3T11 (Tentative) Denver area
Aug. 14-18 ANSI X3T11 (Tentative) Denver area
Aug. 29-Sep. 1 Windows Solutions San Fran. San Francisco, CA
SEPTEMBER Windows Solutions Paris Paris, France
FALL 1995 Seybold Europe
Sep. 4-6 8th IFIP WG6.1 Intntl Wkshp on
Protocol Test Systems Every, France
Sep. 4-7 APPC/APPN Tech. Conf. (AATC) London, England
Sep. 11-15 6th IFIP High Performance
Networking, HPN'95 Palma de Mallorca, Spain
Sep. 11-15 OIW (Firm)
Sep. 25-29 7th SDL Forum Oslo
Sep. 25-29 NetWorld+Interop Atlanta, GA
Sep. 26-29 Seybold San Francisco San Francisco, CA
Oct. 1-6 ATM Forum Honolulu, HI
Oct. 2-6 ANSI X3T11 Toronto, Ontario, Canada
Oct. 3-11 Telecom '95 Geneva, Switzerland
Oct. 10-11 ANSI X3T11
Oct. 16-19 APPC/APPN Tech. Conf. (AATC) Sydney, Australia
Oct. 17-20 IFIP WG6.1 FORTE '95 Montreal, Quebec
Nov. 6-9 IEEE 802 Plenary (Firm) Montreal, Quebec
Nov. 6-10 NetWorld+Interop Paris, France
Nov. 7-10 ICNP-95 Tokyo
Nov. 13-17 GLOBECOM'95 Singapore
Nov. 27-Dec. 1 Email World (Definite) Boston, MA
Nov. 27-Dec. 1 Windows Solutions Germany Frankfurt, Germany
Dec. 3-6 ACM SIGOPS
Dec. 4-8 OIW (Firm)
Cooper [Page 42]
Internet Monthly Report October 1994
Dec. 4-8 34th IETF Dallas, TX
Dec. 4-8 ANSI X3T11 (Possible) San Diego, CA
Dec. 4-8 Supercomputing '95 (Firm) San Diego, CA
Dec. 4-8 Windows Solutions Tokyo Tokyo, Japan
Dec. 10-15 ATM Forum Orlando, FL
Dec. 11-15 11th Comp. Sec. Applications New Orleans, LO
Dec. 11-15 ULPAA (upper layers) Sydney, AU
1996
-----------
Feb. 5-9 ANSI X3T11
Mar. 11-14 UniForum San Francisco, CA
Mar. 11-15 35th IETF (Under Consideration)
Mar. 18-22 35th IETF (Under Consideration)
Mar. 18-22 OIW (Firm)
Apr. 8-13 ANSI X3T11 (Tentative) Irvine, CA
Apr. 15-19 ANSI X3T11 (Tentative) Irvine, CA
May. 13-29 ISO/IEC JTC 1/SC 21
WGs and Plenary (Firm) Kansas City, MO
Jun. 10-14 OIW (Firm)
Jun. 10-14 ANSI X3T11
Jun. 24-27 ICC'96 Dallas
Jul. 8-12 36th IETF (Under Consideration)
Jul. 22-26 36th IETF (Under Consideration)
Jul. 29-Aug. 2 36th IETF (Under Consideration)
Aug. 5-9 ANSI X3T11
Sep. 2-6 14th IFIP Conf. Canberra, AU
Sep. 9-13 OIW (Firm)
Sep. 24-27 IFIP WG6.1/FORTE/PSTV'96 (Tenative) Kaiserslauten
Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL
Nov. 11-15 37th IETF (Under Consideration)
Nov. 18-22 37th IETF (Under Consideration)
Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA
Dec. 2-6 ANSI X3T11
Dec. 9-13 OIW (Firm)
1997
-----------
Mar. 10-13 UniForum San Francisco, CA
Mar. 10-14 OIW (Firm)
Jun. 8-12 ICC '97 Montreal
Jun. 9-13 OIW (Firm)
Sep. 8-12 OIW (Firm)
Dec. 8-12 OIW (Firm)
1998
-----------
Cooper [Page 43]
Internet Monthly Report October 1994
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
---------
Via ftp: /ietf/1events.calendar.imr.txt on ietf shadow directories
Via gopher: "Internet Engineering Task Force (IETF) / IETF Meetings /
Scheduling Calendar" on ietf.cnri.reston.va.us
**********************************************************************
Ref. RSec(94)001-ac November 1994
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact the
chair of the meeting or the TERENA Secretariat. If you have
additions/corrections/comments, please mail Anne Cozanet
(e.mail address: cozanet at rare.nl).
MEETING/DATE LOCATION
============ ========
TERENA Executive Committee
--------------------------
7 November Amsterdam (TERENA Secretariat)
TERENA General Assembly
-----------------------
GA2
2 December London
GA3
18/19 May 1995 Tel Aviv (tbc)
UPTURN
------
30 November (afternoon) London
TERENA Working Groups
---------------------
WG-ISUS
1/2 December London
WG-LLT
1 December (morning) London
WG-NOP
1 December (morning) London
Cooper [Page 44]
Internet Monthly Report October 1994
LOCAL ACCESS TF
1 December (afternoon) London
ATM TF
12 December (all day) Amsterdam (TERENA Secretariat)
RIPE
----
25-27 January Amsterdam (NIKHEF, WCW)
12-14 April 1996 Berlin
PRIDE COURSES
-------------
7 November Amsterdam
11 November Pisa
14 November London
18 November Vienna
VARIOUS
-------
EuroCAIRN
EuroCAIRN Consultation Meeting
8 November Brussels (Sheraton Hotel)
(DANTE EuroCAIRN project team
and representatives of the
national networks meet to
discuss work done for EuroCAIRN
to date. closed, by invitation
ony)
EUROPEAN CERTs
(experts and interested parties)
8-9 November Hamburg
CEENet General Assembly
EUROPEAN OPERATORS FORUM
25 November London
EBONE
Consortium of Contributing Organisations
02 November Munich
EBONE Management Committee
7 December Amsterdam (TERENA Secretariat)
Cooper [Page 45]
Internet Monthly Report October 1994
EOT (Ebone Operations Team)
? December (tbd) Munich
EARN
Board of Directors
30 November - 1 December London
CCIRN
16/17 June 1995 tbc
INTERNET SOCIETY Board of Trustees
15/16 December Washington DC
IETF
5-9 December San Jose, California
3-7 April 1995 Danvers, Massachusetts
17-21 July 1995 Stockholm, Sweden
4-8 December 1995 Dallas (tbc)
EWOS
----
Technical Assembly
22-23 November Brussels
Steering Committee
6 December Brussels
ETSI
----
General Assembly
22/23 November Nice, France
CONFERENCES
*******************************************************************
JENC6 - 6th Joint European Networking Conference
15-18 May 1995 in Tel Aviv, Israel
To be added to the conference email distribution list, send a message
to <jenc6-request at rare.nl>.
For information, email <jenc6-sec at rare.nl>.
To submit a paper, email <jenc6-submit at rare.nl>
JENC6 Programme Committee
^^^^^^^^^^^^^^^^^^^^^^^^^
1 December London
Cooper [Page 46]
Internet Monthly Report October 1994
JENC7 - 7th Joint European Networking Conference
13-16 May 1996 in Budapest, Hungary
*******************************************************************
NETWORK SERVICES CONFERENCE 94
------------------------------
from 28 to 30 November 1994
in London (UK)
For further information contact David Sitman (PC Vice Chairman) via
email: <A79 at TAUNIVM.bitnet>;
Paper submissions to: <NSC94 at EARNCC.EARN.NET>
OTHER CONFERENCES
nb. For some of the following events, full text information is
available from the TERENA Document Store under the directory calendar,
in which case the file name is specified under the information
presented below. The files may be retrieved via:
anonymous FTP: ftp.rare.nl
Email: server at rare.nl
Gopher: gopher.rare.nl
OPENNET'94 - German Society of Internet Users (DIGI e.V.)
---------------------------------------------------------
from 8-11 November in Goettingen (Park Hotel Ropeter)
For further information contact the DIGI board via email:
<vorstand at digi.de>
CEN/CENELEC/ETSI CONFERENCE 1994
--------------------------------
on 15 and 16 November 1994
in the European Parliament, Brussels.
Information from Kristien Van Ingelgem, fax.+32 2 519 6819
ICT STANDARDIZATION POLICY WORKSHOP 1994
----------------------------------------
28, 29 and 30 November 1994
Chateau du Lac, Genval, Belgium
organised by the European Commission with logistic
support from EWOS.
For information, email <ewos at sp1.y-net.be>
EMAIL WORLD
-----------
The Mail Enabled Technologies Conference
from 29 November to 1 December 1994
Cooper [Page 47]
Internet Monthly Report October 1994
Hynes Convention Center, Boston MA, USA
For further information, email <expo at dic-inc.com>
Tel. +1 508 470 3880; Fax. +1 508 470 0526
WORKSHOP ON EUROPEAN USER REQUIREMENTS FOR
INTERNATIONALISATION OF IT AND CHARACTER SET TECHNOLOGY
-------------------------------------------------------
on 1 and 2 December 1994
in Luxembourg.
Organised by CEN/TC304, sponsored by CEC/DGIII,
EFTA and STRI.
Registrations before 30 September 1994
For information, email <tobbi at iti.is>
IS&T/SPIE SYMPOSIUM ON ELECTRONIC IMAGING
-----------------------------------------
from 5 till 11 February 1995
San Jose Convention Center, San Jose, California USA
-> Multimedia Computing and Networking 1995 -> Digital Video
Compression: Algorithms & Technologies 1995
Tel.(206)676 3290 - Fax.(206)647 1445
MULTIMEDIA COMPUTING & NETWORKING
---------------------------------
from 6 till 8 February 1995
San Jose Convention Center, San Jose, California USA
for registration and info, email <spie at spie.org>
DIGITAL VIDEO COMPRESSION: ALGORITHMS & TECHNOLOGIES
----------------------------------------------------
from 7 till 10 February 1995
San Jose Convention Center, San Jose, California USA
for registration and info, email <spie at spie.org>
INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED
SYSTEM SECURITY
-----------------------------------------------------
16-17 February 1995
Catamaran Hotel, San Diego, California USA
Deadline for submission of papers is 15 August 1995.
For further information, email David Balenson
<balenson at tis.com>
EEMA MEETINGS
-------------
Winter Conference
15-17 November Luxembourg
Cooper [Page 48]
Internet Monthly Report October 1994
Cooper [Page 49]
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09858;
11 Nov 94 21:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17717;
11 Nov 94 21:15 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09819;
11 Nov 94 21:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09675;
11 Nov 94 21:05 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa17498;
11 Nov 94 21:05 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA23782>; Fri, 11 Nov 1994 18:05:56 -0800
Message-Id: <199411120205.AA23782 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: IETF-Announce: ;
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Subject: Internet Monthly Report Availability via FTP and EMAIL
Reply-To: cooper at isi.edu
Date: Fri, 11 Nov 94 18:05:56 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
--NextPart
Internet Monthly Report Availability via FTP and EMAIL
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
IMR Retrieval using WW
----------------------
The URL below may be used in MOSAIC or other WWW browsers to access
the IMRs. You will see a list of names in the form IMR9407.TXT. For
example, IMR9407.TXT is the report for July 1994.
URL: ftp://ftp.isi.edu/in-notes/imr
IMR Retrieval using EMAIL via the RFC-INFO Service
--------------------------------------------------
The EMail retrieval system "RFC-Info" will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from VENERA.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where "yymm" refers to the date of
the IMR. For example IMR9207.TXT is the report for July 1992). Login
with FTP username "anonymous" and password "ftp".
Requests to be added or deleted from the Internet Monthly Report list
should be sent to "imr-request at isi.edu".
Requests to be added or deleted from the IETF list should be sent to
"ietf-request at cnri.reston.va.us".
. . .
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the ASCII version
of the IMRs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9410
--OtherAccess
Content-Type: Message/External-body;
name="imr9410.txt";
site="venera.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11237;
11 Nov 94 22:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11223;
11 Nov 94 22:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19002;
11 Nov 94 22:26 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11114;
11 Nov 94 22:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10861;
11 Nov 94 22:24 EST
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa18970;
11 Nov 94 22:25 EST
Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14490(5)>; Fri, 11 Nov 1994 19:24:53 PST
Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Fri, 11 Nov 1994 19:24:44 -0800
To: ietf at CNRI.Reston.VA.US
Cc: deering at parc.xerox.com
Subject: Re: IPng Last Call -- H Factor
In-reply-to: deering's message of Fri, 11 Nov 94 17:04:48 -0800.
<94Nov11.170452pst.12173 at skylark.parc.xerox.com>
Date: Fri, 11 Nov 1994 19:24:39 PST
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <94Nov11.192444pst.34050 at swallow.parc.xerox.com>
Umm, it just occurred to me how unwise I was to post the following to
this list:
> > ...64 is a futile attempt to keep IP numbers memorable.
>
> No, it was a futile attempt to prevent gargantuan packet headers. But the
> payload lobby doesn't have much influence in this community.
because it has a significant probability of dredging up the entire debate of
the past two years. Please suppress the urge to reply (as I should have
done) or, if you must, take it to big-internet.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03503;
12 Nov 94 16:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03497;
12 Nov 94 16:34 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10065;
12 Nov 94 16:34 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03488;
12 Nov 94 16:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03446;
12 Nov 94 16:29 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa09989;
12 Nov 94 16:29 EST
Received: by ginger.lcs.mit.edu
id AA08895; Sat, 12 Nov 94 16:28:52 -0500
Date: Sat, 12 Nov 94 16:28:52 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9411122128.AA08895 at ginger.lcs.mit.edu>
To: greg_minshall at novell.com, ses at tipper.oit.unc.edu
Subject: Re: in-addr for v6
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
From: Simon E Spero <ses at tipper.oit.unc.edu>
Actually, as an optimisation, couldn't the DNS name be used as a
compressed form of the address :-)
Nah, that's no good. The DNS name's variable length, and we all know it's more
important to make things fixed length, even if they have to be 1,432 bits long
as a result. :-)
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03568;
12 Nov 94 16:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03562;
12 Nov 94 16:39 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10151;
12 Nov 94 16:39 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03553;
12 Nov 94 16:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03520;
12 Nov 94 16:38 EST
Received: from unlinfo.unl.edu by CNRI.Reston.VA.US id aa10124;
12 Nov 94 16:38 EST
Received: from unlinfo2.unl.edu by unlinfo.unl.edu (4.1/SMI-4.1)
id AA21847; Sat, 12 Nov 94 15:37:47 CST
Received: by unlinfo2.unl.edu (4.1/SMI-4.1)
id AA07411; Sat, 12 Nov 94 15:37:42 CST
Date: Sat, 12 Nov 1994 15:37:40 -0600 (CST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: thomas keller <tkeller at unlinfo2.unl.edu>
Subject: Re: in-addr for v6
To: Rob Austein <sra at epilogue.com>
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9411111722.aa19188 at deathstar.epilogue.com>
Message-Id: <Pine.3.89.9411121535.B2364-0100000 at unlinfo2.unl.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 11 Nov 1994, Rob Austein wrote:
>> How about modeling it after the RFC 1706 approach to the same problem for
>> NSAPs ?
> RFC-1706 grew out of the same basic ideas that we used as a starting
> point, but Paul and I think we may have a slightly more elegant
> solution. As Paul says, check the DNSIND meeting, or maybe the bar.
With all due respect, what about those of us who are vitally
interested, but economically constrained from attending?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02656;
13 Nov 94 13:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02650;
13 Nov 94 13:52 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07919;
13 Nov 94 13:52 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02599;
13 Nov 94 13:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02426;
13 Nov 94 13:30 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa07594; 13 Nov 94 13:30 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm036-23.dialip.mich.net [141.211.7.65]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA28370 for <ietf at CNRI.Reston.VA.US>; Sun, 13 Nov 1994 13:30:03 -0500
Date: Sun, 13 Nov 94 17:37:43 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3448.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: NSF Monthly report
I was reading the October Internet Monthly Report this morning (while
waiting for breakfast to cook), and was _amazed_ by the NSF reporting of
"stability". Essentially, the report gives its good result by
_omitting_ the bad links, in this case a bad T1 tail circuit, which
wasn't fixed for 5 days! (What would you say to your electric company
when they took 5 days to restore power?)
Sure, you can report very fine results by dropping all the bad cases.
But, this is not honest!
Another "feature" of the report is omitting route "disconnects" (the
word "failures" would mean more) that are longer than 5 minutes. In my
measurement of AN_S to PSI route flaps between DC and Cornell, which
seem to happen rather regularly, the switchover time (during which
network unreachable occurs) seems to be about 7 minutes. These results
simply aren't reported.
My guess is that the BGP lifetime (holdtime?) is set to 3.5 minutes,
which is much too long for a T3 link. (3 to 4 seconds would be better.)
That's a clever way of avoiding the 5 minute reporting time. But, it's
not honest!
Give us honest reports, folks....
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03511;
13 Nov 94 16:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03505;
13 Nov 94 16:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09951;
13 Nov 94 16:26 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03493;
13 Nov 94 16:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03441;
13 Nov 94 16:21 EST
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa09870;
13 Nov 94 16:21 EST
Received: by gw.home.vix.com id AA19039; Sun, 13 Nov 94 12:45:47 -0800
Date: Sun, 13 Nov 94 12:45:47 -0800
X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul A Vixie <paul at vix.com>
Subject: Re: in-addr for v6
Organization: Vixie Enterprises
Message-Id: <VIXIE.94Nov13124541 at gw.home.vix.com>
References: <Pine.3.89.9411121535.B2364-0100000 at unlinfo2.unl.edu>
Nntp-Posting-Host: gw.home.vix.com
In-Reply-To: tkeller at unlinfo2.unl.edu's message of 12 Nov 1994 14:29:00 -0800
> With all due respect, what about those of us who are vitally
>interested, but economically constrained from attending?
I predict an I-D on this topic following San Jose.
--
Paul Vixie
La Honda, CA
<paul at vix.com>
decwrl!vixie!paul
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04523;
14 Nov 94 11:27 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04512;
14 Nov 94 11:27 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08719;
14 Nov 94 11:27 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04386;
14 Nov 94 11:27 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04116;
14 Nov 94 11:08 EST
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa08191; 14 Nov 94 11:08 EST
Received: from ftp.com by ftp.com ; Mon, 14 Nov 1994 11:08:01 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Mon, 14 Nov 1994 11:08:01 -0500
Received: by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA10191; Mon, 14 Nov 94 11:07:35 EST
Date: Mon, 14 Nov 94 11:07:35 EST
Message-Id: <9411141607.AA10191 at mailserv-D.ftp.com>
To: perry at imsi.com
Subject: Re: IPng Last Call -- Mobility
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten at ftp.com>
Reply-To: kasten at ftp.com
Cc: jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US, karn at qualcomm.com,
ji at cs.columbia.edu
Content-Length: 1161
Perry,
Your comments are all valid, but I fear, somewhat misdirected...
IF there were a single "datalink" substrate that the entire world used then
you would be very right. The Cellphone people are doing 'datalink-level'
mobility and if we could use that for everything then mobile-ip would
be reinventing the wheel, which would be silly.
However, the goal here is a bit wider than that. I'd like to be able
to take my laptop and disconnect it from the corporate net, turn on
its cellular modem, take it home, turn off the cell-modem and
reconnect via the link to my home, then go to the airport, get on a
plane, go to our west coast office, reconnect there, etc etc etc.
All the while I'd like to be able to maintain connections (say to
send/receive email). "Letting the cellphone people worry about this"
does not solve the complete problem -- such as when I'm connected up
to (and move about on) the LANs at work, the PPP link at home, etc.
--
Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy
present... As our case is new, so we must think anew, and
and act anew" - A. Lincoln
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04542;
14 Nov 94 11:27 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04536;
14 Nov 94 11:27 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08720;
14 Nov 94 11:27 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04387;
14 Nov 94 11:27 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04122;
14 Nov 94 11:08 EST
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa08196; 14 Nov 94 11:08 EST
Received: from ftp.com by ftp.com ; Mon, 14 Nov 1994 11:08:09 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Mon, 14 Nov 1994 11:08:09 -0500
Received: by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA10205; Mon, 14 Nov 94 11:07:47 EST
Date: Mon, 14 Nov 94 11:07:47 EST
Message-Id: <9411141607.AA10205 at mailserv-D.ftp.com>
To: bsimpson at morningstar.com
Subject: Re: IPng Last Call -- H Factor
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten at ftp.com>
Reply-To: kasten at ftp.com
Cc: ietf at CNRI.Reston.VA.US
Content-Length: 2590
> From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
>
> The target [for ip6] is 1E15 nodes, and 1E12 networks. Since the
> projected human
> population is 8.5E9 during the lifetime of IPng, this represents more
> than 10,000 nodes and 100 networks per person.
>
> These numbers were deliberately chosen to be unrealistically high. It
> is very unlikely that each and every single human will personally manage
> 100 networks, or personally assign 10,000 nodes, in their lifetime. It
> is even more unlikely that computing resources will be evenly
> distributed among all people.
Bill,
The numbers (10**15 and 10**12) were not "deliberately chosen to be
unrealistically high". I know. I was one of the choosers. The numbers
were chosen based on A) estimates from industrial sectors for
penetration of 'network connectivity' into homes and B) the desire on
the part of the people choosing these numbers to be conservative and
leave room for unanticipated growth patterns, errors, administrative
overheads, and so on.
The absolute numbers may well seem unrealistically high. No argument.
However, consider, e.g., that the number of hosts (10**15) was chosen
based on a guess that most networks will have between 100 and 1,000
hosts on them. So, if 10**12 is a good guess for a max level of
networks, 10**15 is good for the number of hosts. There will
certainly be networks with more hosts, and there certainly will be
networks with less. The average number of hosts per network will
probably be much less than 1,000 per, but we (Craig Partridge and I
-- authors of the IPng criteria document) felt that the 100-1,000
host network will be a common 'size' and IPng must be able to deal
with that.
As to the number of networks, well, that's based on the estimates of
the number of homes there will be in the world (we presume 1 network
per home -- which may be unreasonable, some countries may never be
connected, but then you get into trying to guess what percentage,
etc, of homes in the world... and who knows what economic/cultural
revolutions will occur in the under-internetted world over the next
20 years). We then added several orders of magnitude to this to
account for things like network infrastructure (eg the ppp-link to my
home is one network, the network in my home is another -- now we have
2 networks per home), wastage, etc, etc.
--
Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy
present... As our case is new, so we must think anew, and
and act anew" - A. Lincoln
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05273;
14 Nov 94 11:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09597;
14 Nov 94 11:54 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05109;
14 Nov 94 11:53 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04823;
14 Nov 94 11:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mobile-ip at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mobileip-protocol-07.txt
Date: Mon, 14 Nov 94 11:38:19 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9411141138.aa04823 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Routing for
Wireless/Mobile Hosts Working Group of the IETF.
Title : IP Mobility Support
Author(s) : C. Perkins
Filename : draft-ietf-mobileip-protocol-07.txt
Pages : 42
Date : 11/10/1994
This document specifies protocol enhancements that allow transparent
routing of IP datagrams to mobile node in the Internet. The mobile node is
always identified by its home address, regardless of its current point of
attachment to the Internet. While situated away from its home, a mobile
node is also associated with a care-of address, which provides information
about its current point of attachment to the Internet. The protocol
provides for registering the care-of address with a home agent. The home
agent sends traffic destined for the mobile node through a tunnel to the
care-of address.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mobileip-protocol-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-protocol-07.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mobileip-protocol-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19941110113139.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-protocol-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mobileip-protocol-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941110113139.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05321;
14 Nov 94 11:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09620;
14 Nov 94 11:54 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05247;
14 Nov 94 11:54 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05015;
14 Nov 94 11:47 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-umig-mime-voice-01.txt
Date: Mon, 14 Nov 94 11:47:16 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9411141147.aa05015 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME/ESMTP Profile for Voice Messaging
Author(s) : G. Vaudreuil
Filename : draft-umig-mime-voice-01.txt
Pages : 20
Date : 11/10/1994
A class of special-purpose computers has evolved to provide voice messaging
services. These machines generally interface to a telephone switch and
provide call answering and voice messaging services. Traditionally,
messages sent to a non-local machine are transported using analog
networking protocols based on DTMF signaling and analog voice playback. As
the demand for networking increases, there is a need for a standard
high-quality digital protocol to connect these machines. The following
document is a profile of the Internet standard MIME and ESMTP protocols for
use as a digital voice networking protocol.
This profile is based on an earlier effort in the Audio Message Interchange
Specification (AMIS) group to define a voice messaging protocol based on
X.400 technology. This protocol is intended to satisfy the user
requirements statement from that earlier work with the industry standard
ESMTP/MIME mail protocol infrastructures already used within corporate
internets. This profile will be called the voice profile in this document.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-umig-mime-voice-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-umig-mime-voice-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-umig-mime-voice-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19941110135219.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-umig-mime-voice-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-umig-mime-voice-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941110135219.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05385;
14 Nov 94 11:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09685;
14 Nov 94 11:56 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05361;
14 Nov 94 11:56 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05091;
14 Nov 94 11:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rem-conf at es.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-avt-cellb-profile-01.txt
Date: Mon, 14 Nov 94 11:50:11 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9411141150.aa05091 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Audio/Video Transport Working
Group of the IETF.
Title : RTP Encapsulation of CellB Video Encoding
Author(s) : M. Speer, D. Hoffman
Filename : draft-ietf-avt-cellb-profile-01.txt
Pages : 24
Date : 11/10/1994
This note describes a packetization scheme for the CellB video encoding
using RTP. This document is meant for implementors of video applications
that use RTP and CellB.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-avt-cellb-profile-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-avt-cellb-profile-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-avt-cellb-profile-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19941110161406.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-avt-cellb-profile-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-cellb-profile-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941110161406.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05405;
14 Nov 94 11:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09694;
14 Nov 94 11:56 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05351;
14 Nov 94 11:56 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05056;
14 Nov 94 11:48 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ripv2-md5-00.txt
Date: Mon, 14 Nov 94 11:48:52 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9411141148.aa05056 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the RIP Version II Working Group
of the IETF.
Title : RIP-II Cryptographic Authentication
Author(s) : F. Baker, R. Atkinson
Filename : draft-ietf-ripv2-md5-00.txt
Pages : 12
Date : 11/10/1994
Growth in the Internet has made us aware of the need for improved
authentication of routing information. RIP-II provides for unauthenticated
service (as in classical RIP), or password authentication. Both are
vulnerable to passive attacks currently widespread in the Internet.
Well-understood security issues exist in routing protocols [4]. Clear text
passwords, currently specified for use with RIP-II, are no longer
considered sufficient [5].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ripv2-md5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ripv2-md5-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ripv2-md5-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19941110160720.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ripv2-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941110160720.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05471;
14 Nov 94 11:58 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09739;
14 Nov 94 11:57 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05449;
14 Nov 94 11:57 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05148;
14 Nov 94 11:51 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: html-wg at oclc.org
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-html-fileupload-00.txt
Date: Mon, 14 Nov 94 11:51:15 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9411141151.aa05148 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Markup Language
Working Group of the IETF.
Title : File Transfer from World-Wide Web Browsers to Servers
Author(s) : L. Masinter, E. Nebel
Filename : draft-ietf-html-fileupload-00.txt
Pages : 5
Date : 11/10/1994
Currently, a World-Wide Web server can get information from users with HTML
forms. These forms have proven useful in a wide variety of applications in
which input from the user is necessary. But this capability is still
greatly limited because HTML forms don't provide a way for the user to
submit files to the server. Service providers who need to get files from
the user have had to implement custom browsers. (Examples of these custom
browsers have appeared on the www-talk mailing list.) To avoid the
necessity for custom browsers and to make WWW servers complete in their
ability to get information from the user, the WWW needs to provide a way
for users to send files to servers. Since user information is sent back to
the server using HTML forms, it is most logical to extend HTML forms to
support file submission.
This document proposes an extention to HTML to allow forms to request
users supply files as data to be returned when the form has been completely
filled out and submitted. It also includes a description of a backward
compatibility strategy that allows new servers to interact with
old WWW browsers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-html-fileupload-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-html-fileupload-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-html-fileupload-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19941110170031.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-html-fileupload-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-html-fileupload-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941110170031.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05575;
14 Nov 94 11:59 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09804;
14 Nov 94 11:59 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05537;
14 Nov 94 11:59 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05203;
14 Nov 94 11:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ballardie-cbt-overview-01.txt, .ps
Date: Mon, 14 Nov 94 11:52:04 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9411141152.aa05203 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Core Based Trees (CBT) Multicast
-- Architectural Overview and Specification --
Author(s) : A. Ballardie
Filename : draft-ballardie-cbt-overview-01.txt, .ps
Pages : 41
Date : 10/10/1994
CBT is a new architecture for local and wide-area IP multicasting, being
unique in its utilization of just one shared delivery tree, as opposed to
source-based delivery trees of traditional IP multicast schemes.
The primary advantages of the CBT approach are that it offers more
favourable scaling characteristics in certain situations than do existing
multicast algorithms, and is independent of whichever underlying unicast
routing protocol is operating.
This draft describes the CBT protocol in detail, as well as
the CBT architecture. The definition of a new network layer
multicast protocol has also meant that it has been possible to
integrate an enriched functionality into multicast that is not possible
under other IP multicast schemes. For example, CBT offers a potential
solution to ``anycasting'' [RFC 1546], and it has been possible to
integrate security features into the CBT protocol. Besides CBT's
capability to authenticate tree-joining host's and routers, optional
in-built protocol mechanisms provide a scalable solution to the multicast
key distribution problem [RFC 1704].
CBT has been designed to interoperate with existing IP multicast
techniques, as well as other new IP multicast proposals, such as PIM.
Interoperation will be discussed in detail. Some open and, as yet,
unresolved issues are also discussed.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ballardie-cbt-overview-01.txt".
Or
"get draft-ballardie-cbt-overview-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ballardie-cbt-overview-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ballardie-cbt-overview-01.txt".
Or
"FILE /internet-drafts/draft-ballardie-cbt-overview-01.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19941110131757.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ballardie-cbt-overview-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ballardie-cbt-overview-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941110131757.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07176;
14 Nov 94 13:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07170;
14 Nov 94 13:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12509;
14 Nov 94 13:31 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07161;
14 Nov 94 13:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07070;
14 Nov 94 13:25 EST
Received: from wintermute.imsi.com by CNRI.Reston.VA.US id aa12391;
14 Nov 94 13:25 EST
Received: from relay.imsi.com by wintermute.imsi.com
id NAA26357 for <ietf at CNRI.Reston.VA.US>; Mon, 14 Nov 1994 13:25:36 -0500
Received: from snark.imsi.com by relay.imsi.com
id NAA08770 for <ietf at CNRI.Reston.VA.US>; Mon, 14 Nov 1994 13:25:36 -0500
Received: by snark.imsi.com (4.1/SMI-4.1)
id AA00987; Mon, 14 Nov 94 13:25:35 EST
Message-Id: <9411141825.AA00987 at snark.imsi.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: IPng Last Call
Reply-To: perry at imsi.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 14 Nov 1994 13:25:34 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Perry E. Metzger" <perry at imsi.com>
We've gone very far towards solving the address length limitation for
the forseeable future. However, there are other limitations that we
aren't addressing at all. I know people who already have media where
datagrams can hit 64kbytes, and the notion that we have to live with
that limit for N years into the future while so overamply solving the
address length limitation sticks a bit. Consider that as networks get
faster and faster and faster this limit is going to seem very cramped
indeed in about twenty years.
Similarly, I've noted that some proposed discovery formats indicate
lifetimes for advertised information in (16 bit value) seconds. In an
era where many people are noting that a couple of seconds lifetime for
some information on T3s is almost too long, the upper bound of these
values (18.2 hours) seems very high, and the lower bound, one second,
is certain to seem like a very long period when we are dealing
routinely with links that operate in the tens to hundreds of gigabits
per second.
Perry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07986;
14 Nov 94 14:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07974;
14 Nov 94 14:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13360;
14 Nov 94 14:15 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07955;
14 Nov 94 14:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07859;
14 Nov 94 14:12 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa13303;
14 Nov 94 14:12 EST
Received: from milou.inria.fr by venera.isi.edu (5.65c/5.61+local-19)
id <AA03374>; Mon, 14 Nov 1994 11:12:19 -0800
Received: by milou.inria.fr
(5.65c8/IDA-1.2.8) id AA02036; Mon, 14 Nov 1994 20:15:17 +0100
Message-Id: <199411141915.AA02036 at milou.inria.fr>
To: ietf at isi.edu
Subject: HIPPARCH '94 Advanced Program
Date: Mon, 14 Nov 1994 20:15:16 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Walid Dabbous <Walid.Dabbous at sophia.inria.fr>
First International Workshop on
High Performance Protocol Architectures
HIPPARCH '94
ADVANCED PROGRAM
INRIA Sophia Antipolis
2004 route des Lucioles, BP 93,
06902 Sophia Antipolis cedex (FRANCE)
December 15-16, 1994
A workshop organized by INRIA within the context of the HIPPARCH
project (European-Australian collaboration); sponsored by CEC DG XIII
Program Co-Chairmen :
Jon CROWCROFT, UCL, UK
Christian HUITEMA, INRIA Sophia Antipolis France
Program Committee :
David CLARK MIT, USA
Per GUNNINGBERG SICS, Sweden
Melfyn LLOYD DSTC, Australia
Larry PETERSON University of Arizona, USA
Aruna SENEVIRATNE UTS, Australia
David TENNENHOUSE MIT, USA
Martina ZITTERBART University of Karlsruhe, Germany
Organization Co-chairmen :
Walid DABBOUS, INRIA Sophia Antipolis France
Christophe DIOT, INRIA Sophia Antipolis France
FOREWORD
The objective of the HIPPARCH project is to study and design high performance
communication architectures and implementations, based particularly on the
"Application Level Framing" and "Integrated Layer Processing" concepts. Several
research groups engaged in this area will be represented. The workshop will
present the early results and ongoing research activities. It aims at
developing discussion and exchange of ideas between the participants.
Papers presented will cover the following areas:
Configurable transmission control mechanisms
New implementation techniques
Experiences with ALF/ILP
Tools and description languages for protocol implementation
PROGRAMME
Thursday December 15,
08:30-17:00 Welcome desk.
09:00-10:30 Welcome Session.
Christian Huitema, INRIA, Sophia Antipolis (F).
Jon Crowcroft, UCL, London (UK).
10:30-11:00 Pause.
11:00-12:30 Session 1 : Application Level Framing.
Chairman : Aruna Seneviratne, UTS (OZ).
-Integrated Layer Video Decoding and Application Layer Framed
Secure Login-General Lessons from Two or Three Very Different
Applications.
A. Ghosh, M. Handley, Z. Wang, J. Crowcroft. UCL. London (UK).
-From the partial order connection concept to partial order
multimedia transport connections.
M. Diaz, C. Chassot, A. Lozes. LAAS. Toulouse (F).
-Impact of ALF on Communication Subsystems design and
performance.
I. Chrisment. INRIA. Sophia Antipolis (F).
12:30-14:00 Lunch.
14:00-15:30 Session 2 : High performance Implementations.
Chairman : Christian Huitema, INRIA Sophia Antipolis (F).
-Design and Implementation of flexible User Protocol
Interface.
B. Metzler, I. Miloucheva. TUB. Berlin (D).
-Demultiplexing on the Adapter, Experiments with Internet
Protocols over ATM.
E. W. Biersack, E. Rutsche, T. Unterschutz. EURECOM (F).
-High performance event filtering for dynamic multipoint
applications.
D. C. Schmidt. Washington University. St. Louis (US).
10:00-10:30 Pause
16:00-18:00 Session 3 : Configuration of protocols.
Chairman : P. Gunningberg. SICS (S)
-Efficient Configuration of Protocol Software for
Multiprocessors.
S. Fischer, W. Effelsberg. University of Mannheim (D).
-The Application of ILP/ALF to Configurable Protocols.
A. Richards, R. de Silva, A. Fladenmuller. UTS. Sydney (OZ).
-PROCOM: A protocol configuration manager in the function-
based communication subsystem.
B. Stiller. University of Cambridge (US)
-Communication Protocols Development Using Esterel.
C. Diot, R. de Simone, C. Huitema. INRIA Sophia Antipolis (F)
18:00-19:00 Cocktail
Friday December 16
08:30-17:00 Welcome desk.
09:00-10:30 Session 4 : Efficient implementations
Chairman : M. Zitterbart, University of Karlsruhe (D).
-High Performance Protocol Implementations in the Scout
Operating System - Invited paper.
S. O'Malley University of Arizona (US)
-A minimal-copy network interface architecture supporting
ILP and ALF.
B. Ahlgren, P. Gunningberg. SICS (S).
-Enhancing Integrated Layer Processing using Common Case
Anticipation and Data Dependence Analysis.
P. Oeschlin, EPFL, Lausanne. S. Leue, University of Berne (CH).
10:00-10:30 Pause
11:00-12:30 Session 5 : System integration
Chairman : M. Diaz. LAAS (F).
-Towards Integrated QOS management.
C. Schmidt, M. Zitterbart. University of karlsruhe (D).
-Evaluating Crucial Performance Issues of Protocol
Configuration in Da CaPo.
T. Plagemann, University of Oslo (N). B. Plattner, ETH (CH).
-System Architecture Considerations for efficient protocol
implementations.
P. Boonchai-Apsit, M. Fry, A. Seneviratne. UTS (OZ).
12:30-14:00 Lunch
14:00-15:30 Closing Debate : The future of protocol architectures
Moderator : Jon Crowcroft.
WORKSHOP INFORMATION
Venue
The workshop will be held at Sophia-Antipolis France, in the vicinity of Nice
and Cannes on the "Cote d'Azur" (french Riviera), which stretches from Cassis
to Menton encompassing a string of mediterranean resorts famous for their
beautiful scenery and lively atmosphere. Just inland from the coast is some of
the most beautiful countryside in France. Within easy reach of the workshop
site are situated some picturesque villages which are well worth a visit: Biot,
Mougins, Saint-Paul de Vence and Vallauris. Sophia-Antipolis houses more than
300 academic, research and high technology centers in the areas of telecommuni-
cations, data processing, electronics, etc. Several major international
companies have chosen to locate research facilities in the science park with in
total some 10,000 personnel.
Language
The official language of the workshop is English.
Registration fees
There will be no registration fees. Participation is free, but participants
must be regularly registered by electronic mail before the workshop. The
number of participant is limited to 50.
Name badge
An admission name badge will be delivered to each registered participant.
This badge gives access to the workshop room and it must be worn visible
throughout the whole workshop period.
Literature
A participant's edition of the proceedings will be made available at the
Welcome Desk of the workshop. Selected papers will be proposed for publication
in an international journal.
Registration form
The enclosed registration form must be returned as soon as possible by
electronic mail or post to the workshop secretary.
Accomodation
Rooms have been reserved for the workshop participants within a walking
distance of the workshop location. Early reservation is advisable.
Hotel categories are (prices are given per night) :
De Luxe hotel category **** 700 FRF
First class category *** 300 to 400 FRF
Economy category ** 250 FRF
The hotel form must be returned as soon as possible to the workshop secretary.
Travel Arrangements
NICE International airport is located only 25 kilometers from INRIA Sophia
Antipolis. Shuttles will be organized by the workshop secretary for those who
will have sent their flight information more than one week before the workshop.
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
