Subject: RE: Limiting the Use of Site-Local

From: "Richard Draves" <[email-masked]>
Date: Wed, 30 Oct 2002 13:39:46 -0800

> A router might (and probably should) be hard-coded not to 
> forward link-local packets, as there is no reason to ever 
> forward them.
> 
> However, a router that might ever need have multiple 
> interfaces in a single site can't be hard-coded not to 
> forward site-locals. Whether or not they will be forwarded is 
> the result of configuration.

Actually, a router can forward link-locals between interfaces on the
same link. In particular, a router can forward a packet with link-local
dest and/or source back out the interface from which it arrived (and
presumably generate a Redirect too).

If you are implementing link-locals properly, it's really very little
additional code to support site-locals. At least that's my experience.

Rich

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 31 Oct 2002 06:47:40 +0900

>additional code to support site-locals. At least that's my experience.

	could you comment on routing code? (RIPng, OSPFv3)  i still think
	it's way too tough to support multi-sited node.

itojun

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Oct 2002 23:30:47 +0000

> 	it's way too tough to support multi-sited node.

RIPng is relatively simple. link-state protocols require congruent
areas and sites. there are some open issues with regards to multicast
and PIM I believe. routing protocol support is required in any case
for VPNs.

site-locals can be used without multi-site support, i.e treated pretty
much like globals. multi-sited-ness shouldn't be recommended for other
reasons than adding complexity to routers, e.g DNS issues.

/ot

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Oct 2002 21:01:56 -0500

> 	it's way too tough to support multi-sited node.

Not that the chairs have finalized the agenda, but I am planning
on presenting what it took me to get a site-border router coded
and running.  If you want to request a certain level of detail,
let me know.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Oct 2002 21:07:45 -0500

> and PIM I believe. routing protocol support is required in any case

The actual routing protocol changes in RIPng is dependent on
how you structure your RIBs.  I hacked RIPng to make an SBR
using a monolithic RIB with an additional index (the zone id).
It was an additional 800-900 lines of code to deal with
figuring out which RIB entries needed to be advertised on each
interface.

Then there are the changes to configure and maintain the zone
IDs.

The biggest hit is actually in the forwarding.  Each packet
gets at least one additional table lookup (for the incoming
zone id).  Then there are the checks to ensure that the source
address is valid (e.g. a site-local SA and global DA trying
to cross a site border).

The extra cost?  Performance drops around 25-30% for a SBR
between 3 sites.  Of course, this was all software based,
but even a hardware-based solution will take the extra lookup
hits.

Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Oct 2002 02:51:38 +0000

[...]

> address is valid (e.g. a site-local SA and global DA trying

you have to do the outgoing check for link-locals anyway.

> but even a hardware-based solution will take the extra lookup

I don't see a performance drop in our implementation. an additional
table lookup is not needed for forwarding. you need to figure out the
scope of the DA of course, but that is needed for link-local/multicast
anyway.

cheers,
Ole

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 30 Oct 2002 22:02:49 -0500

>scope of the DA of course, but that is needed for link-local/multicast

The issue is that you also have to check the source address and drop
the packet if you would be crossing a scope boundary for the source
address...

I think that a lot of routers already (in IPv4) have the capability
of doing fast classification/filtering based on both source and
destination addresses (among other things), so I don't know how much
of a performance hit this will cause for a hardware-based routers.
And, as was already pointed out, you need to do it for link-local
addresses, anyway.

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Oct 2002 08:25:26 -0500

> you have to do the outgoing check for link-locals anyway.

Right, but the check for LL in the SA does not require
retrieving a zone id that has to be used in the forwarding
decision.

> scope of the DA of course, but that is needed for link-local/multicast

What protocol is your implementation of SL routing utilizing?

How many sites are configured on the router?

Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Oct 2002 08:30:13 -0500

> And, as was already pointed out, you need to do it for link-local

Right.  The data points I provided were for one possible implementation
of a RIB combined with a software-only router.  I can envision several
very useful optimizations to do SL routing/forwarding in hardware.

Brian