ietf
[Top] [All Lists]

RE: IPv6 addresses really are scarce after all

2007-08-28 13:10:30
You are not comparing like with like.
 
Early Sun's had an ethernet driver that would retry without waiting after a 
collision. This meant that if you put a single sun workstation on a network of 
VAXen the sun would appear to be really fast and the Vaxen slow. 
 
If you had a lot of sun workstations together, particularly diskless ones the 
result was pretty terrible.
 
 
I don't see what the relevance is however, the diskless workstations that 
caused the real issues were paging over the ethernet. I can't see how you would 
end up in that situation today, RAM is cheap, implementing virtual memory is 
going to be unnecessarily complex. It isn't a set of compromises you are likely 
to find these days.
 
Of course there are going to be embedded devices that boot from a network image.

________________________________

From: RJ Atkinson [mailto:rja(_at_)extremenetworks(_dot_)com]
Sent: Tue 21/08/2007 10:39 PM
To: Iljitsch van Beijnum
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: IPv6 addresses really are scarce after all




On  20 Aug 2007, at 15:25, Iljitsch van Beijnum wrote:
On 18-aug-2007, at 16:27, RJ Atkinson wrote:

Second, Ethernet bridging is a well understood technology
and it works just fine even with very large numbers of devices.

That's a meaningless statement. Yes, it works well if you work 
around the limitations. If you create a loop in a bridged network, 
instant fireworks. That's why spanning tree has to be so 
conservative, which is in turn the reason it's not always enabled. 
With routing on the other hand, we call the extra links 
"redundancy" and it's a good thing.

In one's home network, which was and is the subject of this thread,
one ought not worry about backhoes taking out the cabling in the
attic.  Since the uplink to the ISP would have a router in any
event, the part that might need to be redundant (i.e. the uplink)
can easily be redundant. :-)

Some years back I was at a research lab (~2500 people on site)
where virtually everyone had at least one IP connected
computing system (some had more than one).  About 1/4 of that
site was connected via a big yellow Ethernet cable running
classic CSMA/CD Ethernet at 10 Mbps (half-duplex).

Really? When I was in school we had 8 Sun diskless work stations 
per room hooked up to a 10 Mbps switch and when those puppies 
started to swap over the network, you could read a book by the 
collision light and have a chapter finished before your 
helloworld.c was compiled.

Absolutely yes.

That school's network/workstations must have been misconfigured.
We had easily over 1000 UNIX workstations on the same big yellow
Ethernet back in the day, without the kinds of issues you describe.

Third, DHCP is a well understood technology that is deployed
at millions of sites world-wide and generally works quite well.

Quick guess: you weren't at IETF-69.

One deployment having issues is VERY different from
most deployments having issues.

So one ought to be able to use DHCP to provision
IPv6 addresses (out of that overall block of ~2^^64 IPv6 addresses
mentioned above) using say 16 bits (bits 64-79) for IPv6 subnetting
and the remaining 48 bits for naming IPv6 interfaces.

This requires that all IPv6 nodes do DHCPv6 and there's a DHCPv6 
server. You won't see those two requirements met very often in 
today's IPv6 deployments.

Most IPv6 workstations/laptops support DHCPv6 client at least.
DHCPv6-capable servers are not rare within the set of IPv6-capable
routers/systems.

Yours,

Ran
rja(_at_)extremenetworks(_dot_)com


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>