Re: [tsvwg] question about draft-ietf-tsvwg-natsupp

[Michael Tuexen <[e-mail]>]

> On 08 Jul 2015, at 19:35, George, Wes <[e-mail]> wrote:
> 
> Hi - 
> 
> First- please include my address in any replies, I am not subscribed to the tsvwg mailing list, I saw the draft go past in the newly-published drafts RSS feed, and it caught my attention.
> 
> I'm raising this concern now so that you don't get broadsided by it when it gets raised at IETF LC.
Hi Wes,

I'm glad you raise it now.
> 
> It's the middle of 2015: All RIRs but AFRINIC are at or near the last phase of their IPv4 exhaustion plans, IPv6 usage is in the double-digit percent to many major destinations, and it's common knowledge that one of NAT's many flaws is that it breaks things. 
> 
> I think that given that set of facts, this draft needs to answer the following questions:
> Why are we still working on hacking new features into IPv4?
To be honest: Because we haven't finished it earlier...
> Why can't this draft be distilled to, "SCTP does not work through NAT, use IPv6 (or 6951) if you want to use SCTP"?
Wouldn't this be more precisely:
SCTP doesn't work through NAT, use it either end-to-end or use RFC 6951.
It doesn't matter if it is IPv4 or IPv6. An IPv6 NAT would break the same way. 
> Is there some specific problem unique to IPv4 that is solved by SCTP such that it is necessary to make SCTP work for IPv4 + NAT rather than simply acknowledging that it doesn't work and recommending IPv6? 
No. The same methods would apply to any kind of NAT. You just replace one address by another.
> Are any operators actually asking for support of this feature in their NAT? Any benefit to them/incentive to deploy?
I have no concrete data on that. FreeBSD's NAT has the support build in. I got a question regarding SCTP NAT and
the document shift from BEHAVE to TSVWG from a Linux vendor. But I don't know if they want to implement it or
when.
> If we're going to ask vendors to spend development cycles implementing new features into legacy devices, shouldn't it be to support IPv6, rather than to keep IPv4 on life support? How do you reconcile this with RFC6540's guidance?
Good question. Maybe something to discuss at the WG meeting...
> 
> Having said all of that, I appreciate the work that went into this, and realize that the effort started 5 years ago when the IPv6 deployment picture was significantly different, so I hesitate to outright call for this draft to be abandoned as overtaken by events, but the longer out in time it goes, the higher the burden of proof to explain why work is continuing on this effort, especially as an IETF consensus document.
> Alternatively, could the scope of the draft be limited so that it focuses on making SCTP work in IPv6-based IPv4 sharing protocols (e.g. NAT64/DSLite/MAP/464xlat) instead of generic NAT44/NAPT? Even if the implementation is largely the same for both types of NAT, limiting it in the draft so that the focus is on IPv6 sends the right message.
The implementation would be the same. I think we sticked to IPv4 for simplicity...

Any other opinions?

Best regards
Michael
> 
> Thanks,
>  
> Wesley George
> 
> Anything below this line has been added by my company’s mail server, I have no control over it.
> -----------
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.