Subject: draft-ietf-ipngwg-scoped-routing-02.txt

From: Jim Bound <[email-masked]>
Date: Tue, 15 Feb 2000 23:51:17 -0500

Hi Brian,

I think your draft is very concise and complete and we should move
forward to PS if we are serious about keeping and processing scoped
addresses.

     6.  Protocol Impact

        The performance impact on routing protocols is obvious.  Routers
       implementing scoped address support will be forced to perform an
       additional check in the main forwarding path to determine if the
       source address is a site-local address.  This will add overhead to 
       the processing of every packet flowing through the router.  In
       addition, there will be some storage overhead for the scope 
       identifiers. If scoped addresses are going to be realized, this 
       performance impact may be acceptable.

I note you say "If ...."to be realized"... ???

Do you not think this is 100% a good idea as a router implementor?

Also in the above should you not reiterate at this point in the draft
that a multisited router will have to keep forwarding tables for each
site-interface it supports?  

/jim

--------------------------------------------------------------------
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: "Brian Haberman" <[email-masked]>
Date: Wed, 16 Feb 2000 07:03:25 -0500

Jim,

> forward to PS if we are serious about keeping and processing scoped

Thanks.  I was sort of waiting on the multi-homed/scoped-addressing
architecture document, but I believe this draft can stand on its own.

> Do you not think this is 100% a good idea as a router implementor?

I put the "If... to be realized" comment in there to emphasize that
there is a performance impact, but if we as a WG are serious
about scoped addresses then this impact should be acceptable.

> site-interface it supports?

Good point.  I can add such a statement.

> /jim

Brian

---

From: Jim Bound <[email-masked]>
Date: Wed, 16 Feb 2000 10:02:25 -0500

Brian,

Processing site-identifiers is a performance hit across the board and
forces datastructures for IP addresses to now maintain a tuple of
address+site-identifier.  so what we have done is increase the
time+space computation where ever it is an issue (much like the old
ES-IS vs ARP debates).  This impacts performance and configuration.  
In addition this aspect of IPv6 will affect the IETF routing protocol work, 
SNMP MIB work (already is at present and Erik Nordmark has made several 
assumptions on that list I don't agree with regarding the API but will 
wait till he brings it to this list), Mobile, and others.

I for one will at this time recommend publicly in all talks, papers, with 
the press, that users NOT USE ANYTHING BUT GLOBAL ADDRESSES and LINK-LOCAL 
ADDRESSES for unicast with IPv6 until this aspect of IPv6 is better defined 
for Routing, APIs, DNS, Address Selection, Autoconfiguration Affect, etc.  
I will also recommend that ONLY GLOBAL ADDRESSes be kept in the DNS at this 
time for IPv6 deployment.

This will not be painful to users first adopting IPv6 as most of the
early adopters I have spoken to will use Global Addresses cause it
removes the need for NAT in their IPv6 infrastructure day one, and want
the end-2-end model kept in tact with IPv6 out-of-the-box.  Most early
adopters I have spoken with want all the benefits for their networks the
huge IPv6 address space gives them and consider it an advantage and
benefit for IPv6.  

As far as link-local addresses those remain on the LAN and if users want 
multisited LANs on a host they will have to specify the sin6_scope_id
either on the app command line or out-of-band to the app. We are fixing
the API to support this now.

I have a plan for using site-local by treating them as global but I
won't go into this in the IETF and will explain it at the IPv6 Forum for
the members first, as its a deployment strategy for IPv6 not a standards
issue.   

Hint: vendors build a config switch in their v6 implementation that never
permits a source address of lesser scope to be used with a dst address
of greater scope.  This means scope exceeded cannot happen at the
router.  Also apply the same rules to tunneled packets for transition
operations.  The IETF does not want to do this so we will add it as a
vendor feature we will discuss out of the IETF.  Until these scope
issues are better defined, implemented in an interoperable manner
between multiple independent implementations, and some of the work to
define it reaches Proposed Standard Status.  And the performance penalty
you describe is in fact "really" acceptable cause we have seen it with
running code.                                              

regards,
/jim

---

From: Steve Deering <[email-masked]>
Date: Wed, 16 Feb 2000 08:54:27 -0800

>about scoped addresses then this impact should be acceptable.

The impact is no different than that required to prevent forwarding of
packets with link-local source addresses or invalid source addresses
such as multicast, loopback, or unspecified addresses.  Such source-
address filtering is a SHOULD requirement for IPv4 (see RFC 1812,
section 5.3.7), and a MUST requirement for IPv6.  And given the
heightened concern about source-address spoofing arising from the
recent attacks on prominent web sites, we are likely to see even more
demand for source-address checking by routers.

>Good point.  I can add such a statement.

Shouldn't that be per-site, not per-site-interface?

Steve

---

From: Steve Deering <[email-masked]>
Date: Wed, 16 Feb 2000 09:03:40 -0800

At 10:02 AM -0500 2/16/00, Jim Bound wrote:
>router.

Jim,

Your conclusion that "scope exceeded cannot happen at the router" is
incorrect, because there is no way to guarantee that all sources will
have the configuration switch set as you wish, nor that all sources will
obey the configuration switch (e.g., sources using "raw" transmission
interfaces).  I.e., routers cannot depend on sources being "well-behaved".

Steve

---

From: Jim Bound <[email-masked]>
Date: Wed, 16 Feb 2000 12:12:36 -0500

hi steve,

>Shouldn't that be per-site, not per-site-interface?

yep.. good catch steve that is what was in my head but not my words.

good point about src filtering another IPv6 advantage....

thx
/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 16 Feb 2000 12:17:29 -0500

Hi Steve,

>interfaces).  I.e., routers cannot depend on sources being "well-behaved".

We can gurantee it if the customer mandates that this switch be set by
all hosts which is the mantra I will begin to preach in the open market.
I will also add that routers should have such a switch too.
If they don't turn it on then your right but if they all "obey" the
mantra it will work at least for early deployment.

We have many cases of non-ietf defined behavior that is working quite
well in the industry like ingress filtering, etherchannel, etc.. we can
also do this with IPv6 Host systems.

/jim