On Feb 16, 2012, at 4:43 PM, Paul Wouters wrote: > On Thu, 16 Feb 2012, Yoav Nir wrote: > >>> Are you really telling me they are using a private numbers from the >>> internet draft that expired more than 10 years ago, and which is not >>> compatible with the RFC3947 (which (which was published January 2005, >>> i.e. 7 years ago). >> >> They don't always do that. But looking at their MainMode packet 1 in >> wireshark, They send the following VIDs: >> - RFC 3947 Negotiation of the NAT-Traversal in the IKE >> - draft-ietf-ipsec-nat-t-ike >> - draft-ietf-ipsec-nat-t-ike-08 >> - draft-ietf-ipsec-nat-t-ike-07 >> - draft-ietf-ipsec-nat-t-ike-06 >> - draft-ietf-ipsec-nat-t-ike-05 >> - draft-ietf-ipsec-nat-t-ike-04 >> - draft-ietf-ipsec-nat-t-ike-03 >> - draft-ietf-ipsec-nat-t-ike-02 >> - draft-ietf-ipsec-nat-t-ike-02\n >> - RFC 3706 DPD (Dead Peer Detection) >> >> I guess what they later do depends on what VID they get in the reply. There >> were quite a few versions of Windows server that returned 90cb80…427b1f >> (draft-ietf-ipsec-nat-t-ike-02\n), so maybe Paul's implementation was a >> surprise for iOS. > > I'll make sure this is not an implementation issue on our side. > > Did any large deployment switch to removing all the draft VIDs? If so, > how many problems did that cause? I'd be happy to remove the ancient > drat cruft, especially if it increases interoperability.
Our implementation supports the RFC and "draft-02\n", which is what Microsoft clients added in some service pack of XP. We reply according to the last recognized NAT-T VID, which in this case is the draft-02\n one. When we do this, we don't get any weird encapsulation modes like you do. Do you reply with the RFC one? Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
