Thomas Narten wrote:
>> CurHopLimit The default hop limit to be used when sending
>> (unicast) IP packets.
>
> why only unicast? seems like this should also apply to multicast. Are
> the default values for multicast different than unicast? (I think the
> answer is yes for IPv4, but I'm not sure that applies to IPv6. IPv6
> multicast addresses have explicit scoping, whereas IPv4 multicast used
> the TTL for that...)
I don't know how much we've discussed it, but I think IPv6 needs to have
a default hoplimit for multicast of 1, just like IPv4. Applications can
use IPV6_MULTICAST_HOPLIMIT etc to set a different value.
>> A proxy MAY multicast Neighbor Advertisements when its link-layer
>> address changes or when it is configured (by system management or
>> other mechanisms) to proxy for an address. If there are multiple
>> nodes that are providing proxy services for the same set of addresses
>> the proxies SHOULD provide a mechanism that prevents multiple proxies
>> from multicasting advertisements for any one address, in order to
>> reduce the risk of excessive multicast traffic. This is a requirement
>> on other protocols that need to use proxies for Neighbor
>> Advertisements. An example of a node that performs proxy
>> advertisements is the Home Agent specified in [MIPv6].
>
> not sure the above is right. and MIPv6 doesn't do this AFAIK. maybe we
> should change SHOULD to "should consider", or something less strong.
It might make sense to clarify the wording.
AFAIK MIPv6 avoids having multiple HAs on the home link proxy for the
same MN, by having the MN only register with one of its HAs.
>> Finally, when sending a proxy advertisement in response to a Neighbor
>> Solicitation, the sender should delay its response by a random time
>> between 0 and MAX_ANYCAST_DELAY_TIME seconds.
>
> This seems problematical for MIP, where there is exactly one
> proxy. Indeed, we should relax the requirements here so that delays
> are only required if there is a real danger of too many responses at
> the same time.
I don't even remember that text. Does anybody implement it that way?
I can see the case for a random delay if there are lots of nodes
responding to the same anycast address on the same link, but that isn't
the common way anycast is used in IPv4.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
