Subject: RE: [Ietf-behave] Maximum number of binding

From: "Francois Audet" <[email-masked]>
Date: Wed, 24 Nov 2004 16:30:53 -0800 (PST)

Let me know if there is some precise wording that needs to be added, and where.

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Wednesday, November 24, 2004 16:03
> To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; Audet, Francois [SC100:9T51:EXCH]
> Subject: Re: [Ietf-behave] Maximum number of binding
> 
> 
> ICMP type=3, code=2 is "protocol unreachable" which most closely 
> indicates the problem the NAT is attempting to communicate.  However, 
> code=2 can only be sent by the destination host.  So ICMP type=3, 
> code=0 "net unreachable" is probably best.
> 
> -d
> 
> On Nov 24, 2004, at 3:04 PM, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote:
> 
> > If number of simultaneous connections per binding exceeds what a NAT
> > can have, the NAT might either overwrite an existing 
> binding for a new 
> > connection or do nothing with the new connection, and there 
> is no way 
> > for an application to know what is going on... this is the 
> problem. I 
> > think Teredo is a good example, which encapsulates multiple IPv6 
> > TCP/UDP connection to many remote hosts on a single IPv4 UDP socket 
> > binding assuming that a NAT can have enough number of 
> connections on a 
> > single binding (especially when NB=AD or APD). I feel at 
> least in such 
> > a case the NAT could send a new ICMP error like "Too many 
> connections" 
> > back to a connecting node, IMHO.
> >  
> > Yutaka
> >  
> > ----- Original Message -----
> >  From: Francois Audet
> > To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ;
> > 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> > Sent: Friday, November 19, 2004 3:57 PM
> > Subject: RE: [Ietf-behave] Maximum number of binding
> >
> >
> > Thanks for the comments. I hadn't put too much tought into it, as I 
> > viewed this more of a product specification type of requirement.
> >
> > Let's see if anybody has any views on the list.
> >
> > > -----Original Message-----
> > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> > > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx
> > > Sent: Friday, November 19, 2004 13:59
> > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > > Subject: [Ietf-behave] Maximum number of binding
> >  >
> > >
> > > I like how 'behave-nat-00' classifies different behaviors of
> >  > NAT.  The
> > > common term definitions also make my life easier, indeed. 
> Nice job!
> >  >
> > > One thing I thought... It would be nice to include a 
> requirement on:
> > >
> >  > - Minimum number of bindings per NAT.
> >  >
> > > Especially, NB=AD and NB=APD  consume more memory resource in
> >  > NAT. The
> >  > requirement may have to have:
> >  >
> > > - Minimum number of connections (destinations) per binding.
> > >
> >  > I can see that developers especially who are working on 
> residential
> > > gateways, or routers are trying minimize its
> > > memory requirement to bring down hardware cost as low as 
> possible to 
> > > win
> >  > the race. Does anyone have any idea or thoughts on above
> > > parameters in
> > > existing NATs?
> > >
> > > Thanks,
> > > Yutaka
> > >
> > >
> > > _______________________________________________
> > > Ietf-behave mailing list
> > > Ietf-behave@xxxxxxxxxxxxxxxxxxx
> >  > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> >  >
> > >
> >
> >  _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
> 
>

---

From: Dan Wing <[email-masked]>
Date: Wed, 24 Nov 2004 16:47:25 -0800 (PST)

Section 3.2, "port assignment", needs to discuss running out of ports.  
I suggest adding another paragraph, probably right after the paragraph 
discussing the 1-1023 and 1024-65535 ranges:

  In high-load situations, a NAT may exhaust its source UDP port range. 
 If
  such an event occurs,

    o the NAT MUST NOT prematurely re-use a UDP port, as this may
      cause a datagram from the old UDP binding to be injected into the
      new UDP binding, and;
    o the NAT MUST NOT use a source UDP port from the other UDP port 
range,
      and;

    o it is strongly RECOMMENDED that the NAT send an ICMP message 
