At 9:52 AM -0700 6/30/00, Richard Draves wrote:
>My first reaction is I think your suggestions (reproduced below) are logical
>& consistent, but I do worry about one thing.
Two weeks late in answering (better than usual for me)...
> If I understand correctly, you're saying that a user could say
> ping6 fec0::1%3
>where 3 could be an interface index. On a multi-sited node, this would say
>"I mean fec0::1 in the site that interface 3 belongs to". But it would not
>constrain the packet to actually being sent out interface 3. It could be
>sent via any interface belonging to the same site as interface 3.
Yes, that's exactly what I was suggesting.
> My worry is that this would be rather confusing & nonintuitive for users.
Indeed. My only reason for suggesting it is to provide backwards
compatibility for implementations that are already using interface IDs
(instead of link zone IDs) in the sin6_scope_id field for link-local
addresses. Perhaps this backwards compatibility goal could be met in a
different way, e.g., applying the "non-intuitive" semantics described
above only to link-local addresses, or saying that interface IDs can
serve as link zone IDs iff a node is attached to one link per interface
(by far the dominant case). That latter suggestion is kinda the opposite
of Dave Thaler's suggestion that for scopes that have not locally been
assigned zone IDs, an app can use the IDs of a larger zone; in this case,
we would be saying that an app can use the IDs of a smaller zone.
My *preference* would be to say that sin6_scope_id must contain a zone
ID of the same scope as the accompanying address. But I anticipate
opposition to that.
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
