Subject: [BEHAVE] draft-tsou-behave-natx4-log-reduction-01

From: Rémi Després <[email-masked]>
Date: Mon, 6 Sep 2010 18:14:59 +0200

Hi Tina,

Your draft covers NAT64 log minimization for *dynamically shared port ranges.

There is an even more effective approach to reduce NAT64 logs which is static port-set allocations, with port sets algorithmically derived from assigned v6 prefixes.

A way to do it is presented in draft-despres-softwire-sam-01.
- How to derive extended IPv4 addresses (IPv4E) from IPv6 prefixes is covered in sec. 3.2
- How to derive assigned port sets from IPv4E addresses is covered in sec. 2.4.

FYI, below is an extract coming from a discussion in Softwire about port allocation.
Following this discussion, section 8.4 and annex C of draft-ietf-softwire-dual-stack-lite-06, which deal with port allocation policies, will apparently be deleted (www.ietf.org/mail-archive/web/softwires/current/msg01562).

Regards,
RD

<<<
> De : Ralph Droms <[email-masked]>
> Objet : Rép : [Softwires] dual-stack-lite-06 - Too biased against static port sharing
> ...
> On Aug 11, 2010, at 8:38 AM 8/11/10, Rémi Després wrote:

>> 1. The text should take into account that "over time" more and more servers will have IPv6, and that the full 64K ports are available in IPv6. (The mentioned AJAX/Web 2.0 sites would typically enable IPv6 asap, if not done yet. This will prevent problems over time.)
> 
> traffic to IPv6 servers just bypasses dual-stack lite altogether, right, so the limitation doesn't apply to that traffic?
> 
>> 2. If the number of assignable IPv4 addresses is for a start multiplied by 10, by statically sharing ports of each address among 10 customers, this still leaves several thousands of IPv4 ports per customer. (Exactly 6144 ports per customer if, as appropriate, the first 4K ports, that include well-known ports and have special value are excluded). 
> 
> Agreed; one could argue that even sharing an IPv4 address among 5 customers allows 5x as many customers in the existing IPv4 address assignment, which should be more than enough to bridge the gap until IPv6 is available.
> 
>> 3. Where applicable static sharing is much simpler to operate.
> 
> Agreed.
>>>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 07 Sep 2010 11:31:01 +0200

Merci, Remi.
The static way needs to manage the port directly, so the there is high  
requirement from the operation point of view, the log will naturally  
be less.
The two ways need to be considered.

B. R.
Tina
http://tinatsou.weebly.com

On Sep 6, 2010, at 6:14 PM, Rémi Després wrote:

> There is an even more effective approach to reduce NAT64 logs which  
> is static port-set allocations, with port sets algorithmically  
> derived from assigned v6 prefixes.
>
> Following this discussion, section 8.4 and annex C of draft-ietf- 
> softwire-dual-stack-lite-06, which deal with port allocation  
> policies, will apparently be deleted (www.ietf.org/mail-archive/web/softwires/current/msg01562) 
> .
>
> Regards,
> RD
>
>
> <<<
>>> 1. The text should take into account that "over time" more and  
>>> more servers will have IPv6, and that the full 64K ports are  
>>> available in IPv6. (The mentioned AJAX/Web 2.0 sites would  
>>> typically enable IPv6 asap, if not done yet. This will prevent  
>>> problems over time.)
>>
>> traffic to IPv6 servers just bypasses dual-stack lite altogether,  
>> right, so the limitation doesn't apply to that traffic?
>>
>>> 2. If the number of assignable IPv4 addresses is for a start  
>>> multiplied by 10, by statically sharing ports of each address  
>>> among 10 customers, this still leaves several thousands of IPv4  
>>> ports per customer. (Exactly 6144 ports per customer if, as  
>>> appropriate, the first 4K ports, that include well-known ports and  
>>> have special value are excluded).
>>
>> Agreed; one could argue that even sharing an IPv4 address among 5  
>> customers allows 5x as many customers in the existing IPv4 address  
>> assignment, which should be more than enough to bridge the gap  
>> until IPv6 is available.
>>

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Sep 2010 12:12:57 +0200

Le 7 sept. 2010 à 11:31, Tina TSOU a écrit :

> Merci, Remi.
> The static way needs to manage the port directly,

> so the there is high requirement from the operation point of view,

It depends on how port states are assigned.
If they are algorithmically derived from assigned IPv6 prefixes, the requirement from the operation point of view is almost nil.
keeping track of which customer has which IPv6 prefix is sufficient. 
(This is like Like in 6rd where keeping track ofIPv4 addresses is sufficient to know which customer has which IPv6 prefix.)
 
In the DSAM draft, this 1-1 mapping between an IPv6 prefix and an extended IPv4 address (address + port set) is presented in the context of tunneling solutions, but it can also apply to translation solutions.

RD

> the log will naturally be less.

---

From: Xing Li <[email-masked]>
Date: Fri, 10 Sep 2010 22:00:54 +0800

> (This is like Like in 6rd where keeping track ofIPv4 addresses is sufficient to know which customer has which IPv6 prefix.)
agree.

> In the DSAM draft, this 1-1 mapping between an IPv6 prefix and an extended IPv4 address (address + port set) is presented in the context of tunneling solutions, but it can also apply to translation…

similar schemes are also proposed in dIVI and partial state IVI drafts.

regards,

xing

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

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Sep 2010 16:35:26 +0200

Le 10 sept. 2010 à 16:00, Xing Li a écrit :

>> keeping track of which customer has which IPv6 prefix is sufficient. (This is like Like in 6rd where keeping track ofIPv4 addresses is sufficient to know which customer has which IPv6 prefix.)
>>  
> agree.
> 

Agreed.

RD