Hi Steve,
I withdraw my thoughts on having to embedd uniqueness in the sitelocal
addresses. After reviewing this draft I can only come up with limited
cases where the app servers I mentioned cannot be made to work using
the work in draft-ipngwg-scoping-arch-01.txt. I think each implementor
can figure it out as I have so I won't go into the details (or I don't
think I should to be accurate), but the Basic API sin6_scope_id will
resolve the multisited database problems. The one area that does seem to
make it problematic in the spec is:
Just before section 10 Routing:
Addresses of a given (non-global) scope may be re-used in different
zones of that scope. The zone to which a particular non-global
address pertains is not encoded in the address itself, but rather is
determined by context, such as the interface from which it is sent
Routing Header with more than zero Segments Left [RFC 2460, section
4.4] swaps the original destination address with the next address in
the Routing Header. Then the above forwarding rules are applied,
using the new destination address. An implementation MUST NOT
examine additional addresses in the Routing header to determine
whether they are crossing boundaries for their scopes. Thus, it is
possible, though generally inadvisable, to use a Routing Header to
convey a non-global address across its associated zone boundary.
I believe this is very inadvisable.
The other option is for customers that really want to use multisited
servers is to use global addresses, which will not be a scarce resource
in IPv6.
regards,
/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 PROTECTED]
--------------------------------------------------------------------
