PROTECTED]]
Sent: Wednesday, May 10, 2000 5:56 AM
To: [EMAIL PROTECTED]; 'Paul Robinson'; 'Tripp Lilley'
Cc: 'Keith Moore'; 'Greg Skinner'; [EMAIL PROTECTED]
Subject: RE: IPv6: Past mistakes repeated?
A
ooops, sorry, I guess it was Paul that uncovered my retirement scheme.
v
At 10:10 AM 5/8/2000 +0100, Paul Robinson wrote:
No! We don't want to fix the holes! We want to keep a record of them
without telling the admins, and when they misbehave, not only can we pop
their kneecaps, set fire to
At 10:39 AM 5/8/2000 -0700, Jim Stephenson-Dunn wrote:
No! We don't want to fix the holes! We want to keep a record of them
without telling the admins, and when they misbehave, not only can we pop
their kneecaps, set fire to their house, release information to their
families they wouldn't want to
esday, May 10, 2000 2:58 AM
To: Paul Robinson; Tripp Lilley
Cc: Keith Moore; Greg Skinner; [EMAIL PROTECTED]
Subject: Re: IPv6: Past mistakes repeated?
ooops, sorry, I guess it was Paul that uncovered my retirement scheme.
v
At 10:10 AM 5/8/2000 +0100, Paul Robinson wrote:
No! We don't w
Anyone want to by a 3? :)
The value is not the number but its percived routablity.
%
% Heh.
%
% I know someone who wants to offer a class B at seven figures and for class B's
% that "sold" for 5 figures. And you say addresses have no value.
%
% Ah, nostalgia. It's so nice to revisit
Steve,
There was a similar discussion here about five years ago where some
people proposed market models for address allocation and routing.
Unfortunately, it's not in the archives.
I think it was on CIDRD, actually, no?
If anyone has this discussion archived, could
"J. Noel Chiappa" [EMAIL PROTECTED] wrote:
From: Greg Skinner [EMAIL PROTECTED]
There was a similar discussion here about five years ago where some
people proposed market models for address allocation and routing.
Unfortunately, it's not in the archives.
I think it was on
From: Greg Skinner [EMAIL PROTECTED]
I think it was on CIDRD, actually, no?
I don't think so.
Well, it turns out that Paul Resnick's draft (which did come out as an I-D,
draft-ietf-cidrd-mktbased-alloc-00.txt) was discussed at some length on CIDRD
in February, 1996. But it
Tripp Lilley wrote:
We came up with a wacky idea here yesterday at Interop... Why not
accelerate v6 deployment by writing a virus that will upgrade
end-stations' stacks? :)
Even better, why doesn't the IETF employ a bunch of people dressed in
black suits and wearing sun glasses to go around
In message [EMAIL PROTECTED], Paul Robinson typed:
Even better, why doesn't the IETF employ a bunch of people dressed in
black suits and wearing sun glasses to go around and 'enforce' IPv6...
we do, but you keep forgetting.
:-)
j. iab member, and official "man in black"
In message [EMAIL PROTECTED], Bill Manning writes:
Sigh,
Please -NOT- the PIARA again. There is near zero value in the
number/address
Right. That's why, following the publication of RFC 1631, everyone gave up on
NATs as a bad idea, and no one is selling them. We all have all the
"David R. Conrad" [EMAIL PROTECTED] wrote:
Ah, nostalgia. It's so nice to revisit old "discussions"...
There was a similar discussion here about five years ago where some people
proposed market models for address allocation and routing. Unfortunately,
it's not in the archives. If anyone has
In message [EMAIL PROTECTED], "J. Noel Chiappa" writes
:
From: Greg Skinner [EMAIL PROTECTED]
There was a similar discussion here about five years ago where some
people proposed market models for address allocation and routing.
Unfortunately, it's not in the archives.
I
For the archives of the historic PIARA discussions, see
http://www.apnic.net/wilma-bin/wilma/piara
(I think the mailing list is still alive)
Rgds,
-drc
"Steven M. Bellovin" wrote:
In message [EMAIL PROTECTED], "J. Noel Chiappa" writes
:
From: Greg Skinner [EMAIL PROTECTED]
Mathis Jim-AJM005 [EMAIL PROTECTED] wrote:
We need to move forward with IPv6 both by deploying it in
the "core" and setting a time-frame after which non-IPv4
compatible addresses will be assigned. Unless there is a
clear reason to move, no one wants to change software just
to change. Once
Keith Moore writes:
| the core will support v6 when it makes economic sense - i.e. when
| top tier ISPs can save enough on bandwidth and support costs (as compared
| to tunneling) to make the investment worthwhile.
Perry Metzger had this to say a long time ago (1999 12 03):
Peter made the
Sigh,
Please -NOT- the PIARA again. There is near zero value in the
number/address and very real value in the routing slot. Perhaps it is
best to simply have ebone route filter on the /16 boundaries to drive
home your point. (being cranky this morning)
% I would like to see a market
Heh.
I know someone who wants to offer a class B at seven figures and for class B's
that "sold" for 5 figures. And you say addresses have no value.
Ah, nostalgia. It's so nice to revisit old "discussions"...
Rgds,
-drc
Bill Manning wrote:
Sigh,
Please -NOT- the PIARA again.
To: Karl Auerbach
Cc: IETF
Sent: Wednesday, April 26, 2000 16:48
Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Turn it any way you want, TCP sessions can only survive renumbering
through
end to end mechanisms...
Which raises the interesting (to me anyway) quest
It seems to me that the decision to just use NATv6 rather than
do a site-wide runumber will be a very easy decision to make.
Actually, if your assumption is that NATv6 is better than IPv6 with
renumbering, then IPv4 and NATv4 was good enough to start with and
there was need to move to IPv6 in
So what I am suggesting is that it seems that there is evidence that one
can do an "association" protocol that is relatively lightweight in terms
of machinery, packets, packet headers, and end-node state if one leaves
the heavy lifting of reliability to the underlying TCP protocol.
the
Thomas Narten writes:
| Actually, if your assumption is that NATv6 is better than IPv6 with
| renumbering, then IPv4 and NATv4 was good enough to start with and
| there was need to move to IPv6 in the first place.
^
no (right? maybe this is where the previous "not" came
I agree completely with what you say about needing to push
the multi-address complexity to the host. As you kindly
pointed out (and I self-servingly expand on here), this is
an architecture I put forth about a decade ago in a sigcomm
paper (in Zurich, I don't remember the year).
The paper
mid-connection. I would assume that what people have in
mind for this are the mobility mechanisms? (The alternative
is 8+8 or some variant, which I understand to be contentious
enough that it is a defacto non-starter.)
The rubbing point is that identifying is not quite enough
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 "association" the
e -
From: [EMAIL PROTECTED]
To: Karl Auerbach
Cc: IETF
Sent: Wednesday, April 26, 2000 16:48
Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Turn it any way you want, TCP sessions can only survive renumbering
through
end to end mechanisms...
Which raises the inter
Christian;
But that architecture (hosts having multiple addresses
representing a site's multiple aggregation prefixes and
selecting among them) requires some method of identifying
hosts when they switch from one address to another
mid-connection. I would assume that what people have
Steve Bellovin;
To avoid connection hijacking, cookies, such as TCP port and sequence
numbers, is enough, if they are long enough.
That's preposterous. Long-enough numbers are good *if* and only if there are
no eavesdroppers present.
"good *if* and only if"?
With cookies, a network is
Hi all,
I guess this is somewhat unrelated to the thread's maing topic but
the paper that Christian mentioned is available to everyone (as
well as all papers from SIGCOMM since 91) through SIGCOMM's web site.
The exact pointer for the paper mentioned below is
So what I am suggesting is that it seems that there is evidence that one
can do an "association" protocol that is relatively lightweight in terms
of machinery, packets, packet headers, and end-node state if one leaves
the heavy lifting of reliability to the underlying TCP protocol.
draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of
sessions within a server pool, where uncoordinated failover of sessions from
one endpoint to another is a requirement. There is signifcant overheard and
indirection added to the session to achieve this.
We seem to be
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
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
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
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]
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
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?
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
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.
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
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
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
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
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
% 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
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.
I agree! Why create a finite anything when an infinite possibility exists?
On another note, I have heard the argument that a unique identifier already
exists in the form of a MAC address why not make further use of it?
David H
-Original Message-
From: Anthony Atkielski [mailto:[EMAIL
IPv6 is designed to be compatible with IPv4?
If what you suggest should be implemented, then probably
the entire software of all the switches and hubs need to be
upgraded (if not entirely scrapped) .
As also everytime the source and destination addresses are
upgraded, all the systems and the
In message BB2831D3689AD211B14C00104B14623B1E7569@HAZEN04, "David A Higginbot
ham" writes:
I agree! Why create a finite anything when an infinite possibility exists?
On another note, I have heard the argument that a unique identifier already
exists in the form of a MAC address why not make
"Near-perfect example"? I beg to differ. I used to work for a Local
Exchange Carrier.
The telephone number situation in the United States has been one of
continual crisis for years, because of rapid growth in use (in part because
of Internet access!). The area served by a given "area code"
Ian King wrote:
"Near-perfect example"? I beg to differ. I used to work for a Local
Exchange Carrier.
The telephone number situation in the United States has been one of
continual crisis for years, because of rapid growth in use (in part because
of Internet access!). The area served
Ian King wrote:
I'd suggest that address assignment
policy should keep process lightweight, so that it is realistic for
businesses to regularly ask for assignments in more granular chunks; rather
than grabbing a class A-size space "just in case", big users would be
willing to request
The telephone number situation in the United States has been one of
continual crisis for years, because of rapid growth in use (in part because
of Internet access!). The area served by a given "area code" would be
split
into smaller areas with multiple area codes; these days, those
From: "Steven M. Bellovin" [EMAIL PROTECTED]
In message BB2831D3689AD211B14C00104B14623B1E7569@HAZEN04, "David A Higginbot
ham" writes:
I agree! Why create a finite anything when an infinite possibility exists?
On another note, I have heard the argument that a unique identifier already
exists in
*
* I can remember early TCP/IP implementations that used class A
* addressing only, with the host portion of the Enet MAC address as the
* host portion of the IP address - "because ARP is too hard" or
* something like that. I think the first Suns did this.
*
* --
Dick,
Right
A couple of routing points, not related to NAT:
From: Ian King [EMAIL PROTECTED]
so that it is realistic for businesses to regularly ask for assignments
in more granular chunks; rather than grabbing a class A-size space
"just in case", big users would be willing to request
What I find interesting throughout discussions that mention IPv6 as a
solution for a shortage of addresses in IPv4 is that people see the
problems with IPv4, but they don't realize that IPv6 will run into the
same difficulties. _Any_ addressing scheme that uses addresses of
fixed length
Users shouldn't care or know about the network's internal addressing.
Some of the application issues with NATs spring directly from this issue
(e.g. user of X-terminal setting display based on IP address instead of
DNS name).
it's not the same issue. the point of using IP addresses in
But the first thing to remember is that there are
tradeoffs. Yes, infinitely long addresses are nice,
but they're much harder to store in programs (you
can no longer use a simple fixed-size structure for
any tuple that includes an address) ...
Sure you can. You just allocated the fixed
its ironic you should send this today, when 12
million people in london, england, had to learn
to dial 8 digits instead of 7 because of lack
of foresight from the telephone regualtor when
re-numbering less than a decade ago ...
France has increased the number of digits in telephone numbers
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.
On another note, I have heard the argument that
a unique identifier already exists in the form of
a MAC address
The telephone number situation in the United States
has been one of continual crisis for years, because
of rapid growth in use (in part because of Internet
access!). The area served by a given "area code" would
be split into smaller areas with multiple area codes;
these days, those areas
Keith Moore wrote:
if by that time the robot population exceeds the human population then
I'm happy to let the robots solve the problem of upgrading to a new
version of IP.
Ah--the Iron Man's Burden. :-)
--
/\
|John Stracke
making each house a TLA does not strike me as a scalable multihoming
solution for very large numbers of houses, given the current state of
the routing art.
The restriction has little to do with the current state of the routing art
(which is not to say that better
From: "Keith Moore" [EMAIL PROTECTED]
I suppose that's true - as long as addresses are consumed
at a rate faster than they are recycled. But the fact that
we will run out of addresses eventually might not be terribly
significant - the Sun will also run out of hydrogen
eventually, but in
Users shouldn't care or know about the network's internal addressing.
Some of the application issues with NATs spring directly from this issue
(e.g. user of X-terminal setting display based on IP address instead of
DNS name).
it's not the same issue. the point of using IP addresses in
in an earlier message, I wrote:
OTOH, I don't see why IPv6 will necessarily have significantly more
levels of assignment delegation. Even if it needs a few more levels,
6 or 7 bits out of 128 total is a lot worse than 4 or 5 bits out of 32.
the last sentence contains a thinko. it should
At 09:45 PM 4/24/00 +0200, 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.
You just have to redeploy new implementations when you add new
personally, I can't imagine peering with my neighbors.
but maybe that's just me ... or my neighborhood.
Keith
Ah ... famous last words. I feel confident that similar words were said
when the original 32-bit address scheme was developed:
"Four billion addresses ... that's more than one computer for every person
on Earth!"
"Only a few companies are every going to have more than a few computers
On Mon, 24 Apr 2000 21:45:43 +0200, Anthony Atkielski [EMAIL PROTECTED] said:
Not every machine on the Internet has an Ethernet card with a MAC address,
otherwise it might not be such a bad idea. I think using the MAC address is
an excellent idea for software protection schemes (it's a lot
On Mon, 24 Apr 2000 22:18:09 +0200, Anthony Atkielski [EMAIL PROTECTED] said:
allocate a fixed space in advance. In a variable-length address space, you
don't have to anticipate any kind of advance allocation--you can just add
digits to addresses where they are required, and routers only
ginal Message-
From: Keith Moore [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 24, 2000 5:38 PM
To: Anthony Atkielski
Cc: [EMAIL PROTECTED]
Subject: Re: IPv6: Past mistakes repeated?
[snip]
but this same impossibility means that we do not know whether
we should
put t
77 matches
Mail list logo
