Jen Linkova <furr...@gmail.com> wrote:
>> However, following several discussions and [1] , there's interest in
>> developing a more generic approach. I am hopping the Internet Draft would
>> define a more detailed payload, similar to how ICMP defines packet
payload
>> in RFC 792.
> Then it probably should be an ICMPv6 packet encapsulated into ESP.
> Is there any reason we can't just use an existing SPI to send ICMPv6
packets?
> Off-top of my head:
> - what source/dst addresses to use,
> - it could be a problem if the peer's configuration doesn't allow pings.
The "more generic approach" is actually way way way more complex for the
reasons cited above.
Secondly, the "more generic approach" has really nothing in common with the
ESP-ping mechanism, and there is really no overlap. I have no problem with
developing a *second* approach, because I think that they solve different
aspects of the diagnostic problem.
The two points above (src/dst to use, whether or not policy allows) need to
be solved with some amount of IKEv2 level negotiation and/or Notify.
While the whole point of the SPI7/8 mechanism is that it can be operated
completely without IKEv2 involved at all.
I would prefer to adopt this document to solve the primitive diagnostic
problem. There are a number of problems/challenges in the currenct solution
which I think that the WG can address, once we agree on the problem we are
trying to solve.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