type=3,
      code=0 ("net unreachable") in response to the UDP packet, and;

    o Alternatively, but less preferred, the NAT SHOULD simply drop the
      UDP packet and not transmit it on the public side of the NAT.
(I noticed that 'public side' and 'private side' aren't defined in 
draft-ietf-behave-nat-00, so replace that term appropriately in my 
suggested paragraph above.)

-d

On Nov 24, 2004, at 4:29 PM, Francois Audet wrote:

Let me know if there is some precise wording that needs to be added, 
and where.

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 25 Nov 2004 11:45:23 -0800 (PST)

At 04:47 PM 11/24/2004 -0800, Dan Wing wrote:
Section 3.2, "port assignment", needs to discuss running out of ports.
I suggest adding another paragraph, probably right after the paragraph 
discussing the 1-1023 and 1024-65535 ranges:

  In high-load situations, a NAT may exhaust its source UDP port range.  If
  such an event occurs,
    o the NAT MUST NOT prematurely re-use a UDP port, as this may
      cause a datagram from the old UDP binding to be injected into the
      new UDP binding, and;
    o the NAT MUST NOT use a source UDP port from the other UDP port range,
      and;
What is the use of the above restriction/requirement?

    o it is strongly RECOMMENDED that the NAT send an ICMP message type=3,
      code=0 ("net unreachable") in response to the UDP packet, and;
    o Alternatively, but less preferred, the NAT SHOULD simply drop the
      UDP packet and not transmit it on the public side of the NAT.
Shouldn't this be a MUST?

Senthil

-d

Let me know if there is some precise wording that needs to be added, and 
where.

> >  > NAT.  The
> >  > - Minimum number of bindings per NAT.
> >  >
> >  > NAT. The
> >  > requirement may have to have:
> >  >
> >  > I can see that developers especially who are working on
> residential
> >  > the race. Does anyone have any idea or thoughts on above
> > > parameters in
> > > existing NATs?
> > >
> > > Thanks,
> > > Yutaka
> > >
> > >

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Nov 2004 12:39:47 -0800 (PST)

On Nov 25, 2004, at 11:46 AM, Senthil Sivakumar wrote:

At 04:47 PM 11/24/2004 -0800, Dan Wing wrote:
Section 3.2, "port assignment", needs to discuss running out of ports.
I suggest adding another paragraph, probably right after the 
paragraph discussing the 1-1023 and 1024-65535 ranges:

  In high-load situations, a NAT may exhaust its source UDP port 
range.  If
  such an event occurs,

    o the NAT MUST NOT prematurely re-use a UDP port, as this may
      cause a datagram from the old UDP binding to be injected into 
the
      new UDP binding, and;

    o the NAT MUST NOT use a source UDP port from the other UDP port 
range,
      and;
What is the use of the above restriction/requirement?
See the discussion in section 3.2 of draft-ietf-behave-nat-00.txt 
regarding
the well-known, registered, and dynamic port ranges.

    o Alternatively, but less preferred, the NAT SHOULD simply drop 
the
      UDP packet and not transmit it on the public side of the NAT.
Shouldn't this be a MUST?

Sure, how about rewording that last bullet to:

  o If the NAT doesn't send the above-described ICMP message, the NAT
    MUST drop the UDP packet and not transmit it on the public side of
    the NAT.
-d

Senthil

-d

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 25 Nov 2004 20:50:50 -0800 (PST)

I understand that we're trolling the depths of aberrent behavior here, 
but has anyone seen a NAT that cannot allocate a UDP source port (due 
to a large number of bindings leading to port exhaustion, as 
previously described) and still transmits the packet on the public 
side of the NAT?

    o it is strongly RECOMMENDED that the NAT send an ICMP message 
type=3,
      code=0 ("net unreachable") in response to the UDP packet, 
and;

    o Alternatively, but less preferred, the NAT SHOULD simply 
drop the
      UDP packet and not transmit it on the public side of the 
