Subject: [BEHAVE] what to do when the nat64 does not have a port that complies with the requirements

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Jan 2010 15:37:33 +0100

In the current NAT64 document, we have a set of SHOULDs for the port 
assignment.
In particular, for both TCP and UDP we recommend that the port should be 
from the same port range and in UDP we recommend that the port must 
preserve the parity.

The question is what do we do if we don't have a port that complies with 
the requirements?

Do we drop the packet or do we assign a port that does not meet the 
requirements?

Regards, marcelo

---

From: Dave Thaler <[email-masked]>
Date: Wed, 6 Jan 2010 23:07:51 +0000

My opinion: Assign a port that does not meet the requirements.

This will allow some applications to work.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, January 06, 2010 6:38 AM
> To: Behave WG
> Subject: [BEHAVE] what to do when the nat64 does not have a port that
> complies with the requirements
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jan 2010 15:29:54 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Thaler
> Sent: Wednesday, January 06, 2010 3:08 PM
> To: marcelo bagnulo braun; Behave WG
> Subject: Re: [BEHAVE] what to do when the nat64 does not have 
> a port that complies with the requirements
> 

+1.

-d

> > In particular, for both TCP and UDP we recommend that the 
> port should
> > be

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 6 Jan 2010 17:09:06 -0800

I agree that should be the default behavior. But also provide an option
to overide the behavior if someone want to strictly enforce the port
ranges & parity.

Senthil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dave Thaler
Sent: Wednesday, January 06, 2010 6:08 PM
To: marcelo bagnulo braun; Behave WG
Subject: Re: [BEHAVE] what to do when the nat64 does not have a port
that complies with the requirements

-Dave

> In particular, for both TCP and UDP we recommend that the port should 
> be from the same port range and in UDP we recommend that the port must

> preserve the parity.
> 
> The question is what do we do if we don't have a port that complies 
> with the requirements?
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 7 Jan 2010 01:45:12 +0000

If there is such an option in the document, I would suggest it be at most
a MAY.

-Dave

> Behalf Of Senthil Sivakumar (ssenthil)
> Sent: Wednesday, January 06, 2010 5:09 PM
> To: Dave Thaler; marcelo bagnulo braun; Behave WG
> Behalf

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 07 Jan 2010 13:52:18 +0100

These are the proposed text for these two sections. Please comment:

            <section title="Rules for Allocation of IPv4 Transport 
Addresses for UDP" anchor="UDP transport address alloc">
                <t>If the rules specify that a new UDP BIB entry is 
