Subject: [BEHAVE] Single-Purpose NATs, Multi-Purpose NATs, and NAT-related standards

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Jan 2014 08:43:45 -0500

I am trying to work through the issue of how general a NAT the SYSLOG 
logging document should provide for. This also affects the MIB (and 
IPFIX) documents, since we are trying to keep them synchronized.

The issue seems to come to a head when considering the question of 
address pools. The MIB shows the following:

1. An address pool can only belong to one realm. See natPoolRealm in the 
natPoolTable.

2. A subscriber is mapped to only one address pool. See 
natSubscriberPool in natSubscribersTable.

Between these two restrictions, we have the following implication: a 
given subscriber can have sessions with only one external realm at a 
time (that is, only one realm external to the realm in which the 
subscriber lies).

I can think of use cases where this makes for a viable product:

-- traditional NAT44 where everything goes between one internal realm 
and the rest of the world in the other. NAT64 or NAT46 are similar cases.

-- DS-Lite AFTR, where the DS-Lite subscribers are the internal realm 
and the global IPv4 network is the external realm.

On the other hand, I see use cases where the subscriber will want to 
connect to multiple realms, each having its own address pool by 
necessity because it has its own numbering space:

-- NAT4x or NAT6x, connecting single-stack subscribers to both the IPv4 
and IPv6 external world.

-- a NAT serving multiple enterprises, each having its own realm with 
overlapping numbering space, distinguished by ingress interface 
identifiers, where the enterprises want to communicate with each other 
as well as the outside world.

The question is whether the MIB and logging documents should be able to 
handle these more general cases. If so, it has to be possible for a 
subscriber to be mapped into more than one address pool at once.

Comments?

Tom Taylor

---

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Jan 2014 09:35:07 -0500

> 1. An address pool can only belong to one realm. See natPoolRealm in the

I can't imagine an address pool belonging to multiple realms.

I could imagine a "set of pools" kind of thing that would simply be an 
enumeration of pools. But I don't see a use case of it (see below).

> as well as the outside world.

Another use case: when accessing ISP internal services (e.g. video on 
demand), a different external realm would be used, and therefore a 
different pool as well.

> subscriber to be mapped into more than one address pool at once.

We have to be extremely careful with language here.

Let's go back to the MIB definition:

    natSubscriberPool OBJECT-TYPE
        SYNTAX Unsigned32 (0|1..4294967295)
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "External address pool to which this subscriber belongs, or
             zero if the subscriber does not belong to any pool."
        ::= { natSubscribersEntry 7 }

The word "belong" has been very carefully chosen. Its meaning is 
undefined in IETF documents as far as I know. Therefore it would be up 
to a particular implementation to define what "belong" means.

A subscriber "belonging" to one particular pool does not preclude NAT 
mappings existing or being created for this subscriber with an external 
address taken from a pool different from the one to which the subscriber 
belongs.

The usefulness of natSubscriberPool resides in the fact that fact that 
an implementation may maintain in its state memory an explicit 
association between subscriber and pool. This piece of NAT state can 
thus be reported through natSubscriberPool. New mappings would usually 
be allocated from that pool, but on edge conditions an implementation 
could decide to do weird things like borrow ports from a different pool, 
switch a subscriber's pool, change a pool's definition, or whatever else.

So I see two viable options:

1. Remove natSubscriberPool.

2. Keep natSubscriberPool and add text saying that:
- "belong" is undefined.
- Mappings for this subscriber may exist or even be created with 
external addresses taken from a different pool.
- The value zero can also mean that a subscriber belongs to multiple pools.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Jan 2014 15:06:46 -0500

> I can't imagine an address pool belonging to multiple realms.

[PTT] I had no intention of questioning this one.

> - The value zero can also mean that a subscriber belongs to multiple pools.

[PTT] I'd go for (1) removing natSubscriberPool. Any default is an 
implementation issue.

Tom

---

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Jan 2014 15:15:38 -0500

> [PTT] I'd go for (1) removing natSubscriberPool. Any default is an

Consider it done.

Thanks,
Simon