RE: IPv6 addresses really are scarce after all

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: Re: IPv6 addresses really are scarce after all

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@xxxxxxxxxxxxxxxxxxx]
Sent: Tue 21/08/2007 10:39 PM
To: Iljitsch van Beijnum
Cc: ietf@xxxxxxxx
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@xxxxxxxxxxxxxxxxxxx


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf