Margaret Wasserman wrote:
>
>
>> 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)?
Yes. Given the issues with magically setting the subnet-local
zone id when multiple prefixes are enabled on an interface I
would agree with that change.
Though, I would like to be able to do automatic configuration
of subnet zone ids if only one global prefix is configured
per interface. :) That would be nice for the zero-config
router scenario using multi-link subnets.
>
> 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.
We may need this as well. Typically, the default behavior for
any less than global scope zone id is that all interfaces are
in the same zone. I don't think we want that behavior with
subnet-local, it should default to being equivalent to link-local.
>
>>> 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.
If the change is made that subnet-local must be administratively
configured, you don't need to mention zone ids 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?
It is if you believe in multi-link subnets. Otherwise, your
assumption works fine and my comment is invalid. Now, do we
want to say (somewhere) that in order to identify multi-link
subnets:
- the prefixes must match
- the subnet zone ids must match
This would give us the ability to identify the link-local ==
subnet-local case from the subnet-local > link-local case.
>
>>> 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.
Host routes would work. Another possibility (though I haven't
thought it all the way through) would be to utilize NDP by sending
out NS's on both interfaces. This doesn't work if prefix1::1
exists on both nets.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
