>>>>> On Thu, 21 Mar 2002 08:13:44 -0500,
>>>>> Margaret Wasserman <[EMAIL PROTECTED]> said:
>> Thus I prefer
>>
>> <address>%<id_in_the_scope>
>>
>> and scope type is from address.
> I also prefer this notation. It removes any ambiguity about
> what a node is supposed to do if the address and the scope
> number don't match.
Then, does the following plan make sense?
- in the definition of zone indices (Section 6 in the 03 draft),
specify that a zone ID includes its scope type and an ID in the
scope when an implementation handles the zone IDs.
- in the textual representation, only define the form of
<address>%<id_in_the_scope>
and specify that <id_in_the_scope> will be translated into an
(implementation-dependent) internal form containing both scope type
and the zone in the scope.
>> And, then make sure every address has
>> a definite scope designated (the ones for which scope is a bit unclear
>> are/were :: and "::/3" (eg. those pesky IPv4 mappen and kind
>> addresses).
> Every address has to have a scope, anyway, because routers need to know
> when/if a packets should be forwarded. If an address should not be
> forwarded at all, it is link-local. If it should be constrained
> within a site, it is site-local. If it can be forwarded anywhere, it
> is global. If this information is undefined for one or more types
> of addresses, we need to define it.
It's true that a packet with link-local src or dst should not be
forwarded across a link border. However, I do not think it is always
true that "if an address should not be forwarded at all, it is
link-local." For example, a packet with a multicast source address
should not be forwarded, even if the address has a global scope.
We'll have to specify how a packet with bogus addresses should be
treated, and it may not always be a scoping issue. I think the
unspecified address falls into this type of bogus address, and makes
much sense to treat it as "no scope" than link-local.
> If an address is never meant to be used on the wire, it is effectively
> node-local. For a unicast addresses, I think that we should consider
> these addresses link-local. That way, mistakes won't be propagated
> across the network.
(an additional note which is not related to this discussion) the
notion of "node-local" has been deprecated. It has been replaced with
the notion of "interface-local".
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
