Subject: ICMPv6 Source Address Determination - Paranoid catch all?

From: Suresh Krishnan <[email-masked]>
Date: Tue, 11 Jan 2005 18:58:58 -0500 (EST)

Hi Folks,
  In my implementation of the source address determination algorithm, I 
have noticed that branch (d) is never traversed (section 2.2(d) of 
RFC1885,RFC2463 and draft-ietf-ipngwg-icmp-v3-06). This 
condition has been around since RFC1885. Does someone know under what 
condition this branch will be traversed? Is this just a paranoid 
catch-all?

Cheers
Suresh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jan 2005 10:31:05 +0200 (EET)

Hi,

> condition this branch will be traversed? Is this just a paranoid

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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 12 Jan 2005 09:19:00 +0000

Hi.
At 08:31 12/01/2005, Pekka Savola 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.

I reviewed this document for the general area review team on the IETF last 
call a while back.  In my review, I made some comments related to source 
address selection...

Section 2.2: I have noted previously (in connection with
Neighbor Discovery) that the source address selection rules can lead
to situations in which the scopes of the source and destination
addresses are (legitimately) mismatched.  It should be noted here that
such packets MUST not be dropped by the packet transmission mechanisms
in the node. Suggest adding the following to the end of the section:
    Under some circumstances the scope of the chosen source address may
    not match the scope of the destination address.  ICMPv6 messages
    MUST NOT be dropped in the node that generates the ICMPv6 packet on
    account of such a mismatch.

However, there are also circumstances under which this mismatch can
occur and is unhelpful.  For example, if an interface on a router only
has a link local address, rule 2.2(b) may result in an ICMPv6 response
to a problem with a site or global scope multicast destination address
being sent with a link-local scope source address.  In the Neighbor
Discovery cases, this is not a problem because all messages are link
local anyway, but in other cases the ICMPv6 message may have to
traverse some routers on its way back to the originator of the
offending message: it is inconvenient to have to make special cases
for scope checking here, and the message is much less helpful when it
arrives back at the originator.  The problem could be considered to be
a misalignment between rules 2.2(b) and 2.2(c): some thought needs to
be put into what is the best solution, but the scope of the ICMPv6
destination address and the nature of the sub-protocol need to be
taken into account - 2.2(c) could be allowed to override 2.2(b) if the
result was unhelpful in the way described, and a global unicast
address belonging to the node could be used in place of the link local
if the packet is expected to traverse other routers.

-------------

In the light of this discussion, it is possible that a more useful set of 
rules needs to be created.

I have also had discussions with implementers related to these rules, so 
there is clearly a problem for implementers.

Regards,
Elwyn

---------------------
Elwyn Davies
Consultant

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jan 2005 12:06:44 +0200 (EET)

On Wed, 12 Jan 2005, Elwyn Davies wrote:
>> 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..

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 13 Jan 2005 09:43:23 -0500 (EST)

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jan 2005 17:33:07 +0200 (EET)

Hi,

> should not be implemented.

There is not much support for it, it is too ambiguously defined to be 
useful, and because it's not sufficiently well supported, the hosts 
cannot know whether the address was chosen to make the diagnostics 
easier, or just chosen somehow.

In short, it's not proven to be useful and much implemented, and 
because of that, it can't be used in any reasonable way by the hosts. 
On the other hand, it incurs code complexity and makes the selection 
of the source address less deterministic.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 26 Jan 2005 06:06:32 +0900

>>>>> On Wed, 12 Jan 2005 12:06:44 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

>          way as for any other packet the node originates.

I tend to agree with removing 2.2(c) and with the revised text.  And,
FWIW, in some recent versions of the KAME implementation we apply the
default address selection rule defined in RFC3484 in case of 2.2 (d),
partly because the resulting source address(es) would be more
deterministic.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]