Subject: RE: ICMPv6: New destination unreachable codes

From: "Christian Huitema" <[email-masked]>
Date: Fri, 30 Jan 2004 09:50:52 -0800

> > But what do you do when the routers will NOT supply this message?
> 
> Well, if you are trying to implement a multihomed solution and this
> solution
> involves multiple elements, i guess that you need all of them working
> properly. I mean, when you adopt this solution in a multihomed site,
you
> have to make sure that both the router part and the host part of the
> solution is working.

In the site multi-homing case, the host has a choice of several possible
source addresses. When a communication is requested, the host will
choose a source/destination pair according to the Default Address
Selection rules for IPv6 (RFC 3484). In some cases, the initial choice
will be the wrong one, the connection will fail, and a smart host will
want to retry with a new address pair. 

The default algorithm will be to retry after a time-out without any
information from the network. This default is necessary, because there
will indeed be many cases where the network does not provide any
explicit information. The question is then whether we can do better when
the network does provide information, by means of an ICMP message.
(Obviously, we have to be aware of security issues with ICMP messages.)

The ICMP "destination unreachable" code allow for some help in the
decision making. In the case of code 0, no route to destination, code 1,
communication with destination administratively prohibited, and code 3,
address unreachable the host should try another destination address if
one is available. In the case of code 4, port unreachable, the
communication probably just failed, although it might perhaps succeed
with a different destination address. In the case of code 2 and code 5,
the host should normally try a different source address.

Marcelo's question is whether the code 5 message can be made just a bit
more helpful than "try a new source address if you can", and whether it
should give a hint about which new source address can be tried in
preference. I understand the reluctance to add more parameters to an
ICMP message. However, simply choosing an appropriate source address for
the ICMP message might help. 

In a site exit scenario, ingress filtering is performed either at the
ingress interface of a router, or at one of the exit interfaces on the
router. I suggest that the source address of the router's ICMP message
should be one of the global scope addresses associated to that specific
interface. This gives a strong hint to the host: among the source
addresses that can be tried, pick the one that is the best match for the
router's interface.

-- Christian Huitema

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

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 30 Jan 2004 19:33:20 +0100

> However, simply choosing an appropriate source address for

very good point

thanks, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Jan 2004 20:40:06 +0200 (EET)

FWIW, I have no objection to specifying a new code, but I don't think
adding a "working address" option is feasible or useful.

> addresses that can be tried, pick the one that is the best match for the

I believe that all router implementations pick the source address of
the generated ICMP error messages based on the outgoing interface of
the message: this would be toward the site's internal infrastructure, 
and would very likely include addresses from all the prefixes.

So this would probably not help in this specific case, unless you want
to make a specific exception (which might have some obvious problems).

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