> >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 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.
It's not assumed, but I think it will be uncommon to have two sites in a
single IGP routing domain and when it does occur the admin will have to take
care to avoid bad results in situations like you described.
> 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 address selection rules try really hard to avoid mixed-scope packets. It
will happen if there's a host that has a global address but no site-local
address trying to communicate with a host that has a site-local address but
no global address. I think the presence of a mixed-scoped packet generally
indicates some problem somewhere.
> 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.
This sounds right... a link is down, so you get no-route-to-destination and
you know what to start looking for.
> 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.
If the sender is trying to open a TCP connection, and their user-level code
is smart enough to iterate through the destination addresses that it got
back from getaddrinfo(), then the sender will first try the site-local
destination (using its site-local source address) and then when that
connect() fails it will fall back to the global destination (using its
global source address). The ICMP error isn't relevant to this to because TCP
treats the ICMP errors as soft errors.
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]
--------------------------------------------------------------------