NAT.
Shouldn't this be a MUST?
Sure, how about rewording that last bullet to:

  o If the NAT doesn't send the above-described ICMP message, the 
NAT
    MUST drop the UDP packet and not transmit it on the public side 
of
    the NAT.
I'm just trying to understand how precise we need to be in describing 
MUST NOT behavior.

Thanks,

Spencer

---

From: [email-masked]
Date: Fri, 26 Nov 2004 13:14:51 -0800 (PST)

> If such an event occurs,

Let me make sure if we are on the same boat. Besides the source UDP
port range (space) exhaustion, I am also concerned about binding resource 
exhaustion in NAT. 

Say, a NAT has NB=I and EF=ADP properties, and a host wants to 
send UDP packets to outside from a single source port bound to a socket.
Although the NAT only needs one external port, the NAT has to remember
each packets destination address and port number for filtering. Then,
"how many transport addresses associated to the single binding the NAT
can remember?" is my question. (I just realized that I said 'NB' where I 
meant 'EF' in my previous postings. Sorry.) 

>   o the NAT MUST NOT prematurely re-use a UDP port, as 
>      this may cause a datagram from the old UDP binding to be 
>      injected into the new UDP binding, and;

I agree.

>    o the NAT MUST NOT use a source UDP port from the 
>       other UDP port range, and;

I agree.

>    o it is strongly RECOMMENDED that the NAT send an ICMP 
>       message type=3, code=0 ("net unreachable") in response to the 
>       UDP packet, and;

Is there a reason why this cannot be a MUST.

>       the UDP packet and not transmit it on the public side of the NAT.

I feel this needs to be a MUST.

Yutaka

----- Original Message ----- 
From: "Dan Wing" <dwing@xxxxxxxxx>
To: "Francois Audet" <audet@xxxxxxxxxxxxxxxxxx>
Cc: <ietf-behave@xxxxxxxxxxxxxxxxxxx>; <yutaka_takeda@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, November 24, 2004 4:47 PM
Subject: Re: [Ietf-behave] Maximum number of binding

-d

---

From: Kaushik Biswas <[email-masked]>
Date: Sat, 27 Nov 2004 13:09:44 -0800 (PST)

> In high-load situations, a NAT may exhaust its source UDP port range.
Shouldn't we reword this to include Address & Port exhaustion to be more 
specific so as to avoid any confusions ? UDP port-range for one NAT 
public-address can exhaust but NAT can still pick up the next 
public-address from its address-pool(s) and start using the port-range 
associated with that.

-Kaushik

I agree.

I agree.

Yutaka

---

From: Dan Wing <[email-masked]>
Date: Mon, 29 Nov 2004 10:01:46 -0800 (PST)

On Nov 25, 2004, at 8:51 PM, Spencer Dawkins wrote:

I understand that we're trolling the depths of aberrent behavior here, 
but has anyone seen a NAT that cannot allocate a UDP source port (due 
to a large number of bindings leading to port exhaustion, as 
previously described) and still transmits the packet on the public 
side of the NAT?
The behavior I want to explicitly prohibit is a NAT that decides to 
prematurely time out a previous binding, as that behavior leads to 
non-deterministic behavior from an application's view.

  o If the NAT doesn't send the above-described ICMP message, the NAT
    MUST drop the UDP packet and not transmit it on the public side of
    the NAT.
I'm just trying to understand how precise we need to be in describing 
MUST NOT behavior.
You're suggesting we just need to prohibit a NAT from reusing a 
previous binding before the 2 minute timeout and leave it at that -- or 
that the existing wording for the two minute timeout is sufficient?

-d

---

From: [email-masked]
Date: Mon, 29 Nov 2004 11:37:14 -0800 (PST)

> ..., as that behavior leads to 

I agree with your idea. No matter how the existing NATs are 
implemented, if there is any case that can lead to non-deterministic
behavior of NATs, we should take precautions against it.

Thanks,
Yutaka