Panwei (William) <william.pan...@huawei.com> wrote:
    > I feel that the problem of IPv6 ESP traverse failure, as described in
    > the draft and presentation slides, is because of NAT. IKEv2 already

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.

    > supports the detection of NAT. After the detection of NAT, the peers
    > can use IP + UDP (4500) + ESP to traverse the NAT. Are there some use
    > cases that this existing solution doesn't work and this draft tries to
    > solve? Or, are there some use cases that IKEv2 fails in detecting the
    > existence of NAT?

It's not about detecting or avoiding *NAT* per-se.
We prefer not to have to encapsulate.

I think that you are over-estimating the competency of some operators: the
experience with IPv6 is often not there.   Even when it is, not all equipment
vendors are equally competent at implementing/documenting things.

Imagine a situation where IPsec will be used in a (sub)site to site
configuration.  For instance, between a billing system and an outsourced
credit card processor. {Not replacing TLS, but in addition to}
The administrators of the billing system request "IPsec" from their (inhouse)
network operator, and the operator looks up their howto list, and enables UDP
port 500 and 4500, because that's what IPv4 wanted.
Now the billing system people wonder why the it seems to work, but in fact no
traffic gets through.  It can be very hard to debug.

The purpose of this protocol is to allow that debugging.
The network operator people, who are not allowed into the billing system, can
instead use an ESPping utility to send ESP traffic, adjusting their firewalls
until they understand that UDP!=ESP.

We also realized that one can write/modify traceroute to use ESPping to
determine how far ESP actually gets.

There are also situations where there are ECMP routers in the way which
simply do not know what to do with ESP.  A network operator could introduce
such a sytem into a previously working site-to-site VPN and suddenly things
stop working, or get poor performance.

--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*



Attachment: signature.asc
Description: PGP signature

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to