Hi, Per RFC-3513, link-Local addresses have the following format:
| 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ Does it mean that the mid 54-bit must be 0 for a legitimate link-local address? Thanks, Ken > -----Original Message----- > From: Eric Levy- Abegnoli (elevyabe) > Sent: Tuesday, March 14, 2006 11:58 PM > To: Jon Rosen (jrosen) > Cc: Ole Troan (otroan); Ken Yi (xyi); Lisa Huang (lihuang); > Doug Currie (dcurrie); Mukund Ghonasgi (mukund); Priyank > Warkhede (priyank); Malcolm Bumgardner (mbumgard); Mohamed > Mahmoud (mmahmoud); blt6 (mailer list) > Subject: Re: Link Local packet processing in data plane > > Jon, > On mardi 14 Mars 2006 20:31, Jon Rosen (jrosen) wrote: > > > -----Original Message----- > > > From: Ole Troan (otroan) > > > Sent: Tuesday, March 14, 2006 12:07 AM > > > To: Jon Rosen (jrosen) > > > Cc: Ken Yi (xyi); Lisa Huang (lihuang); Doug Currie (dcurrie); > > > Mukund Ghonasgi (mukund); Priyank Warkhede (priyank); Malcolm > > > Bumgardner (mbumgard); Mohamed Mahmoud (mmahmoud); blt6 (mailer > > > list) > > > Subject: Re: Link Local packet processing in data plane > > > > > > Jon, > > > > > > > I'm working on a data plane processing engine called CPP. > > > > As part of that work we are targeting multiple platforms, the > > > > first of which is called MCP. Recently we have been trying to > > > > work out the requirements that the platform software has for > > > > injecting packets into the data plane. One of the > areas that has > > > > been discussed is support for IPv6 link-local packet processing. > > > > > > > > Basically the question boils down to should we have > visibility to > > > > a database of information about link-local addresses in > the data > > > > plane so as to be able to process packets without > having to punt > > > > to the RP when its not necessary. If we do have a need > then this > > > > has implications on what our options are for support > for injecting > > > > link-local packets. If we don't have access for any > other reason > > > > then we need to consider if we need to have access to support > > > > injected link-local packets or if we need to find some other > > > > solution. > > > > > > > > I've seen some references that state that so far today > we do not > > > > have any support execpt for at process level on an RP for > > > > processing link-local packets. I've also seen some references > > > > that imply that at some point in the future we want to > be able to > > > > support processing link-local packets in the data plane without > > > > punting the packets to process level on an RP. > > > > This seems consistent with the goal of minimizing potential > > > > attacks against an RP by performing as much processing > as we can > > > > in the data plane (eg. we do all the IPv4 ICMP replies and > > > > redirects in the data plane already). > > > > > > we would certainly like to have the option of doing > distributed IPv6 > > > ICMP handling. in practise that means neighbour > discovery. ND sends > > > packets with link-local SA and DA, as well as link-local > multicast. > > > > > > > If you could help shed some light on what our current > direction is > > > > from a Cisco IPv6 technology perspective, and provide some > > > > guidance as to what options we might consider for CPP data path > > > > support of processing received link-local packets as well as > > > > injected link-local packets, that would be a great help. > > > > > > are you only concerned with handling of locally sourced > packets with > > > link-local SA or DA at this point? > > > > At this point, the current question at hand is more related to > > injected (locally sourced) packets. But I think it's the broader > > question in general that is of importance. If we are to implement > > IPv6 processing of link-local packets in the data plane for packets > > which are not "forus" packets, then I think it means we > would have the > > necessary forwarding database information required handle injected > > packets similar to how we would handle transit traffic. > > > > Said another way, if were going to need the forwarding > database with > > link-local address information anyway, why not use it for injected > > packets vs. coming up with some other scheme for injecting packets > > where the RP does the forwarding lookup and tells the data > plane which > > interface and encapsulation to use. > > > > > for forwarding of packets with either LL SA or DA. Claudio has a > > > document ENG-65729, which is pretty good. you could also look at > > > what they do in Earl7/8. > > > > I'll have a look, thanks for the reference. > > > > > in most cases you wouldn't expect to have to forward > packets with LL > > > DA, even though that is allowed for in the spec. and should be > > > handled (normally you have to do redirect also). > > > packets with global DA and LL SA can also only be > forwarded out the > > > same link, otherwise you need to send an ICMP out of > scope message. > > > > > > it would be good to have the option of handling these > cases in the > > > data plane. i.e only punting LL packets for us. (the > current IOS FIB > > > implementation punts anything with a LL DA). > > > > Any idea what it would take to get the additional database entries > > distributed down into the dataplane? MCP is actually a centralized > > platform but I believe they use some of the hooks intended for > > distributed platforms as a means of getting the database > into the data > > plane. > It would not take much. The current IOS implementation is to > filter the link-local tables so that they do not make it to > CEF and do not trigger the creation of link-local FIBs. So > most of what it would take would be to remove these special filters. > However, the reason to not signal these databases to CEF > still stands. There is currently one link-local RIB per > interface, and there would be one FIB as well if not > filtered. It always sounded like an overkill to CEF and > harware, since most of the time, they end up punting traffic > destined to a LL to the process switching anyway. > I must say than, from a purity perpective, the current hook > that makes the > IPv6 process switch installing FE80::/10 in the global table > to signal it to the hardware is really really ugly, and I > would rather see individual LL intalled in their respective tables. > Eric > > > > > also note that a single interface can have multiple link-local > > > addresses. > > > > > > > If there is someone else that would be more appropriate to talk > > > > with about these issues, please feel free to forward. > > > > > > I've cc'ed the IPv6 team list (blt6) > > > > > > cheers, > > > Ole > > > > Thanks for the feedback, this is very helpful information > to help us > > set the proper direction for CPP. > > > > thanks, jon. > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
