Subject: Re: [Int-area] mic comments on draft-matsushima-v6ops-transition-experience

From: Wojciech Dec <[email-masked]>
Date: Tue, 29 Mar 2011 17:27:44 +0200

Replying to Dan's statement inline

---snip---

Logging
-------
It is simplistic to say "stateless needs no logging; stateful needs
logging".  It is a continuum from completely random ports to completely
fixed ports.  I described this in February on the BEHAVE list in
http://www.ietf.org/mail-archive/web/behave/current/msg09182.html, where I
wrote:

There is a range of things a CGN can do:

   1. for every outgoing connection, create one mapping.  This is what
      most people mean by "stateful NAT".
   2. for an outgoing connection, create a "bin" of several mappings
      using random public ports.  Subsequent outgoing connections will
      use ports from the "bin".  When the "bin" is full, a new
      connection causes a new bin to be created.  A bin is smaller or
      equal to the user's maximum port limit.  This is what all
      stateless mechanisms do.
   3. Same as (2), but the ports allocated to a "bin" are consecutive
      public ports.

The problem is that a CGN can be implemented, or configured, to do (1) or
(2).  Thus, a CGN can have the exact same logging characteristics that are
being attributed to stateless solutions.

---snip---
The point of draft matsushima is IMO different, as is the basic
requirement that operators interested in a stateless 4V6 solution are
considering: With the stateless 4V6, the operator has no logging of
any kind to do to "capture the NAT assignment", beyond the IPv6
address assignment which is something that they will be doing
irrespective. Hence, while a CGN can be set-up to do 1,2 or 3, it will
still generate extra logs (ie require extra stuff to be integrated,
accounted, etc) over and above a 4V6 system.

Regards,
Wojtek.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Mar 2011 17:45:18 +0200

> -----Original Message-----
> From: Wojciech Dec [mailto:[email-masked]]
> Sent: Tuesday, March 29, 2011 5:28 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Int-area] mic comments on draft-matsushima-v6ops-
> transition-experience
> 

The translation can be completely static, so that no logging is necessary.

-d

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Mar 2011 08:37:18 +0200

> The translation can be completely static, so that no logging is necessary.

Is it not true, then, that the better multiplexing ratio disappears (while it is often presented as the main advantage of ISP's running the NATs instead of CPE's)?

RD

> 
> -d
> 
> 
>> Regards,
>> Wojtek.
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 30 Mar 2011 09:48:22 +0200

> Is it not true, then, that the better multiplexing ratio disappears (while it is often presented as the main advantage of ISP's running the NATs instead of CPE's)?

The static translation: Wouldn't that result in per
end-point/subscriber configuration on the NAT device?

Rgds,
Wojtek.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 Mar 2011 10:15:58 +0200

> Sent: Wednesday, March 30, 2011 9:48 AM
> To: Rémi Després
> Cc: Dan Wing; [email-masked]
> > Is it not true, then, that the better multiplexing ratio disappears
> (while it is often presented as the main advantage of ISP's running the
> NATs instead of CPE's)?
> 

A NAT can also do a static mapping that internal IP address 

  internal 10.1.1.1 is mapped to public ports 100-199
  internal 10.1.1.2 is mapped to public ports 200-299
  internal 10.1.1.3 is mapped to public ports 300-399

Which could be done in a single configuration line.  This is an
algorithmic transformation common to all subscribers, with 
per-connection state on the NAPT.  If, in the future, fewer 
or more ports need to be allocated to the users, it's a 
single configuration change in a single device.

If there are some users who need fewer or more ports, there are
two approaches (1) give them a different IP address, so that (for 
EXAMPLE), users with 10.2/16 would get 500 ports, users with 
10.3/16 get 5000 ports.  This approach is similar to that 
described in dIVI, 4rd, and other A+P-like approaches.  Or 
(2) leave the subscriber's IP address the same, and add a 
NAT configuration setting for the exceptional subscribers 
(e.g., 10.9.1.1 gets 65535 ports, 10.9.1.2 gets 25 ports,
and everyone else (10/8) gets 100 ports).

But IETF and BEHAVE have not been involved in how NAT devices do 
their mapping.  It's entirely up to the implementer.  There is 
nothing intrinsic in NAT technology that prevents a NAT implementer 
from doing what I describe above.

-d

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 30 Mar 2011 10:31:23 +0200

I agree to the static NAT applicability here. 

Of course, such usage has been historically minimal given the extraneous overhead associated with changing the NAT config for every new customer and keeping track of internal IP add assignment (per customer).

Cheers,
Rajiv

Sent from my Phone

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 Mar 2011 10:49:11 +0200

> From: Rémi Després [mailto:[email-masked]]
> Sent: Wednesday, March 30, 2011 8:37 AM
> To: Dan Wing
> Cc: 'Wojciech Dec'; [email-masked]

Yes, that's what happens with any static scheme.

> (while it is often presented as the main advantage of ISP's running the

If that feature is desired, configure the NAT differently.  If that
feature is not desired, configure the NAT differently.

-d

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Mar 2011 11:14:42 +0200

No difference of analysis.
Thanks.
RD

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 Mar 2011 11:42:30 +0200

> Sent: Wednesday, March 30, 2011 11:15 AM
> To: Dan Wing

Right.  If the SP wants flexibility, they should choose NAT
because it can provide the flexibility to do no logging
with a similar restriction as A+P solutions (less efficient
IPv4 sharing).  But, with NAT, the SP maintains flexibility
to change their mind over the years, as IPv4 addresses get
expensive, as IPv4 port utilization goes up or goes down,
or their customer complaints get worse (or get better) due
to the number of ports allocated to each user.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Mar 2011 14:27:31 +0200

In your previous mail you wrote:

   Is it not true, then, that the better multiplexing ratio disappears
   (while it is often presented as the main advantage of ISP's running
   the NATs instead of CPE's)?
   
=> IMHO this better multiplexing ratio is an illusion: it relies on
a heterogeneous population but this doesn't match what one should get
in the real world: a small number of end-users sharing the same address
and likely living in the same block...
I believe the same thing about the similar argument on the provisioning:
stateful is supposed to make overbooking easier, i.e., you can put a
hard limit L to the number of ports per user with L * <#user> >> <#ports>.
With other words, between BSDs which pre-allocated the swap space when
processes request it, and Linux which kills arbitrary a process when
the swap space is full, you should guess what I prefer...

Regards

[email-masked]

PS: when applicable stateless solutions are better just because
by definition they are scalable. Exactly the opposite for a CGN.