> 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 PROTECTED]
--------------------------------------------------------------------
