On Wed, 23 Apr 2003 05:17:30 PDT, Spencer Dawkins
<spencer_dawkins(_at_)yahoo(_dot_)com> said:
This was my point (perhaps I wasn't clear enough) about the
difference between site-local and firewalling - if your peer
isn't reachable because of an explicit decision from a network
operator (firewall), that's one class of problem; if your peer
isn't reachable because you have an address that doesn't work,
BUT YOU COULD HAVE BEEN GIVEN ANOTHER ADDRESS THAT WOULD HAVE
WORKED (site-local), that's a different class of problem.
The thing that bugs me is, I don't have any idea how the
application can tell that they have the second class of problem
- even ignoring ICMP Unreachable black-holing for a moment. Am I
missing something? (I don't think I'm a Genius of IPv6)
Nope. That's the problem in a nutshell (almost). One of the main b0rkedness
in site-local is almost exactly your second case - if your peer isn't reachable
because you've been given a site-local address that doesn't work because it's
mis-scoped, but you could have been given another global address that would
have worked.....
I'm having a hard time thinking of a case where an organization would have
a site-local that worked and global that didn't. Using our net as an
example, AS1312 has 128.173/16 and 198.82/16. If we *had* an IPv4 site-local
that covered both nets, I can't see any sensible reason to let those packets
pass, while preventing a host using a 128.173 address from using the 198.82
address of a peer.
pgpQuQ5u3OF0n.pgp
Description: PGP signature