>The more I think about it, the more I realize that "automagically"
>creating the subnet-local scope zone id isn't going to work.
>Especially with multiple prefixes per interface.
So, this would be consistent with the suggestion that we
change the Addr Arch document to list subnet-local and larger
scopes as administratively defined (instead of just admin-local
and higher)?
Another possibility is that we could default to a non-multi-link
subnet case and declare the default to be subnet-local scope
== link-local scope.
>>These are questions that need to be answered in the scoped address
>>architecture.
>
>I think the addressing architecture needs to address the comment
>on automatically creating the subnet-local zone id.
This might be somewhat difficult, since I don't think that the
concept of zone IDs is mentioned in the Addr Arch.
>>I think it would be a reasonable default for a router that is
>>configured with the same prefix on two interfaces to assume that
>>those interfaces are on the same link (same link-local zone), and
>>in the same subnet-local zone.
>
>But if they aren't on the same link, forwarding could break.
So, does this mean that routers can't automagically configure
link-local zone IDs, either? I had always assumed that two links
with the same prefix would be in the same link-local zone. Is
that an invalid assumption?
>>In other words, I think that routers should default to the
>>single-link subnet case, unless mutli-link subnetting has been
>>explicitly configured.
>
>This is slightly different than assuming that the interfaces are
>on the same link. If the router treats them as unique prefixes,
>then forwarding and routing should work.
How would routing and forwarding work? If the router thinks that
it has two "unique" unicast prefixes that are both prefix1::/64, how
will it know where to send a packet to prefix1::1? Without
explicit host routes (which is the solution that Steve preferred in
the multi-link subnet case), there is no way to know whether or
not to forward a packet to that address.
Margaret
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