created for a source
             transport address of (S',s), then the NAT64 allocates an 
IPv4 transport
             address for this BIB entry as follows:<list style="empty">
                 <t>If there exists some other BIB entry containing S' 
as the IPv6
                 address and mapping it to some IPv4 address T, then the 
NAT64 SHOULD use T as the
                 IPv4 address. Otherwise, use any IPv4 address of the 
IPv4 pool assigned to the NAT64 to be used for translation.</t>

                 <t>If the port s is in the Well-Known port range 
0-1023, and the NAT64 has an
                    available port t in the same port range, then the 
NAT64 SHOULD allocate the port t.
                    If the NAT64 does not have a port available in the 
same range,
                    the NAT64 MAY assign a port t from other range where 
it has an available port.
                    (this behavior is recommended in Section 7.1 of 
<xref target="RFC5382"></xref>)</t>

                 <t>If the port s is in the range 1024-65535, and the 
NAT64 has an
                    available port t in the same port range, then the 
NAT64 SHOULD allocate the port t.
                    If the NAT64 does not have a port available in the 
same range,
                    the NAT64 MAY assign a port t from other range where 
it has an available port.
                    (this behavior is recommended in Section 7.1 of 
<xref target="RFC5382"></xref>)</t>

                 <t>If the port s is even, and the NAT64 has an
                    available port t that is also even, then the NAT64 
SHOULD allocate the port t.
                    If the NAT64 does not have an even port available,
                    the NAT64 MAY assign an odd port t that it has 
available.
                    (this behavior is recommended in Section 7.1 of 
<xref target="RFC5382"></xref>)</t>

                 <t>If the port s is odd, and the NAT64 has an
                    available port t that is also odd, then the NAT64 
SHOULD allocate the port t.
                    If the NAT64 does not have an odd port available,
                    the NAT64 MAY assign an even port t that it has 
available.
                    (this behavior is recommended in Section 7.1 of 
<xref target="RFC5382"></xref>)</t>

                 <t>In all cases, the allocated IPv4 transport address 
(T,t) MUST
                 NOT be in use in another entry in the same BIB, but MAY 
be in
                 use in the other BIB (referring to the UDP and TCP 
BIBs).</t>
               </list>If it is not possible to allocate an appropriate IPv4
             transport address or create a BIB entry, then the
             packet is discarded. The NAT64 MAY send an ICMPv6 
Destination Unreachable/Address unreachable (Code 3) message. </t>
            </section>

            <section title="Rules for allocation of IPv4 transport 
addresses for TCP" anchor="TCP transport address alloc">
                <t>If the rules specify that a new TCP BIB entry is 
created for a source
             transport address of (S',s), then the NAT64 allocates an 
IPv4 transport
             address for this BIB entry as follows:<list style="empty">
                 <t>If there exists some other BIB entry containing S' 
as the IPv6
                 address and mapping it to some IPv4 address T, then use 
SHOULD T as the
                 IPv4 address. Otherwise, use any IPv4 address of the 
IPv4 pool assigned to the NAT64 to be used for translation.</t>

                 <t>If the port s is in the Well-Known port range 
0-1023, and the NAT64 has an
                    available port t in the same port range, then the 
NAT64 SHOULD allocate the port t.
                    If the NAT64 does not have a port available in the 
same range,
                    the NAT64 MAY assign a port t from other range where 
it has an available port. </t>

                 <t>If the port s is in the range 1024-65535, and the 
NAT64 has an
                    available port t in the same port range, then the 
NAT64 SHOULD allocate the port t.
                    If the NAT64 does not have a port available in the 
same range,
                    the NAT64 MAY assign a port t from other range where 
it has an available port. </t>

                 <t>In all cases, the allocated IPv4 transport address 
(T,t) MUST
                 NOT be in use in another entry in the same BIB, but MAY 
be in
                 use in the other BIB (referring to the UDP and TCP 
BIBs).</t>
               </list>If it is not possible to allocate an appropriate IPv4
             transport address or create a BIB entry, then the
             packet is discarded. The NAT64 MAY send an ICMPv6 
Destination Unreachable/Address unreachable (Code 3) message. </t>
            </section>

There are two additional questions. We are requiring paired address 
pooling in both cases.
Note that the TCP requirements don't impose such requirement but we do.
Please also note that in case we cannot find a port available that match 
the currently used address, we will not create a binding and we will 
discard the packet.
Also,  for UDP, we are not defining a preference whether we preffer to 
preserve the port range or the port parity.

So, the questions are:
- should we use paired address pooling for TCP?
- what do we do if we cannot do paired address pooling? do we drop the 
packet or we break the paired address pooling?
- do we need to set a preference for port range vs. parity?

Regards, marcelo

Just want to confirm that this is ok

Regards, marcelo

Dave Thaler escribió:
>>> be from the same port range and in UDP we recommend that the port
>>>       
>> must
>>
>>     
>>> preserve the parity.
>>>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 07:51:57 -0800

> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Thursday, January 07, 2010 4:52 AM
> To: Dave Thaler
> Cc: Behave WG

RFC5382 is for TCP, but this text is in your UDP section.  

Better reference is RFC4747's requirement REQ-3a.

> <xref target="RFC5382"></xref>)</t>

Same comment about RFC5382 is for TCP.  Better reference is
RFC4747's requirement REQ-3a.

> <xref target="RFC5382"></xref>)</t>

