Subject: Link Local address

From: "Ken Yi \(xyi\)" <[email-masked]>
Date: Thu, 16 Mar 2006 17:30:24 -0800

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------