Subject: [BEHAVE] NAT behaviour when port quota is reached

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Jun 2011 15:41:30 -0400

These two don't seem to agree on what is appropriate...

RFC 5508:

   REQ-8: When a NAT device is unable to establish a NAT Session for a
   new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource
   constraints or administrative restrictions, the NAT device SHOULD
   send an ICMP destination unreachable message, with a code of 13
   (Communication administratively prohibited) to the sender, and drop
   the original packet.

RFC 6146:

   If it is not possible to allocate an appropriate IPv4 transport
   address or create a BIB entry, then the packet is discarded.  The
   NAT64 SHOULD send an ICMPv6 Destination Unreachable error message
   with Code 3 (Address Unreachable).

Code 3 is a soft error according to RFC 5461.

Any reason why they're not specifying the same code? Is there an errata
to be filed?

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: "Dan Wing" <[email-masked]>
Date: Fri, 24 Jun 2011 15:40:05 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Tuesday, June 21, 2011 12:42 PM
> To: [email-masked]
> Subject: [BEHAVE] NAT behaviour when port quota is reached
> 

I recall some discussion occurred on this difference.  

We need to reach a consensus on this, because a CGN will certainly
hit this limit and we should have a consistent error message that
all CGNs generate.  (Which I suppose is part of the reason you 
are asking.)

IMO, if a user hits a configured limit (e.g., 1000 ports), 
'administratively prohibited' is a reasonable error.  Afterall,
the NAT may well have plenty of additional capacity for more
mappings, but the NAT is administratively restricted from giving
the user more than 1000 mappings.  On the other hand, if a user
hits a hard limit (e.g., consumes all of the memory allocated
to mappings in the NAT), this isn't an 'administrative' limit
but is rather an architectural limit (physical memory), and
returning 'address unreachable' makes sense.

But, there is probably no value in differentiating these two types
of errors.

Thoughts?
-d

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

---

From: Simon Perreault <[email-masked]>
Date: Sun, 26 Jun 2011 11:41:25 -0400

> all CGNs generate.  (Which I suppose is part of the reason you

Precisely. I started a new thread to ensure this issue gets the 
attention it deserves.

> But, there is probably no value in differentiating these two types

IMHO, what is important is that the error is soft. From the point of 
view of the TCP stack, both cases above should be handled exactly as 
when a packet is dropped by a router when its queue is full: it should 
retransmit. This is what's important.

This implies that sending an ICMP error in the first place does not 
matter very much. Quoting RFC 792, "Some datagrams may still be 
undelivered without any report of their loss.  The higher level 
protocols that use IP must implement their own reliability procedures if 
reliable communication is required." Furthermore, ICMP errors sent by 
the CGN are going to be rate limited so the TCP stack will have to deal 
with the "no ICMP error" case quite often.

With all that said, we know that code 3 is specified to be a soft error, 
while we "guess" that 13 is soft (AFAIK). I'd rather err on the side of 
caution and pick 3 for the CGN requirements draft. And possibly file an 
errata against RFC 5508.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 26 Jun 2011 11:41:44 -0700

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Sunday, June 26, 2011 8:41 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [BEHAVE] NAT behaviour when port quota is reached
> 

As an individual, I agree with that analysis.

-d

---

From: Benson Schliesser <[email-masked]>
Date: Mon, 27 Jun 2011 12:03:22 -0500

On 6/26/11 1:41 PM, "Dan Wing" <[email-masked]> wrote:
>> ...

Same here.  For a point of reference, I looked quickly at the latest stable
Linux source (caveat: I'm no Linux kernel hacker - somebody should verify my
comment) and it appears to handle both sub-codes 3 and 13 the same.  Of
course, I'm not sure that it handles packet loss the same as an ICMP
unreach; I think packet loss will result in a slower connection death.  In
the case of a connection failure via CGN, I think it's good to send an ICMP
message if possible to indicate failure quickly, with a fallback to "dropped
packet" behavior if the ICMP rate is too high / being policed.

Cheers,
-Benson