Subject: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling

From: Simon Perreault <[email-masked]>
Date: Sat, 14 Nov 2009 16:27:56 -0500

Hello,

The endpoint-independent mapping behaviour is good for NAT traversal, 
but limits the number of sessions to 65535 per IPv4 address in the pool. 
This limit is low, when also considering the fact that sessions may 
still be active for a relatively long time until they time out.

Since we have the option of doing address-dependent filtering, couldn't 
we also at the same time opt for address-dependent mapping? It would let 
us overload IPv4 source ports for different IPv4 destination addresses, 
which would greatly increase the scalability of the NAT in some common 
situations. I think it would have the same NAT traversability as what we 
already have with address-dependent filtering (am I right?).

I understand this would change a lot of text but I think the scalability 
potential warrants this change. I am willing to contribute text if this 
proposal is received positively.

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Simon Perreault <[email-masked]>
Date: Tue, 17 Nov 2009 14:41:22 -0500

Simon Perreault wrote, on 2009-11-14 16:27:
> we also at the same time opt for address-dependent mapping? [...]
> I think it would have the same NAT traversability as what we

I just realized I was completely wrong. Please ignore my proposal.

(Although the scaling problem remains...)

Simon

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Nov 2009 15:27:45 +0100

Hi Simon,

I think for that address dependent mapping may work if one restrict it
to cases where it is known that there is a strict client server protocol
on the port. I think the most gain for the least hassle would be to
allow address dependent mappings for flows that has destination that
matches TCP.port=80 or TCP.port=443. I don't know how that would affect
the more esoteric usages of HTTP.

But, in general it is difficult to know what application that runs on
top of the transport protocol and what its need is. Thus this should be
done with significant care. I would recommend a minimal set of
identified applications where an operator may chose this option to
achieve a bit better address re-use.

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Nov 2009 09:57:08 -0500

> the more esoteric usages of HTTP.

Something similar to this was proposed by Rémi Després on 2008-05-22 with the
name "Address-port sparing NATs".

I would agree that this is a useful optimization.

> achieve a bit better address re-use.

Agreed.

Rémi Després suggested HTTP, HTTPS, DNS, POP3, IMAP, SNMP.

I suggest that this list be interpreted as guidance for operators, as in e.g.
"these protocols fine with adddress and port-dependent mappnig." Ultimately this
is an operational issue and we can only provide guidance.

However, address and port-dependent mapping is implemented completely
differently than what is described in the current draft. For instance, there is
no longer a need for separate binding and session tables. So I would like to
hear from authors what they think of this suggestion, and if they'd like me to
provide text.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Nov 2009 10:38:49 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Thursday, November 26, 2009 6:57 AM
> To: Magnus Westerlund
> Cc: [email-masked]
> Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling
> 

This sort of optimization feels like an informational/experimental-track
document and can be separate from draft-ietf-behave-v6v4-xlate-stateful.

-d

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