Same comment for the even/odd port, that the reference to RFC5382
is incorrect.  Better reference is RFC4747's section 4.2.2, "Port 
parity".

And I would just tighten the text to say:

  The NAT64 SHOULD preserve the port parity (odd/even), as 
  per Section 4.2.2 of [RFC4747].

> There are two additional questions. We are requiring paired address 

I don't understand what its meant by 'paired address pooling'.

> - do we need to set a preference for port range vs. parity?

I think this gets into implementation details a lot -- you're
getting into a case where resources are so tight (we ran out of
ports); some implementations may find it so important to preserve
parity (or to preserve port range) that they might take a port
that is in the (effective) TIME_WAIT state (that is, one that 
hasn't been used in a long while) to meet that SHOULD (but violating
a different SHOULD).  Others will just allocate whatever port they 
can, hoping the application will still work, violating your SHOULD.

-d

---

From: Dave Thaler <[email-masked]>
Date: Thu, 7 Jan 2010 18:12:33 +0000

As Dan observed, my previous comments on the UDP section have not
been addressed in the proposed text below.  (e.g., it points to
the wrong RFC, does not mention port preservation for UDP, etc.)

-Dave

> From: marcelo bagnulo braun [mailto:[email-masked]]
> Cc: Senthil Sivakumar (ssenthil); Behave WG

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 07 Jan 2010 22:34:43 +0100

will change the reference for the UDP requirements, sorry for that.

> I don't understand what its meant by 'paired address pooling'.

from rfc 4787

   Some NATs are capable of assigning IP addresses from a pool of IP
   addresses on the external side of the NAT, as opposed to just a
   single IP address.  This is especially common with larger NATs.  Some
   NATs use the external IP address mapping in an arbitrary fashion
   (i.e., randomly): one internal IP address could have multiple
   external IP address mappings active at the same time for different
   sessions.  These NATs have an "IP address pooling" behavior of
   "Arbitrary".  Some large Enterprise NATs use an IP address pooling
   behavior of "Arbitrary" as a means of hiding the IP address assigned
   to specific endpoints by making their assignment less predictable.
   Other NATs use the same external IP address mapping for all sessions
   associated with the same internal IP address.  These NATs have an "IP
   address pooling" behavior of "Paired".  NATs that use an "IP address
   pooling" behavior of "Arbitrary" can cause issues for applications
   that use multiple ports from the same endpoint, but that do not
   negotiate IP addresses individually (e.g., some applications using
   RTP and RTCP).

> can, hoping the application will still work, violating your SHOULD.
so, you mean we can leave it as it is?

Regards, marcelo

>>> If there is such an option in the document, I would suggest 
>>>       
>> it be at most
>>     
>>> a MAY.
>>>
>>> -Dave
>>>
>>>   
>>>       
>>>> Subject: Re: [BEHAVE] what to do when the nat64 does not 
>>>>         
>> have a port
>>     
>>>> I agree that should be the default behavior. But also 
>>>>         
>> provide an option
>>     
>>>> to overide the behavior if someone want to strictly 
>>>>         
>> enforce the port
>>     
>>>> ranges & parity.
>>>>
>>>> Senthil
>>>>
>>>> Subject: Re: [BEHAVE] what to do when the nat64 does not 
>>>>         
>> have a port
>>     
>>>>> Subject: [BEHAVE] what to do when the nat64 does not have 
>>>>>           
>> a port that
>>     
>>>>> In the current NAT64 document, we have a set of SHOULDs 
>>>>>           
>> for the port
>>     
>>>>> assignment.
>>>>> The question is what do we do if we don't have a port 
>>>>>           
>> that complies
>>     
>>>>> with the requirements?
>>>>>
>>>>> Do we drop the packet or do we assign a port that does 
>>>>>           
>> not meet the
>>     
>>>>> requirements?
>>>>>
>>>>> Regards, marcelo
>>>>>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 14:22:34 -0800

