RE: IPv6: Past mistakes repeated?

Robert, Thanks for the War Games references. It actually made me lol and salvage an otherwise awful day. Cheers! -- Randall Gale Information Security Predictive Systems vox: 781-751-9629 fax: 781-329-9343 mailto:[EMAIL PROTECTED] http://www.predictive.com ---

RE: IPv6: Past mistakes repeated?

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: Pa

RE: IPv6: Past mistakes repeated?

nt: Wednesday, 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&#

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 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

RE: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

[EMAIL PROTECTED] (Anthony Atkielski) wrote on 24.04.00 in <00db01bfae2b$eec52ef0$[EMAIL PROTECTED]>: > That is mostly because the telco(s) tried to impose a fixed address length > on a scheme that really should have remained variable. Telephone numbers > overseas are truly variable. When you

Re: IPv6: Past mistakes repeated?

> 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

Re: IPv6: Past mistakes repeated?

"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 thin

Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

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 o

Re: IPv6: Past mistakes repeated?

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 PROT

Re: IPv6: Past mistakes repeated?

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 archi

Re: IPv6: Past mistakes repeated?

> 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 CIDRD, actually, no? > If anyone ha

Re: IPv6: Past mistakes repeated?

"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 h

RE: IPv6: Past mistakes repeated?

ROTECTED] Subject: Re: IPv6: Past mistakes repeated? 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

Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

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"

Re: IPv6: Past mistakes repeated?

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 aroun

Re: IPv6: Past mistakes repeated?

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.

Re: IPv6: Past mistakes repeated?

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 de

Re: IPv6: Past mistakes repeated?

On Sun, 7 May 2000, Keith Moore wrote: > 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. which is not to > say that some major ISPs won't support IPv6

Re: IPv6: Past mistakes repeated?

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 abs

Re: IPv6: Past mistakes repeated?

for a long time the assumption was that IPv6 would be deployed first in the core, and then in the periphery, of the net. I'm now of the opinion that IPv6 will be deployed first in the periphery - both in emerging networks that need large amounts of address space, and in existing IPv4 nets using 6

RE: IPv6: Past mistakes repeated?

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.

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

Sean Doran wrote: > > 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

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> > > the on-the-wire protocol overhead is not that great. the computational > > > overhead to the host and application, and the resulting loss in maximum > > > bandwidth, are fairly expensive. > > > > I tend to disagree. An association protocol only really does its work on > > connect/reconne

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

> From: Masataka Ohta [SMTP:[EMAIL PROTECTED]] > "good *if* and only if"? > > With cookies, a network is as secure as a telephone or fax network, which > is *GOOD* enough for credit card companies. Not exactly. It's pretty easy to intercept any packet on the Internet, that's not the case for reg

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

:|||: :|||: 14875 Landmark Blvd #400; Dallas, TX > .:|||:..:|||:. Email: [EMAIL PROTECTED] > > - Original Message - > From: [EMAIL PROTECTED] > To: Karl Auerbach > Cc: IETF > Sent: Wednesday, April 26, 2000 16:48 > Subject: RE: runumbering (was: R

RE: IPv6: Past mistakes repeated?

At 03:21 PM 4/24/00 -0400, J. Noel Chiappa wrote: >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

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> 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

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> > > 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 p

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

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 http://www.acm.org/pubs/articles/pr

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

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 netwo

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

In message <[EMAIL PROTECTED]>, Masataka Ohta wr ites: > >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. We learned in 19

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

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 peop

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

[EMAIL PROTECTED] - Original Message - 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

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) question: Is there value in > considering a new protocol, layered on top of TCP, but beneath new > applications, that provides an "association

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

> > 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

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

> 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 pa

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

> > I think your description is somewhat biased, Paul. Suppose that you execute Sure...I was making a point, not publishing a full analysis. But my position did take into consideration everything you mention. > the strategy you describe, and that the address 10.3.2.1, that was mapped to >

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> Actually, if your assumption is that NATv6 is better than IPv6 with > renumbering, then IPv4 and NATv4 was good enough to start with and I'm not prepared to say that NATv6 is better than IPv6+renumber, simply because what is better depends on what is important to the user. By some general a

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

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 fr

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> > 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

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> 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 on

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> 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

RE: IPv6: Past mistakes repeated?

PROTECTED] "There is no spoon." >-Original Message- >From: Connelly; M [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, April 26, 2000 10:17 AM >To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' >Subject: AW: IPv6: Past mistakes repeated? > > >On the subject of i

AW: IPv6: Past mistakes repeated?

everything was done correctly this forum would be very dull! -Michael C > -- > Van: David A Higginbotham[SMTP:[EMAIL PROTECTED]] > Verzonden:maandag 24 april 2000 13:22 > Aan: 'Anthony Atkielski'; [EMAIL PROTECTED] > Onderwerp: RE: IPv6: Past mistakes repeated?

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> > 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, do

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

Hello again, >From the note below, it's obvious that there are some misconceptions about Mobile IP that I'd like to correct. Tripp Lilley wrote: > That is, that's the way it should work... I should be able to put my > laptop to sleep, hop on the plane, land in San Francisco, pull it back > out

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> 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

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> I have a hard time believing that your average IP net manager > wouldn't prefer to run an IPv6-IPv6 NAT box (lets call this > NATv6) at her ISP boundary rather than do site-wide renumbering. some of the applications that will motivate the deployment of IPv6 will be those that do not work with N

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) question: Is there value in % considering a new protocol, layered on top of TCP, but beneath new % applications, that provides an "associati

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

On Tue, 25 Apr 2000, Karl Auerbach wrote: > 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 i

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) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the lif

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

> 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 ad

Re: IPv6: Past mistakes repeated?

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 +x

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

At 1:53 PM -0700 4/25/00, Paul Francis wrote: >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. If that were the only issue, sure. But there are tradeoffs: is the ease of renumbering (which should be a relatively rare e

RE: IPv6: Past mistakes repeated?

rgument for a global DHCP server, I don't know what is.(and you think we have problems now ;->) Jim Jim Dunn Senior Network Engineer San Francisco NOC -Original Message- From: Mathis Jim-AJM005 [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 8:02 PM To: [EMAIL PROTECTED

Re: IPv6: Past mistakes repeated?

> 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

Re: IPv6: Past mistakes repeated?

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 i

Re: IPv6: Past mistakes repeated?

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 d

Re: IPv6: Past mistakes repeated?

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 wit

runumbering (was: Re: IPv6: Past mistakes repeated?)

> > > 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 address to each > .

Re: IPv6: Past mistakes repeated?

> 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.

Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

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?

Re: IPv6: Past mistakes repeated?

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 c

Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

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 m

Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

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 n

RE: IPv6: Past mistakes repeated?

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

RE: IPv6: Past mistakes repeated?

gt; cost of delaying conversion. For the longer you delay > the inevitable, the more installed base you have to > convert and the exponentially higher the resulting cost. > > Jim > > > -Original Message- > > From: Keith Moore [mailto:[EM

RE: IPv6: Past mistakes repeated?

s "good enough" for now. -- Ian > -Original 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

RE: IPv6: Past mistakes repeated?

Monday, April 24, 2000 2:36 PM > To: Anthony Atkielski > Cc: [EMAIL PROTECTED] > Subject: Re: IPv6: Past mistakes repeated? > > > > What I find interesting throughout discussions that mention > IPv6 as a > > solution for a shortage of addresses in IPv4 is that peop

Re: IPv6: Past mistakes repeated?

> > 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 more elegant > > than a hardware key such as a dongle), but nobody seems

Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

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 l

Re: IPv6: Past mistakes repeated?

> 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 comput

Re: IPv6: Past mistakes repeated?

personally, I can't imagine peering with my neighbors. but maybe that's just me ... or my neighborhood. Keith

RE: IPv6: Past mistakes repeated?

Dick St.Peters writes: | I should probably just go back to lurking No, these are fundamentally hard problems, and nobody has real answers. What is interesting is that people haven't asked real questions either, and yet have decided that the correct approach is IPv6. | but ... my take on every |

correction Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

> > 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 add

Re: IPv6: Past mistakes repeated?

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 ad

Re: IPv6: Past mistakes repeated?

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, bu

RE: IPv6: Past mistakes repeated?

> > 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 pat

Re: IPv6: Past mistakes repeated?

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

Re: IPv6: Past mistakes repeated?

> 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 ar

Re: IPv6: Past mistakes repeated?

> 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 addres

Re: IPv6: Past mistakes repeated?

> 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 numb

Re: IPv6: Past mistakes repeated?

> 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 fixe

Fw: IPv6: Past mistakes repeated?

> 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) . That's what has to be done, anyway. I'm not sure that I see what you are saying. > As also everytime the source and destination addres

Re: IPv6: Past mistakes repeated?

> 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 DI

Re: IPv6: Past mistakes repeated?

> 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

RE: IPv6: Past mistakes repeated?

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 requ

RE: IPv6: Past mistakes repeated?

*> *> 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, R

Re: IPv6: Past mistakes repeated?

>From: "Steven M. Bellovin" <[EMAIL PROTECTED]> > >In message , "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 alread

RE: IPv6: Past mistakes repeated?

> 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? 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 t

Re: IPv6: Past mistakes repeated?

> > > 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

  1   2   >