caveat: i have not checked the entire thread yet, so it could be a
duplicate of someone's words.
First, giving each end user a /64 means that the user can
have up to 2^^64 devices at their site/home/office. That
2^64 interface ID is picked to reduce the possibility (or "probability"
if you prefer) of address collisions when we use RA. it does not need
to be tied with IEEE 802 MAC address - in fact, if i were to use
bridged ethernet and wireless segment, i prefer to use MD5(hostname)
just for the ease of migration between wired and wireless.
(i guess i would like to mention a bit about session layer protocol,
but that is outside of the point)
Second, Ethernet bridging is a well understood technology
and it works just fine even with very large numbers of devices.
that's true, but when link MTU is different, it gets very nasty.
Third, DHCP is a well understood technology that is deployed
at millions of sites world-wide and generally works quite well.
ISC dhcp server takes like 5 minutes to reboot when it serves /16
segment, due to the re-read of /var/run/dhcpd.leases.
dhcp server is a single point of failure, unless you have a replicated
lease database among dhcp servers. if there's implementations or
practices, i would like to know that.
Fourth, lots of folks (me included) happen to find it convenient
to use NAT between my site/house/office and my upstream provider.
eeeeks. i wouldn't re-start this religious war, but i just can
mention that (1) NAT is a single point of failure, and (2) NAT is
not future-proven so you have to upgrade it forever.
itojun
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf