Panwei (William) wrote:
>> I'm not sure I understand how you get this from the Problem
>> Statement.
>> Clearly, we need to clarify the purpose.
>> It's not about detecting NAT, it's about determining if ESP will work or
>> not.
>> It's not about detecting or avoiding *NAT
Thanks for your and Michael’s clarifications. I’m much clearer now and I’m
convinced this is an useful draft.
I think it would be useful to add one or two sentences in the introduction. An
example is given below.
However, because ESP packets do not share fate with IKE packets, it
is possib
Hi Michael,
Thanks for your clarification. I'm much clearer about the problems now.
> > When you find out that the IKEv2 negotiation succeeds but ESP
> > traffic can't get through, what more information will you get
> > from sending the ESPping and not receiving a response?
>
On Wed, 27 Mar 2024, Panwei (William) wrote:
Thanks for your clarification. I'm much clearer about the problems now.
> > When you find out that the IKEv2 negotiation succeeds but ESP
> > traffic can't get through, what more information will you get
> > from sending the ESPping and not
Hi,
On Wed, Mar 27, 2024, at 8:24 PM, Panwei (William) wrote:
> Thanks for your and Michael’s clarifications. I’m much clearer now and I’m
> convinced this is an useful draft.
> I think it would be useful to add one or two sentences in the introduction.
> An example is given below.
>
>Howe
Paul Wouters wrote:
>> If you want to do the traceroute to determine how far ESP actually
>> gets, you need to make sure every node supports the ESPping.
> I think people meant to extend traceroute to use an ESP packet instead
> of an ICMP or UDP packet. The machines in the middl
Panwei (William) wrote:
> If you want to do the traceroute to determine how far ESP actually
> gets, you need to make sure every node supports the ESPping.
No, only the final machine.
Others would respond with ICMP unreachable when TTL=0
--
Michael Richardson , Sandelman Software Works
