D]
> CC: [EMAIL PROTECTED]
> Asunto: RE: ICMPv6: New destination unreachable codes
>
>
> I agree with Christian and Pekka here.
>
> So I think, we mostly agree upon the text that I had sent out
> and I don't have to make any changes to that.
>
> > -
> > 5 - source address failed ingress policy
> [...]
> >
> >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.
>
> One minor comment here: this co
On Thu, 29 Jan 2004 [EMAIL PROTECTED] wrote:
> 5 - source address failed ingress policy
[...]
>
>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.
One mino
To: Pekka Savola; marcelo bagnulo
> Cc: Gupta Mukesh (Nokia-NET/MtView); [EMAIL PROTECTED]
> Subject: RE: ICMPv6: New destination unreachable codes
>
>
> > But this is just an operational procedure, which needs to
> be stated in
> > the multihoming solution documents, b
Hi Christian,
I agree, Desination Unreachable is not
the right place to put this information.
I'll explain further below.
Christian Huitema wrote:
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
> 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 t
On Sat, 31 Jan 2004, marcelo bagnulo wrote:
> I think that Christian's proposal doesn't change the packet format, since
> the router just has to be smart enough to pick the right source address.
>
> So all that it is needed is to state that the router has to pick one of its
> own addresses that it
MAIL PROTECTED]
> > Sent: Friday, January 30, 2004 12:09 PM
> > To: Pekka Savola
> > Cc: [EMAIL PROTECTED]; Gupta Mukesh (Nokia-NET/MtView);
> > [EMAIL PROTECTED]
> > Subject: RE: ICMPv6: New destination unreachable codes
> >
> >
> > > FWIW, I have no
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
> 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.
>
>
sh (Nokia-NET/MtView);
> [EMAIL PROTECTED]
> Subject: RE: ICMPv6: New destination unreachable codes
>
>
> > 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
> 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:
FWIW, I have no objection to specifying a new code, but I don't think
adding a "working address" option is feasible or useful.
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 exi
> 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
> > 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,
> 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 ma
On Fri, 30 Jan 2004, marcelo bagnulo wrote:
[..]
> 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
But what do you do when the routers will NOT supply this mes
the message
regards, marcelo
> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Pekka
> Savola
> Enviado el: viernes, 30 de enero de 2004 15:35
> Para: marcelo bagnulo
> CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Asunto: RE: IC
On Fri, 30 Jan 2004, marcelo bagnulo wrote:
> 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 me
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
; From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 29, 2004 5:55 PM
> To: Gupta Mukesh (Nokia-NET/MtView)
> Cc: [EMAIL PROTECTED]
> Subject: Re: ICMPv6: New destination unreachable codes
>
>
>If the reason for the failure to deliver is administr
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
> 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
>
23 matches
Mail list logo
