Subject: [BEHAVE] Port overloading

From: Cameron Byrne <[email-masked]>
Date: Fri, 9 Mar 2012 07:30:10 -0800

RFC 4787 says one must not use port overloading, can someone briefly
expound on why?

I assume it is so that STUN and now PCP may work with end point independent
mapping , but in many cases STUN does not work because endpoint dependent
mapping (symmetric Nat) is used,.... always been used in some places.... no
need to change. This is my case.

But we are getting into a state on the internet where port overloading will
be required to allow NAT session creation to exceed 64k ports and thus
providing substantial utility to those  that are already on the CGN path
but find that they do not have enough ipv4 addresses to feed the CGN in
order to keep up with increasing ipv4 session demand, including session
growth from NAT64.

Commercial implementation for breaking the 64k port barrier with
overloading  already exists with the explicit purpose of extending the
efficiency of ipv4 pools in CGN and nat64.

If I already have symmetric nat, is port overloading going to break more
things?

This is also relevant to the discussion of fixed port solutions like MAP vs
dynamic solutions like NAT64 and 464XLAT.

Cb

---

From: ssenthil <[email-masked]>
Date: Fri, 09 Mar 2012 13:37:04 -0500

If you already have a symmetric NAT, you probably wont lose much by doing
port overloading. But if you are making your NATs application friendly and
wanting to support P2P apps, then port overloading is bad. I recently wrote
a draft on the harmful effects of EDM and port overloading
http://www.ietf.org/internet-drafts/draft-sivakumar-behave-edm-harmful-00.tx
t

Thanks
Senthil

On 3/9/12 10:30 AM, "Cameron Byrne" <[email-masked]> wrote:

> RFC 4787 says one must not use port overloading, can someone briefly expound
> on why?
> 
> But we are getting into a state on the internet where port overloading will be
> required to allow NAT session creation to exceed 64k ports and thus providing
> substantial utility to those  that are already on the CGN path but find that
> they do not have enough ipv4 addresses to feed the CGN in order to keep up
> with increasing ipv4 session demand, including session growth from NAT64.
> 
> Commercial implementation for breaking the 64k port barrier with overloading 
> already exists with the explicit purpose of extending the efficiency of ipv4
> pools in CGN and nat64.
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 9 Mar 2012 10:45:16 -0800

On Fri, Mar 9, 2012 at 10:37 AM, ssenthil <[email-masked]> wrote:
> http://www.ietf.org/internet-drafts/draft-sivakumar-behave-edm-harmful-00.txt
>

Great, i think you answer my question and i will review the draft as well.

I would like to underscore that APNIC is already out of addresses, and
soon RIPE will go into their end run mode where the max allocation is
/22.  A /22 cannot support a very large EIM CGN, so EDM and port
overloading are an obvious solutions that CGN / NAT64 operators will
have no choice but to accept port overload to extend the limited IPv4
space beyond 64k sessions per IPv4.

Application friendly NATs are a day late and dollar short IMHO, as the
saying goes.  IPv4 will be continued to be watered down.  For my
customers and application developers, i suggest they use IPv6 if
symmetric NAT does not work out for them

CB
> providing substantial utility to those  that are already on the CGN path but
> find that they do not have enough ipv4 addresses to feed the CGN in order to
> keep up with increasing ipv4 session demand, including session growth from
> NAT64.
>
> ________________________________