Re: Last Call: RFC 6346 successful: moving to Proposed Standard

[🔓Dan Wing <[e-mail]>]

On Dec 13, 2014, at 12:09 PM, Christian Huitema <[e-mail]> wrote:

> On Friday, December 12, 2014 3:26 PM, Douglas Otis wrote
> 
>> On Dec 12, 2014, at 11:32 AM, Brian E Carpenter <[e-mail]> wrote:
>> 
>>> On 12/12/2014 18:12, heasley wrote:
>>> ...
>>>> I don't know anyone enchanted by v6.
>>> 
>>> Strange choice of word. I'm not in the least enchanted by IPv4
>>> or by NAT44 either. I just know as a matter of fact that the
>>> IPv4nternet ran out of addresses a while back and we have no
>>> alternative but to fix it using IPv6. All the rest is details,
>>> important details of course, but details.
>> 
>> Dear Brian,
>> 
>> Agreed.  One should not support the standardization of a v6 to v4 transitional scheme which significantly weakens
>> protocol security by restricting available port assignments at various points within a path.  Suggested bit ranges of
>> 7 to 10 bits significantly reduces protections otherwise obtained by random assignment.  As such, it makes this a 
>> trivial matter for malefactors to deduce likely source entropies.  Although IPv6 creates different challenges, it
>> provides the only viable long term standard moving forward.  In addition, NAT keep-alives tend to consume critical > mobile energy resources.
> 
> It would be interesting to study the effect of this port range assignment on applications. For example, a lot of the NAT traversal solutions rely on reserving ports for applications using UPNP IGD, PCP, or the management UI from the NAT.

I agree UPnP IGD will break.  But PCP should be fine, as it sends a suggested-port in its request and the response can be any port, http://tools.ietf.org/html/rfc6887#page-41.  The UI from the (in-home?) NAT should be okay, as it needs to be A+P aware, and as part of that awareness it would know the assigned port numbers.  If the UI belongs to the carrier's A+P device itself, it also knows the assigned port numbers.

-d

> That's clearly going to break if the target port falls outside the range assigned to the NAT. But the applications have no official way to learn the range. The applications will thus have to implement ever more NAT traversal cleverness. So, this is by no means a harmless hack. It will have implications on a range of end systems. Personally, I don't see any urgency from changing the status away from experimental.
> 
> -- Christian Huitema
> 
> 
> 
>