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

["George, Wes" <[e-mail]>]

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.

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?
Why can't this draft be distilled to, "SCTP does not work through NAT, use IPv6 (or 6951) if you want to use SCTP"?
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?
Are any operators actually asking for support of this feature in their NAT? Any benefit to them/incentive to deploy?
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?

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.

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.