> Allowing the application to choose runs into connectivity problems > when some applications support the UDP encapsulation, and some do > not. If we're going to define a UDP encapsulation - and it's not at > all clear to me that such a thing is a good idea - In the dark ages, IPsec ESP could not be used if you were behind a NAT. In 2001, IETF began standardizing IPsec-over-UDP [draft-ietf-ipsec-udp-encaps-00]. At roughly the same time, several NAT vendors started shipping equipment with "IPsec Passthru" support. In 2000, IPsec was the most popular way to connect to corporate networks, and NATs were being installed at a rapid pace. Many IPsec implementations added support for IPsec-over-UDP. To this day, IPsec-over-UDP (and IPsec-over-TCP, to a lesser degree) are sometimes necessary to establish an IPsec connection. This means that something along the path -- often a NAT -- is interfering with IKE and/or IPsec. I don't know if DCCP will encounter a greater or lesser success and IPsec (and thus will have more or fewer NATs with native DCCP support). But, like the need to still have IPsec-over-UDP on many networks, DCCP will need a fallback to a NAT-friendly protocol or DCCP won't work. I expect DCCP-over-UDP is a more appealing fallback than TCP, but I think those are the only two choices. -d > then I'd > recommend > that we do so in a way that it can be done by the DCCP stack, > transparently to the applications, with a well-defined order for > trying native vs. encapsulated connection requests. > > -- > Colin Perkins > http://csperkins.org/ > >
