Subject: RE: Scoped Addressing Architecture Routing Issue

From: Richard Draves <[email-masked]>
Date: Tue, 1 Aug 2000 09:33:38 -0700

> In the example that I gave, the network is not misconfigured.  
> There is intra-site routing for an entire site, and there is a 
> second site redundantly attached to the first site.
> 
> Are you implying that a mixed-scope packet always indicates
> a misconfigured network?

The mixed-scope packet is a strong indication of misconfiguration, since the
address selection rules try to avoid mixing scopes.

Your example also has the best route between H1 & H2 in site B, be to go
through site A. This seems really unlikely to occur in actual practice. You
seem to be implicitly assuming that the two sites are in a single IGP
routing domain.

> I agree that being able to debug network problems is good, but
> I think that it is less important than being able to successfully
> route packets to their destinations.

Here's another scenario, much more plausible in my opinion.

Suppose Site A is connected to the internet via site-border router R. Host H
is in site A. Destination D is out in the internet.

Router R is connected to two links. Link 1 is an ethernet inside site A.
Link 2 is a tunnel to some 6bone router; link 2 is not in site A. Router R
has a default route out link 2 plus some more specific routes out link 1,
for the global & site-local prefixes in use within site A.

Now host H sends a packet with a site-local source address and global
destination D. When this packet gets to R, you really want R to generate a
destination-unreachable / scope-exceeded ICMP error.

But with your proposal, that wouldn't happen. Instead R would constrain its
route table lookup to site A, so it would only consider routes out link 1.
It wouldn't find any routes matching the destination. Depending on the
implementation, R might generate a destination-unreachable /
no-route-to-destination ICMP error or, it might assume the destination D is
on-link to link 1 and initiate ND (RFC 2461 section 5.2 para 2 can be
construed this way), eventually generating a destination-unreachable /
address-unreachable ICMP error. Either way, the ICMP error would be pretty
confusing.

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: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Aug 2000 17:28:00 -0400

Hi Rich,

>seem to be implicitly assuming that the two sites are in a single IGP

I am assuming that two sites _may_ be in the same routing domain, and
that problems could occur in that situation.  I don't believe that the
current IPv6 specifications assume that a single routing domain will 
always be a single site.  

My example packet could easily occur in response to a packet sent from
a host that doesn't have a site-local address (perhaps because it was
configured via DHCP?).  That host would need to use a global address to 
communicate with a site-local address, and the response would have
a site-local source and a global destination.  

The ICMP issue that you have described would also exist when using 
multiple "conceptual" routing tables in the case of a partitioned 
site.  For example:

==========================================================
SITEA
       Host1                      Host2
         |                          |
________|__.__._____  ____.______._|_____________
   Link1    |  |           |      |     Link2
            |  |          (down)  |        
            |  +-----R1----+      |
            |                     |
            |                     |
===========|=====================|=========================
SITEB      |                     |
            +--------R1-----------+

===========================================================

If a site-local packet (site-local destination and site-
local source) is send from Host1 to Host2, it would
probably be sent to the local router, R1.

R1 would then use the scoped addressing rules to forward the 
packet.  First, he would look at the destination address
to determine that he should look in the site-local table.
The site-local table would have no active route to Link2,
so he would send a Destination Unreachable/No Route 
To Destination message, _not_ a Scope Exceeded message.

In this case, it might actually be _useful_ for the sender 
to receive a Scope Exceeded message, because the sender might 
be able to switch to global communication.  The sender may 
have had both site-local and global addresses available, but
have chosen site-local communication.  But, he doesn't get the
Scope Exceeded message, so he can't act on it.

However, if a mixed scope packet is sent (global destination
and site-local source) from Host1 to Host2, R1 would look
in the global table, determine that a route exists to Link2
through R2, THEN discard the packet because of the site-local
source.  This would result in a Destination Unreachable/Scope
Exceeded message.  It seems unlikely, though, that Host1 would 
have sent a mixed-scope packet if he had a global address 
available for Host2, so the Scope Exceeded message is potentially 
_less_ useful in this situation.

Margaret

---

From: "Brian Haberman" <[email-masked]>
Date: Wed, 09 Aug 2000 17:13:57 -0400

Margaret,
     Another piece of info that may be missing.  If a non-global
scoped address (source or destination) is forwarded outside of its
zone, there is no way to determine where it belongs.  The discussion
that Steve D. and I had was that Scope Exceeded message would indicate
to a sender that a source address was trying to be forwarded out of
its zone.  I will try and build a table that specifies when the
Scope Exceeded message should be used.

Brian

-- 
Brian Haberman
Nortel Networks
[email-masked]