Subject: Re: [BEHAVE] comments on draft-bagnulo-behave-nat64-00

From: Cullen Jennings <[email-masked]>
Date: Sat, 12 Jul 2008 13:56:34 -0700

On Jun 25, 2008, at 4:38 AM, Magnus Westerlund wrote:

> Philip Matthews skrev:
>> Sorry to be late in commenting here. I just have a few additional  
>> comments.
>> On Fri, 13-Jun-08, at 15:30 , Dan Wing wrote:
>>> (as an individual)
>>>
>>> I have a few comments about the draft:
>>>
>>> * The draft currently only talks of UDP/TCP/ICMP.  It needs to also
>>> discuss, or at least have placeholeders for,
>>>   - IPSec ESP tunnel mode
>>>   - DCCP
>>>   - SCTP
>> Very few NATs today support DCCP or SCTP. In my personal opinion,  
>> the right way to support these protocols is to carry them over UDP.
>
> Well, you are talking about placing a NAT in a new architectural  
> location compared to where NAT44 classically has existed. Not  
> natively supporting SCTP and DCCP seems a direct action to declaring  
> them impossible to go forward with.
>
> I am not buying that the new waist of the internet is only UDP.  
> Especially not in a case where we are actually talking about  
> something that is being designed. Even NAT-PT has very marginal  
> deployment so there are little legacy reason for us to taking short- 
> cuts.
>
> Cheers

I'm trying not to step into the middle of the should DCCP (or SCTP)  
run over UDP debate but regardless of what side of the issue you are  
on, I think that what we do for nat64 and the deployment of NAT-PT is  
not really the relevant issues.

The relevant issues is the deployment of residential v4 to v4 nats at  
peoples home and personal software based firewalls. Anyone building an  
application that connects to end users today would be nuts to run it  
over DCCP (or SCTP)  without a fallback to UDP or TCP because it would  
fail a larger percentage of the time. Because there are no  
applications that use DCCP, there is zero incentive for the  
residential NAT vendors to include support for it.

One possible solution to this for any new transport is that it starts  
up over UDP and they tries to negotiate an "optimized" version over  
IP. This allows applications to start using it before NAT support it.  
It then provides an incentive for NAT vendors to implement it so they  
have a competitive differentiator that certain applications run more  
efficiently on their NATs.

Initially the DCCP WG decided to go for the over IP route. The  
questions to me is at what point in time would you decide that plan  
was not working and consider alternative paths. The truth is even if  
all the incentives are exactly right, it takes a long time for a new  
transport protocol to have any widespread support. Look how long it  
took HTTP to become a transport :-)

Cullen <in my individual contributor role>

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave