Subject: ICMPv6: New destination unreachable codes

From: [email-masked]
Date: Thu, 29 Jan 2004 19:31:12 -0600

Hi,

I have added 2 new destination unreachable codes that
Bob suggested in the ICMPv6 draft.

(me and Bob had a discussion offline and the text is 
outcome of that)

Here is the new text. I would appreciate everyone's 
comments.

==============
   ICMPv6 Fields:

   Type           1

   Code           0 - no route to destination
                  1 - communication with destination
                        administratively prohibited
                  2 - beyond scope of source address
                  3 - address unreachable
                  4 - port unreachable
                  5 - source address failed ingress policy
                  6 - reject route to destination

   Unused         This field is unused for all code values.
                  It must be initialized to zero by the sender
                  and ignored by the receiver.
   Description

   A Destination Unreachable message SHOULD be generated by a router, or
   by the IPv6 layer in the originating node, in response to a packet
   that cannot be delivered to its destination address for reasons other
   than congestion.  (An ICMPv6 message MUST NOT be generated if a
   packet is dropped due to congestion.)

   If the reason for the failure to deliver is lack of a matching entry
   in the forwarding node's routing table, the Code field is set to 0
   (NOTE: this error can occur only in nodes that do not hold a "default
   route" in their routing tables).

   If the reason for the failure to deliver is administrative
   prohibition, e.g., a "firewall filter", the Code field is set to 1.

   If the reason for the failure to deliver is that the destination is
   beyond the scope of the source address, the Code field is set to 2.
   This condition can occur only when the scope of the source address is
   smaller than the scope of the destination address (e.g., when a
   packet has a link-local source address and a global-scope destination
   address) and the packet cannot be delivered to the destination
   without leaving the scope of the source address.

   If the reason for the failure to deliver can not be mapped to any of
   the specific codes listed above, the Code field is set to 3.  The
   example of such cases are inability to resolve the IPv6 destination
   address into a corresponding link address, or a link-specific problem
   of some sort.

   One specific case in which a Destination Unreachable message with a
   code 3 is sent is in response to a packet received by a router from a
   point-to-point link, destined to an address within a subnet assigned
   to that same link (other than one of the receiving router's own
   addresses).  In such a case, the packet MUST NOT be forwarded back
   onto the arrival link.

   A destination node SHOULD send a Destination Unreachable message with
   Code 4 in response to a packet for which the transport protocol
   (e.g., UDP) has no listener, if that transport protocol has no
   alternative means to inform the sender.

   If the reason for the failure to deliver is that packets with this
   source address is not allowed due to ingress filtering policies, the
   Code field is set to 5.

   If the reason for the failure to deliver is that the route to the
   destination is a reject route, the Code field is set to 6.  This may
   occur if the router has been configured to reject all the traffic for
   a specific prefix.

   Upper layer notification

   A node receiving the ICMPv6 Destination Unreachable message MUST
   notify the upper-layer process.
==============

Regards
Mukesh

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

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 30 Jan 2004 10:39:09 +0900 (JST)

> Here is the new text. I would appreciate everyone's 

	i'm not sure if code 6 (reject route to destintion) is useful.
	normally ISPs want to immitate "address unreachable" when they install
	reject route.  if what kind of case in which code 6 is useful?

itojun

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 29 Jan 2004 20:54:59 -0500

Isn't a reject route just a simple type of firewall/administrative
prohibition?  Likewise for ingress filtering?  

Is the intent to distinguish between "packet was dropped because
policy says packets from that source should be dropped" and "packet
was dropped because policy says that packets to that destination
should be dropped"?  

						- Bill

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 30 Jan 2004 12:39:51 +0100

Hi,

i have a question about code 5 error: would the ICMP error message contain
the suggested source address (or prefix that has to containe the source
address)

I mean, in the case that the packet is discarded becuase the source address
is not compatible with the ingress filtering, the router that discards the
packets probably knows which are the accepted prefixes, so it would be
interesting to use the message error to inform the host about the correct
prefix to use for this particular destination.

Have you considered something about this?

thanks, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En nombre de
> [email-masked]
> Enviado el: viernes, 30 de enero de 2004 2:31
> Para: [email-masked]
> Asunto: ICMPv6: New destination unreachable codes
>
>
> Hi,
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Jan 2004 16:35:22 +0200 (EET)

> prefix to use for this particular destination.

In general, the router does know the accepted prefixes, but the list 
might be even hundreds of prefixes long, not just one prefix.  

So, in general, embedding this information is not possible or 
feasible.  The case of just one accepted prefix is special.  Different 
question is whether it makes sense to add this information.  In any 
case it could not be stronger than a MAY (IMHO), so you couldn't 
depend anyone adding it, so you'd have to devise the other mechanisms 
anyway.

So, it seems a bit like adding the information is not worth the effort
for the special case.

-- 
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: "marcelo bagnulo" <[email-masked]>
Date: Fri, 30 Jan 2004 16:02:49 +0100

Hi Pekka,

I think i was too focussed in the site multihoming case :-)

