Hi Fred, On Sat, 5 Mar 2011 15:59:06 -0800 Fred Baker <f...@cisco.com> wrote:
> Dumb question. Is there an attack in your proposal? For example, if I were to > mis-identify my RA as coming from an end-host, could I now bypass RA-Guard? > I'm not sure I fully understand your question, although I think you're asking if end-nodes would also have to enforce this source address/device function policy. That would be the case. My thoughts around this area have mainly been related to the sort of effort layer 2 devices have to go to to inspect existing format RAs - encoding device type/function in the source link local IPv6 address would seem to me to be simpler, as the permit/deny decision it would be an exact match on the first 10 bits of the source IPv6 address, almost directly after the link-layer destination address in the frame, and that avoids these layer 2 devices having to have knowledge of e.g. ICMPv6 formats, (maybe) possibilities of extension headers etc. Possibly some devices which can't implement RA guard as it is today might be able to perform a simpler link-local source address based version. My interest in compatibility with existing link-local implementations where RAs come from a non-fe80::/64 source was about how to easy a transition to this sort of addressing model would be during an interim period. I haven't fully thought through my idea, including whether the cost of this sort of change would be worth benefit, I mentioned it mainly because it was relevant to the fe80::/10 vs fe80::/64 discussion. Possibly there may be other benefits in encoding a device or function type in a link-local address even if a simpler RA guard is not one of them. Regards, Mark. > On Mar 5, 2011, at 2:56 PM, Mark Smith wrote: > > > 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 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
