Address selection

[kasperd]

I was looking at http://tools.ietf.org/html/rfc2463#section-2.2 to figure out how to decide on a source address when generating an ICMPv6 response.

I understand case (a) where the source address of the response will simply be the destination address of the packet triggering the response.

However in case (b)-(d) the source address is chosen by using a unicast address assigned to a particular interface. But is there any best practice for which address should be chosen if that interface has multiple addresses?

For example, I have a router with two IPv6 addresses on an interface where one of the addresses is a 6to4 address and the other is from an HE tunnel. I should probably use my 6to4 address if the original packet was send over 6to4 and my HE address otherwise. But should I be looking at the source address or the destination address of the original packet?

[snarked]

If using Linux (or perhaps other versions of unix, including MacOs), see "ip addrlabel."  I don't know offhand what the equivalent is for windows.

There is a different RFC which documents the behavior of selection, but I don't recall its number offhand.

[kasperd]

Turns out I was looking at an obsolete version of the standard. The updated version is a bit more clear.
http://tools.ietf.org/html/rfc4443#section-2.2

My interpretation of that is that I should use the destination address of the ICMPv6 packet (which means the source address of the packet triggering the ICMPv6 response) unless I have a really good reason to do otherwise.

So if for example somebody using a 6to4 connection does a traceroute of my HE address, he would actually see my 6to4 addresses on the last few hops inside my network. But you could of cause argue that such behaviour would be confusing enough to be a good reason for choosing the addresses differently.

I'm wondering if there exists some examples of best practices.

[kasperd]

If using Linux

I asked the question because I need it for a node, where I am writing the IPv6 code myself. What Linux does is also interesting, but only as a reference on how other implementations does it. I do use Linux, so I'll keep those references in mind.

The general case of address selection I already have covered. My question was really about in which cases (if any) should ICMPv6 messages bypass the general address selection and do something else.

In the general case there is a destination address already chosen, and I have to chose a source address. But in case of an ICMPv6 response, the original message had not just one, but two IPv6 addresses. Only one of those two is copied to the destination of the ICMPv6 response. So should I always use just that one IPv6 address to make the choice, or does the other IPv6 address matter?

[snarked]

The reason I mentioned Linux is because they follow the RFC precisely in "ip addrlabel" (the "policy table" in section 2.1).  I looked it up and it's RFC 3484.

[kasperd]

it's RFC 3484.

I had already looked at that RFC. It did not answer my question. My question was not how the default address selection should be done. I already have that part covered. My question was in which cases that algorithm should be used for ICMP, and in which cases something else should be done for ICMP packets. RFC 3484 doesn't say anything about ICMP.

I guess http://tools.ietf.org/html/rfc4443#section-2.2 is the only place in any RFC that tries to answer that question. But it does leave a bit of choice open. So I am looking for any documentation other than the RFCs, which discusses which of the possible options allowed by RFC 4443 is appropriate when.

[snarked]

I don't see how ICMP isn't covered by the RFC.

IF the ICMP message is with respect to an existing packet (generally, error messages or ping replies), then one uses the source as the destination, and if one's address is the original destination, use that as the ICMP source address.  If the message is being generated by an intermediate router between source and destination, then see the next paragraph.

When an ICMP message is not with respect to an existing packet (e.g. ping requests, routing advertisements, etc.), then the selection algorithm is followed.