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.
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.
A typical house
works fine just with very-low-cost Ethernet switches or hubs
internally and perhaps a very-low-cost IP router between the
house/site/office and the uplink device (e.g. cable modem,
DSL modem, FIOS ONT).
True. And I agree that switching will be much more important than
routing in these kinds of networks in the future. Then again, few
people are worse at predicting the future than engineers. So please
let's keep our options open.
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.
I've seen DHCP fail just as often as pretty much anything else, it's
not exactly bullet proof.
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. However, you WILL see stateless
autoconfiguration everywhere, and that can only work with /64
subnets. So you can't re-subnet a subnet in practice. Also, RFC 3513
says:
For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
I have no idea why this sentence is in there, except possibly to make
sure that stateless autoconfig can work, which may prove challenging
with a prefix longer than /64.
BTW, I wonder how users will react to address nickel-and-diming by
ISPs with IPv6 when they can have a /48 with 6to4 tunneling.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf