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
---
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
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
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
[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
> 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
"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
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
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
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
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
> 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
"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
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
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
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"
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
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.
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
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
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
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
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.
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
> > > 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
> 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
:|||: :|||: 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
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
> 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
> > > 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
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
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
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
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
[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
> > 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
> > 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
> 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
>
> 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
>
> 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
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
> > 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
> 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
> 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
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
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?
> > 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
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
> 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
> 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
% > 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
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
> 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
> 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
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
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
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
> 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
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
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
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
>
> > 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
> .
> 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.
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
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?
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
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
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
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
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
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
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
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
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
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
> > 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
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
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
> 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
personally, I can't imagine peering with my neighbors.
but maybe that's just me ... or my neighborhood.
Keith
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
|
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
> > 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
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
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
> > 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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
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
*>
*> 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
>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
> 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
>
> > 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 - 100 of 109 matches
Mail list logo