Subject: RE: ICMPv6: New destination unreachable codes

From: [email-masked]
Date: Thu, 29 Jan 2004 20:21:56 -0600

Reject Route case is a specific case of the more general 
"administrative prohibition".

The administrative prohibition case might include other reasons
like "source not allowed", "destination not allowed", "protocol 
not allowed", "port not allowed", "in-secure packets not allowed",
etc.

Second paragraph of section 6.0 in draft 
draft-ietf-ipv6-unique-local-addr-02.txt talks about a black hole 
route for Local IPv6 prefix FC00::/7 and an appropriate ICMPv6
destination unreachable message. The new code "reject route to
destination" is supposed to fulfill that need.

I changed the name to "reject route" from "black hole route"
because a "black hole route", as per the name, should drop the 
packet silently without notifying the sender.

Regards
Mukesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 29, 2004 5:55 PM
> To: Gupta Mukesh (Nokia-NET/MtView)
> Cc: [email-masked]
> Subject: Re: ICMPv6: New destination unreachable codes 
> 
> 
>    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 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.
> 
> 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
> 

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

---

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

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

I understand that adding a new option is much harder than adding a new
code point. I am fine with the new code point.

> On Fri, 30 Jan 2004, Christian Huitema wrote:
> > 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.
> 
> 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).

If the site is multi-addressed, the exit router link may or may not be
multi-addressed. If it is not, then the global scope address probably
matches the egress that the router is managing, and that is fine. If the
router link happens to be multi-addressed, then it would be nice to pick
the address that is most likely to match filtering.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 30 Jan 2004 13:51:54 -0800

> If I am not wrong, if we wanted the router to send the correct
> prefix to the host in the ICMP message, we will have to change
> the format of the ICMPv6 Destination Unreachable message.
> 
> Currently, we just have 4 bytes unused in the message format and
> this prefix can't fit in there.
> 
> So the question is: is it worth changing the format of the message
> for this optimization ??

Probably not. Having the proper code is a really nice first step.

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Fri, 30 Jan 2004 16:54:24 -0800

Christian,

>Probably not. Having the proper code is a really nice first step.

I agree.

To respond to some of the other discussion, the purpose of the new codes 
was to provide more feedback to address selection.  As I think Pekka said 
in an earlier discussion, relying on transport layer timeouts to get this 
feedback is not a good idea.

I think for all of the new destination unreachable codes, if the source 
node has only a few addresses to choose from this feedback will very useful 
as there won't be many alternatives to try.  If the source node has many 
addresses to try, then it is less beneficial.  However, I don't think the 
latter is likely to be the case in common practice.

Overall I think that providing this additional feedback is useful and I 
don't think it does any harm.  The ICMP destination unreachable messages 
are a SHOULD so the router has considerable choice if it wants to send them 
or not.

Bob

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 31 Jan 2004 13:03:49 -0800

> But this is just an operational procedure, which needs to be stated in
> the multihoming solution documents, but something that IMHO must not
> be added to the ICMPv6 spec, as it's really out of scope from ICMP
> perspective.

I agree with Pekka. The purpose of the ICMPv6 document is to reserve the
code and define the format. As Marcelo said, the MH code can work with
this code and format. Let's just go with it.

I understand Marcelo's concern. He (and I) would like to make life as
good as possible for hosts in multi-homed sites. This will require
operational rules for hosts and for routers. As I mentioned in a
previous message, the code definition is a nice first step. It tells the
host that it should try another source address. It is only a first step,
because it does not tell which one. The host will have to use some
heuristic. In some cases, e.g. when there are just two addresses, the
heuristic is trivial. In more complex cases, having more information
might help. But it may be a bit early to determine how this information
should be passed. We could pass it in ICMP messages, but we could just
as well use a yet-to-be-defined information protocol associating exit
routers with allowed prefixes, or even let hosts use some cached
knowledge from previous connections. Given the wide choices, I would
rather not try to mess around with the ICMPv6 specification.

-- Christian Huitema