However, in the particular case of multihoming, the accepted source prefix
is likely to be only one, i think. So in this case it would be useful to
include it to allow the host to discover the appropriate prefix to be
inlcuded in the source address.

So, for the multihoming case, this would be IMHO pretty useful and it would
worth the effort, i think.

I agree that a MAY would do it, so that exit routers at multihomed sites can
be configured to support this and hosts within the multihomed site are
upgraded to understand the message

regards, marcelo

> De: [email-masked] [mailto:[email-masked]]En nombre de Pekka
> Savola
> Enviado el: viernes, 30 de enero de 2004 15:35
> Para: marcelo bagnulo
> CC: [email-masked]; [email-masked]
> Asunto: RE: ICMPv6: New destination unreachable codes
>
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Jan 2004 17:13:09 +0200 (EET)

[..]
> upgraded to understand the message

But what do you do when the routers will NOT supply this message?  

In general, I think only few routers would report this, as it would
require an entirely new kind of logical "interface" between ingress
filtering and ICMP in the implementation (when generating the ICMP
message, look up the ingress filtering table in a new way, again) --
especially the products which do not generate these messages on
software would unlikely be upgraded.

Note that you have to add different code in the hosts for the major
case when this supplemental information is NOT supplied as well.  
This would be just an optimization, and an unnecessary one for a
dual-homed network (if it fails, just try the other address :), which
is probably (unless you subscribe to ohta-san's DFZ model :) the
common case.

So this would seem to be an optimization for the case that:

 - routers in fact do supply the information,
 - just one prefix is used per router,
 - the site/host is multihomed to at least 3 providers.

Is it really worth it? :-)

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 30 Jan 2004 16:52:35 +0100

> 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.

> software would unlikely be upgraded.

OTOH, which routers do you think that will send a ICMP error back to the
source?.
My understanding is that edge routers are likely to send this message but
core routers don't. So i don't expect that core routers will implement this
but it is not needed for the multihoming solution, since for this
multihoming solution to work, it only requires exit routers to support this.

the bottom line is that, if we end up building a solution that is optimized
with this message, i would expect that routers will implement it, becuase it
would be useful.

That is why, i think that a MAY would be OK

> is probably (unless you subscribe to ohta-san's DFZ model :) the

I fully agree with you.

But the major case (as you call it) would be addressed by simply picking a
random source address (different from the one included in the icmp error)

So this would be an optimiztion, but imho a powerful one in some cases.

For instance, consider a multihoming solution for medium size sites that
have multiple providers and that run bgp with their isps.

In this case, the internal routing system knows which path is available
towards the selected destination, but the source address may be incompatible
with the exit isp. In this case you need a mechanism to communicate the
correct source address to the the host. If multiple prefixes are available
at the site, the retrial process may be take a ling time. So this
optimization would enable a much better performance.

>  - routers in fact do supply the information,

As i mentioned, if this is part of your multihoming solution, i guess you
could assume this

>  - just one prefix is used per router,

Well, the site exit router can connect with more than one provider implying
more than one prefix, and there is no problem here, just choose one of the
accepted prefixes

>  - the site/host is multihomed to at least 3 providers.

Yes. While i agree that dual homing would be the most common case, i guess
that there will be lots of site that multihome to more than 2 isp, so it is
case that has to be considered also.

regards, marcelo