> -----Original Message----- > From: Ken Yi (xyi) > Sent: Thursday, March 16, 2006 5:30 PM > To: ipv6@ietf.org > Subject: Link Local address > > 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 > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
