Please ignore: Link Local address

["Ken Yi \(xyi\)" <xyi at cisco.com>]

> -----Original Message-----
> From: Ken Yi (xyi) 
> Sent: Thursday, March 16, 2006 5:30 PM
> To: ipv6 at 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 at ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------