For those of you who don't know, and Jim is too modest
to tell you, he was a member of the Stanford team that
designed and implemented the first TCP protocol versions.
Later he went on to build the first versions for the
portable Digital LSI-11s used in the Packet Radio network.
Vint
At 11:06 PM 4/23/00 -0500, Richard Shockey wrote:
With "always on" IP and IP on anything this is closer to reality than we
might think. In order to permit a reasonable allocation of addresses with
room for growth the idea of 25 IP address per household and 10 person
actually seems
even if you do this the end system identifier needs to be globally
scoped, and you need to be able to use the end system identifier
from anywhere in the net, as a means to reach that end system.
DNS is a bright and successfull example of such deal.
actually, DNS is slow, unreliable, and
But we have to engineer this in some fashion that
permits efficient use of these addresses by hosts and (especially) routers.
(An earlier poster wrote that you "just have to write the code". That's
the
wrong idea -- big iron routers don't use "code" to do forwarding, they use
silicon, and
In message [EMAIL PROTECTED], "Mi
chael B. Bellopede" writes:
But we have to engineer this in some fashion that
permits efficient use of these addresses by hosts and (especially) routers.
(An earlier poster wrote that you "just have to write the code". That's
the
wrong idea -- big iron
John Stracke [EMAIL PROTECTED] writes:
Wasn't one of the design goals of IPv6 to make renumbering easier,
so that people could move from small assignments to large ones?
Yes. IPv6's primary tool in this regard is that it supports multiple
addresses simultaneously. To renumber, you add a new
Sean Doran [EMAIL PROTECTED] writes:
Unfortunately, IPv6's current addressing architecture makes it very
difficult to do this sort of traditional multihoming if one is not
a TLA.
This is not true. IPv6's TLA scheme has as its primary goal placing an
upper bound on the number of routing
% even if you do this the end system identifier needs to be globally
% scoped, and you need to be able to use the end system identifier
% from anywhere in the net, as a means to reach that end system.
%
%DNS is a bright and successfull example of such deal.
%
% actually, DNS is slow,
At 9:41 -0400 4/25/00, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Graham
Klyne wri
tes:
At 11:06 PM 4/23/00 -0500, Richard Shockey wrote:
With "always on" IP and IP on anything this is closer to reality than we
might think. In order to permit a reasonable allocation of addresses with
%
% Sean Doran [EMAIL PROTECTED] writes:
%
% Unfortunately, IPv6's current addressing architecture makes it very
% difficult to do this sort of traditional multihoming if one is not
% a TLA.
%
% This is not true. IPv6's TLA scheme has as its primary goal placing an
% upper bound on the
On Tue, 25 Apr 2000, Michael B. Bellopede wrote:
wrong idea -- big iron routers don't use "code" to do forwarding, they use
silicon, and very fast silicon at that. There are routers in production
--Steve Bellovin
Software, firmware, its a matter of semantics. Do you think
Thomas,
This is not true. IPv6's TLA scheme has as its primary goal placing an
upper bound on the number of routing prefixes that are needed in the
core.
...
Contrast that with today's IPv4 where the number of
prefixes that need to be maintained in the DFZ in order to have global
Also, I dont see how you got 25*10^9 * 1000 * 10 = 25*10^9. Should be
25*10^13. This requires log(25*10^13)/log(2), or 48 bits, to use every
address. So the original answer (80 bits left over) was correct, and using
25*10^9 in the calculation must have been a typo. I just had to satisfy
In message CC96542306D7D2119E0B080009EB58FE9582BA@MERCURY, Timothy Behne writ
es:
Also, I dont see how you got 25*10^9 * 1000 * 10 = 25*10^9. Should be
25*10^13. This requires log(25*10^13)/log(2), or 48 bits, to use every
address. So the original answer (80 bits left over) was correct, and
At 8:48 AM -0700 4/25/00, Bill Manning wrote:
and this is different from only carrying the 253 usable /8 prefixes in
IPv4 how?
The set of customers who have addresses under a given IPv4 /8 prefix greater
than 127 do not all aggregate into a single topological subregion (e.g., a
single ISP), and
On Tue, 25 Apr 2000 08:18:20 PDT, Bill Manning said:
The 2q2000 data for the in-addr tree shows 77402 unique
servers answering for 693,337 zones.
19515 servers blocked/refused data. Of the 57887 that
answered, these are the numbers for improper configuration:
% even if you do this the end system identifier needs to be globally
% scoped, and you need to be able to use the end system identifier
% from anywhere in the net, as a means to reach that end system.
%
%DNS is a bright and successfull example of such deal.
%
% actually, DNS is
From: Brian Lloyd [EMAIL PROTECTED]
I was thinking about your message, and something from my exchanges with Keith
Moore suddenly popped into my head with great clarity. I think it's the
answer to your question immediately below - and it has some very grave
consequences.
Although it's
Daniel Senie wrote:
Ian King wrote:
From the reports I read, this was implemented by mapping phone numbers
to some other tag (which the user doesn't see) which is used to get the
calls to the proper carrier and ultimately to the proper user.
Sounds a whole lot like using DNS to map
Anthony Atkielski wrote:
Exactly ... but that's the magic of the variable address scheme. You only
have to allocate disparate chunks in a fixed address scheme because the size
of each chunk is limited by the length of an address field. But if the
address field is variable, you can make
$ Hey!
$ Check Out This:
http://mafiouso3.tripod.com
$ The Best In Everything Mp3s, Pictures, Movies What Ever Your After You Will
Find It Here,
$ Want a HOT Christina Aguilera Background For Your PC
$ Just Goto The Link Below And Right Click, Then `SET AS WALLPAPER.
Anthony Atkielski wrote:
I agree! Why create a finite anything when an infinite
possibility exists?
Exactly. If you designed an open-ended protocol, you're far less likely to
ever have to rewrite it.
PS - that's what we have version numbers for.
Open-ended can sometimes mean "you
From: Keith Moore [EMAIL PROTECTED]
even if you do this the end system identifier needs to be globally
scoped, and you need to be able to use the end system identifier
from anywhere in the net, as a means to reach that end system.
DNS is a bright and successfull example of such deal.
At 10:22 AM -0700 4/25/00, Bill Manning wrote:
Given the nature of trans-oceanic b/w vs. local b/w arguments I've heard
over the years, I'd say that these delegations are esentially constrained
to topological subregions and that for the most part, having the largest
incumbent ISPs in each region
%
% So, of the 57,887 visable servers, 4314 are improperly configured
% in the visable in-addr.arpa. tree. Thats 7.45% of the
% servers being "not well maintained".
%
% a 92.55% reliability rate is not exactly impressive, at least not in
% a favorable sense.
%
% it
From: "Keith Moore" [EMAIL PROTECTED]
I wasn't there, but I expect it would have sounded
even more preposterous for someone to have said:
"I'm absolutely positive that this Internet thing
will reach to nearly everyone on the planet in a
couple of decades, and therefore we need to make
sure
From: [EMAIL PROTECTED]
The problem is that the router guys wanted to fast-path
the case of "no IP option field, routing entry in cache"
so that after seeing only the first few bytes, they could
know what interface to enqueue the outbound packet on
*before the entire packet had even come
Doesn't this leave out a few pieces of data? Given the current IPv6
address format, which includes a globally unique 64 bit interface ID and 64
bits of globally unique routing goop. My calculation is that you only have
2^64 addresses to work with which leaves roughly 12 bits, maybe 14 to
At 11:16 AM -0700 4/25/00, Bill Manning wrote:
And why do you think that the ISP community and others will not
meet the IPv6 routing proposal with anything less than the
"hostility and derision" that came from the previous attempts
to impose "topological constraints
From: Matt Holdrege [EMAIL PROTECTED]
The basic key *architectural* problem with NAT ... is that when you
have a small number of external addresses being shared by a larger
number of hosts behind some sort of "address-sharing" device, there's
no permanent association
Now, if you have a site which has more hosts than it can get external IPv4
addresses for, then as long as there are considerable numbers of IPv4 hosts a
site needs to interoperate with, *deploying IPv6 internally to the site does
the site basically no good at all*. Why?
this sounds like a
Keith,
a 92.55% reliability rate is not exactly impressive, at least not in
a favorable sense.
it might be tolerable if a failure of the PTR lookup doesn't cause
the application to fail.
If people's livelihood depends on something, they're more likely to insure it
actually works. Very
On Tue, 25 Apr 2000 20:07:05 +0200, Anthony Atkielski [EMAIL PROTECTED] said:
I dunno. I don't think that adding two more digits in the 1960s to year
fields would have really made any problems too hard. It was more a question
You never had to fit 2 more bytes onto a punch card, did you?
If people's livelihood depends on something, they're more likely to insure
it actually works.
that's a good point. but it's one thing to make sure that DNS mappings
for "major" services are correct, and quite another to make sure that
the DNS mappings are correct in both directions for
From: Keith Moore [EMAIL PROTECTED]
IPv6's claimed big advantage - a bigger address space - turns out not to be an
advantage at all - at least in any stage much short of completely deployment.
IPv6 deployment is going to have to be driven by IPv6's *other* features, and
when you take
On Tue, 25 Apr 2000 20:16:28 +0200, Anthony Atkielski [EMAIL PROTECTED] said:
But this would be even faster with a variable-length address than with a
fixed-length address. You just read address bits until you find a match,
and ignore the rest.
Umm.. No.
"until you find a match" works
Sean Doran [EMAIL PROTECTED] writes:
Unfortunately, IPv6's current addressing architecture makes it very
difficult to do this sort of traditional multihoming if one is not
a TLA.
This is not true. IPv6's TLA scheme has as its primary goal placing an
upper bound on the
IPv6's claimed big advantage - a bigger address space - turns out not to be an
advantage at all - at least in any stage much short of completely deployment.
that's an exaggeration. if you have an app that needs IPv6, you don't
need complete deployment of IPv6 throughout the whole network to
On Tue, 25 Apr 2000, J. Noel Chiappa wrote:
From: Brian Lloyd [EMAIL PROTECTED]
I was thinking about your message, and something from my exchanges
with Keith Moore suddenly popped into my head with great clarity. I
think it's the answer to your question immediately below - and it has
From: Keith Moore [EMAIL PROTECTED]
I don't see what you're getting at. the outside sites may be running v4
with a limited number of external addresses ... if they are running v6
they will have plenty of external addresses.
Not external *IPv4* addresses, they won't - which
I dunno. I don't think that adding two more digits in the 1960s to year
fields would have really made any problems too hard.
you've obviously never tried to write business applications for a
machine with only a few Kbytes of memory. memory was expensive
in the 1960s, and limited in size.
I don't see what you're getting at. the outside sites may be running v4
with a limited number of external addresses ... if they are running v6
they will have plenty of external addresses.
Not external *IPv4* addresses, they won't - which is what kind of addresses
they need
Hello Matt,
I probably shouldn't tread into these waters, but...
Now, if you have a site which has more hosts than it can get external IPv4
addresses for, then as long as there are considerable numbers of IPv4 hosts a
site needs to interoperate with, *deploying IPv6 internally to the site
Anthony Atkielski wrote:
From: [EMAIL PROTECTED]
so that after seeing only the first few bytes, they could
know what interface to enqueue the outbound packet on
*before the entire packet had even come in*.
But this would be even faster with a variable-length address than with a
Anthony Atkielski wrote:
From: "Keith Moore" [EMAIL PROTECTED]
it often seems to be the case that if you design for
the long term, what you get back isn't deployable
in the near term because you've made the problem
too hard.
I dunno. I don't think that adding two more digits in the
On Tue, 25 Apr 2000 12:19:49 PDT, "David R. Conrad" said:
If it "isn't very good", try using the Internet without it for a bit.
In your view, what is it in the DNS protocol(s) that results in a lack of
reliability?
Actually, in my experience, the protocol isn't the biggest problem. To
On Tue, 25 Apr 2000, David R. Conrad wrote:
Keith,
a 92.55% reliability rate is not exactly impressive, at least not in
a favorable sense.
it might be tolerable if a failure of the PTR lookup doesn't cause
the application to fail.
If people's livelihood depends on something,
I learned of a forthcoming RFC covering SCSI over
IP from IBM and Cisco a couple of weeks ago. Has anyone heard about
this? Has the RFC been submitted yet? Are there any web sites
with more information?
Jon William Toigo
Independent Consultant and Author
[EMAIL PROTECTED]
Anthony,
One interesting example: OSI NSAP addresses are variable length, with a
theoretical limit of 255 bytes I believe (perhaps there's an escape
mechanism to grow them longer?). There was an "implementors'
agreement" to limit the maximum length in actual use to 20 bytes "for now",
to make
Paul Francis wrote:
Sean said that traditional multihoming would be "very difficult".
You replied that "This is not true" (which I take to mean
that multihoming is not very difficult), and then go on to describe
something that sounds very difficult to me (maintain longer prefixes,
make
address space shortage is just one of many possible problems.
as long as the network keeps growing at exponential rates we are
bound to run into some other major hurdle in a few years. it might
be address space but the chances are good that before we hit that
limitation again that we will
At 1:11 PM -0700 4/25/00, Paul Francis wrote:
For me, your statement certainly reinforces the idea that multihoming in
IPv6 is indeed very difficult.
More accurately: multihoming in IP (any version) is indeed very difficult.
The problems are a fundamental consequence of having to do hierarchical
I think there are interesting things happening in DNS. I wrote a not very
good paper for AUUG a few years back noting an error rate in DNS above 10%
for the mirror site I do stats on.
Reviewing the figures for yesterday I get 9.75% unresolvable which is pretty
close to Bill Mannings figure.
I think the only reason this hasn't happened in the phone system is due
to resistance by humans to reading, writing, and entering very long
strings of digits. Unfortunately, computers aren't as fussy.
My experience is that as people become more (internationally) mobile their
use of IDD
SCSIoIP
Who'd a thunk it
I believe there are a few hash renditions of it at a higher
level of networking through distributed computing / storage and processing but
lack the white papers to send you on it. I'd be interested if anyone else has
specifics on it.
Comments?
-
Now consider the NATv6 alternative. The average net admin is already
comfortable with NAT at the ISP boundary (hell, some even like it).
She will already be running NAT, if for no other reason than to deal
with IPv4-IPv6 transition. NATv6 is much less onerous than NATv4,
because the
From: "Charles E. Perkins" [EMAIL PROTECTED]
If we get to a model where large new domains use IPv6 addressing
with NAT to global IPv4 address space, that would be quite useful.
Before too long, services will appear on the IPv6 network that
can't get the IPv4 global addresses they need.
I
% Turn it any way you want, TCP sessions can only survive renumbering through
% end to end mechanisms...
%
% Which raises the interesting (to me anyway) question: Is there value in
% considering a new protocol, layered on top of TCP, but beneath new
% applications, that provides an
From: Keith Moore [EMAIL PROTECTED]
If people's livelihood depends on something, they're more likely to insure
it actually works.
that's a good point. but it's one thing to make sure that DNS mappings
for "major" services are correct, and quite another to make sure that
the DNS mappings are
Which raises the interesting (to me anyway) question: Is there value in
considering a new protocol, layered on top of TCP, but beneath new
applications, that provides an "association" the life of which transcends
the TCP transports upon which it is constructed?
been there, done that. yes,
Which raises the interesting (to me anyway) question: Is there value in
considering a new protocol, layered on top of TCP, but beneath new
applications, that provides an "association" the life of which transcends
the TCP transports upon which it is constructed?
been there, done that.
On Tue, 25 Apr 2000 08:18:20 PDT, Bill Manning said:
The 2q2000 data for the in-addr tree shows 77402 unique
servers answering for 693,337 zones.
19515 servers blocked/refused data. Of the 57887 that
answered, these are the numbers for improper configuration:
It is a complete fallacy that NAT provides any sort of security. It does
no such thing. Security is provide by a firewall, and (more importantly)
by strong security policies that are policed and enforced.
- Original Message -
From: Leonid Yegoshin [EMAIL PROTECTED]
Newsgroups:
63 matches
Mail list logo