> Sent: Thursday, January 07, 2010 1:35 PM
> To: Dan Wing
> Cc: 'Behave WG'; 'Dave Thaler'

Thanks for the citation.

> >> - should we use paired address pooling for TCP?

All outgoing connections, UDP, TCP, and ICMP, need to use the
same public IPv4 address.  Reasons are discussed around
REQ-1a of http://tools.ietf.org/html/draft-nishitani-cgn-03.

> so, you mean we can leave it as it is?

Yes.  I think SHOULD is sufficient.  If the SHOULD can't be met,
the implementor is supposed to understand the side-effects (at
least, that's what RFC2119 says about SHOULD).

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 07 Jan 2010 23:33:32 +0100

Dan Wing escribió:
>>>> There are two additional questions. We are requiring 
>>>>         
>> paired address 
>>     
>>>> pooling in both cases.
>>>>     
>>>>         
>>>> the currently used address, we will not create a binding 
>>>>         
>> and we will 
>>     
>>>> discard the packet.

ok, so we can leave it as it is on this as well, correct?

Regards, marcelo

>> [mailto:[email-masked]] On
>>     
>>>>>>> be from the same port range and in UDP we recommend 
>>>>>>>               
>> that the port
>>     
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> must
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> preserve the parity.
>>>>>>>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 15:04:11 -0800

> Sent: Thursday, January 07, 2010 2:34 PM
> To: Dan Wing

Existing text in draft-ietf-behave-v6v4-xlate-stateful-07 says this for UDP
and TCP:

      If there exists some other BIB entry containing S' as the IPv6
      address and mapping it to some IPv4 address T, then use T as the
      IPv4 address.  Otherwise, use any IPv4 address of the IPv4 pool
      assigned to the NAT64 to be used for translation.

but doesn't say that for ICMP.  It should; without similar text for ICMP, ICMP
could be on a different IPv4 public address than UDP and TCP.  I dunno what
might break -- maybe nothing -- but existing text is certainly breaking REQ-1a
of http://tools.ietf.org/html/draft-nishitani-cgn-03.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Jan 2010 13:26:56 +0100

Dan Wing escribió:
>>>>    Some NATs are capable of assigning IP addresses from a 
>>>>         
>> pool of IP
>>     
>>>>    external IP address mappings active at the same time 
>>>>         
>> for different
>>     
>>>>    "Arbitrary".  Some large Enterprise NATs use an IP 
>>>>         
>> address pooling
>>     
>>>>    to specific endpoints by making their assignment less 
>>>>         
>> predictable.
>>     
>>>>    pooling" behavior of "Arbitrary" can cause issues for 
>>>>         
>> applications
>>     
>>>>    negotiate IP addresses individually (e.g., some 
>>>>         
>> applications using
>>     
>>>>    RTP and RTCP).
>>>>     
>>>>         
>>> Thanks for the citation.
>>>
>>>   
>>>       
> but doesn't say that for ICMP.  

mmm, the current draft reads in section 3.2.3.  ICMP Query Session Handling

         If there exists some other BIB entry containing the same IPv6
         address X' and mapping it to some IPv4 address T, then use T as
         the BIB IPv4 address for this new entry.  Otherwise, use any
         IPv4 address assigned to the IPv4 interface.

do you think something else is missing?

regards, marcelo

> It should; without similar text for ICMP, ICMP
>>>>> hasn't been used in a long while) to meet that SHOULD 
>>>>>           
>> (but violating
>>     
>>>>> a different SHOULD).  Others will just allocate whatever 
>>>>>           
>> port they 
>>     
>>>>> can, hoping the application will still work, violating 
>>>>>           
>> your SHOULD.
>>     
>>>>>   
>>>>>       
>>>>>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 08:10:12 -0800

> Sent: Friday, January 08, 2010 4:27 AM
> To: Dan Wing
> IPv4 pool

I had missed that text, sorry.  Thanks for pointing it out.  It's fine.

-d