Stephen writes:
>I'm not an IPv6 expert, but it seems that the issue here is who emits the message,
>not just what ICMP >message is being emitted.
>An IPsec implementation (gateway or host) has an ability to bypass control traffic
>that it emits, >irrespective of SPD contents.
So, I would expec
Jari,
Stephen Kent wrote:
> > * Path MTU discovery. Consider the following case:
> >
> > (N1)(VPNGW1)(R1)(VPNGW2)-(R2)(N2)
> >
> > Assume N1 wants to send traffic to N2, part of the path
> > goes through an insecure network part, secured using
>
> > which in turn would prevent all communications. Also, as per RFC
> > 2401 we do not in general have the possibility to specify policies
> > for individual ICMP message types.
>
> This passed the IESG in RFC 2894 (so it must be true):
>
>
>Note that for the SPD to distinguish Router Renu
> which in turn would prevent all communications. Also, as per RFC
> 2401 we do not in general have the possibility to specify policies
> for individual ICMP message types.
This passed the IESG in RFC 2894 (so it must be true):
Note that for the SPD to distinguish Router Renumbering from oth
Stephen Kent wrote:
> > * Path MTU discovery. Consider the following case:
> >
> > (N1)(VPNGW1)(R1)(VPNGW2)-(R2)(N2)
> >
> > Assume N1 wants to send traffic to N2, part of the path
> > goes through an insecure network part, secured using
> >
In your previous mail you wrote:
I'm wondering if there are any documents that specify rules regarding the
use of IPsec in the context of IPv6 Neighbor Solicitations and possibly
other ICMPv6 messages.
=> there was a nice presentation by Dan McDonald at a previous IETF about
this (A
I'm wondering if there are any documents that specify rules regarding the
use of IPsec in the context of IPv6 Neighbor Solicitations and possibly
other ICMPv6 messages.
As defined by http://www.ietf.org/rfc/rfc2461.txt, and
http://www.ietf.org/rfc/rfc2462.txt
such IPv6 messages are needed to pe
