On Sun, 06 Mar 2011 08:40:40 +1300 Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> Any router that forwards fe80::/10 would be pretty stupid I think, > since the whole prefix is IANA-reserved. The RFC apears to > only reserve fe80::/64. > > Maybe this should be logged as a "held" erratum for RFC 4291, > to be made 100% clear if it is updated. > I've been a bit interested in this area fairly recently, in the context of making things like RA guard a bit easier. If some of those 54 bits were used to encode a device or function type, then RA guard could be more simply achieved by filtering on link local source address types e.g. if bits 11 through 16 in the link local prefix were used to encode a type, then - fe80::/16 - end-hosts fe81::/16 - routers fe82::/16 - dhcpv6 servers etc. This isn't a new idea, IIRC Appletalk used the lower 1-127 node ids in a cable number for end-nodes, and the upper 128 to 253 for servers. To see of non-fe80::/64 link locals would work with existing implementations, I've run up a quick test with a couple of linux boxes, with one running as a router (radvd, fe81::1/64, autoconf'd fe80::/64 deleted) and the other with a conventional kernel configured fe80::/64 link local address. Everything appears to be working, so it could be possible to move to a link-local encoded type model without too much trouble if other implementations handle non-fe80::/64 in the same way (i.e. apparently as fe80::/10). Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
