Hi Pekka, That sounds good to me. Why do you want (c) to be removed? Is it because there is no support for it (or) is there some other reason why reason (c) should not be implemented.
Cheers Suresh On Wed, 12 Jan 2005, Pekka Savola wrote: >On Wed, 12 Jan 2005, Elwyn Davies wrote: >>> If you don't implement (c) [I have heard of only one implementation doing >>> so, and I argued it should be removed], (d) should be needed for ICMP error >>> message generation, because neither (a) nor (b) applies. >> >> On the other hand, not implementing (c) could lead to situations where using >> (d) could result in the ICMPv6 message having a link local address as source >> if the interface itself only has a link local address. This is OK for >> neighbor discovery where everything is link local but less so for an ICMPv6 >> message that came from outside the local link. > >In that case, I guess (d) would have to be reworded to better match >reality, for example, from: > > (d) Otherwise, the node's routing table must be examined to > determine which interface will be used to transmit the message > to its destination, and a unicast address belonging to that > interface MUST be used as the Source Address of the message. > >to: > > (d) Otherwise, the source address is determined by the same > way as for any other packet the node originates. > >... > >This prevents the problem with no global address on the interface, >because the code will should pick a source address of the same or >larger scope for the reply.. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
