Subject: [Softwires] I-D Action:draft-ietf-softwire-dual-stack-lite-06.txt

From: [email-masked]
Date: Tue, 10 Aug 2010 15:30:03 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires Working Group of the IETF.

	Title           : Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
	Author(s)       : A. Durand, et al.
	Filename        : draft-ietf-softwire-dual-stack-lite-06.txt
	Pages           : 34
	Date            : 2010-08-10

This document revisits the dual-stack model and introduces the dual-
stack lite technology aimed at better aligning the costs and benefits
of deploying IPv6 in service provider networks.  Dual-stack lite
enables a broadband service provider to share IPv4 addresses among
customers by combining two well-known technologies: IP in IP (IPv4-
in-IPv6) and Network Address Translation (NAT).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-stack-lite-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Rémi Després <[email-masked]>
Date: Wed, 11 Aug 2010 17:38:05 +0200

Helo all,

Sec 8.4.1 says (asterisks added):
"... thousands or tens of thousands of ports could be use in a peak by any single customer browsing a number of AJAX/Web 2.0 sites.  
As such, service providers allocating a fixed number of ports per user should dimension the system with a minimum of N = several thousands of ports for every user.  This would bring the address space reduction ratio to a single digit.  Service providers using a smaller number of ports per user (N in the hundreds) should expect customers applications to break in a more or less random way over time.
In order to achieve higher address space reduction ratios, *it is recommended that service provider do not use this cookie-cutter approach, and, on the contrary, allocate ports as dynamically as possible, just like on a regular NAT*."

This is more biased against fixed number of ports per customer than technically appropriate, at least for the three reasons below. (Besides, such a bias isn't needed to justify the DS-lite specification): 

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.)

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). 

3. Where applicable static sharing is much simpler to operate.

If the principle is agreed, I can propose detailed words myself to improve the draft.

Regards,
RD

Le 11 août 2010 à 00:30, [email-masked] a écrit :

> <Pièce jointe Mail>_______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Aug 2010 15:00:10 -0700

Rémi - please see responses in line...

- Ralph

> 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 enab…

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…

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.

> _______________________________________________
> Softwires mailing list
> [email-masked]

---

From: Alain Durand <[email-masked]>
Date: Wed, 11 Aug 2010 18:50:07 -0700

> 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 u…

The later part of this comment is IMHO a matter of opinion... It is very hard to know for sure how much IPv4 translation will be needed in the feature.
The major issue with any scheme that allocates a fixed number of ports is what do you do when that number is exhausted?
How do you even know this is happening? This may or may bot be an issue if we are talking about 10k ports per customers,
but as pressure mounts on the IPv4 space and the address compression ratio need to be increased, you soon end-up with much less ports per customers. And then what?

>> 3. Where applicable static sharing is much simpler to operate.

Logs can indeed be simpler to manage, sure. But this is a trade-off. Other parts of the systems are more complex, see above.

All this being said, the discussion of the advantages or inconvenients of A+B belong  to the A+P mailing list.

    - Alain.

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Aug 2010 08:06:19 +0200

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Aug 2010 08:21:20 +0200

Hi Ralph,
More in line.

>> traffic to IPv6 servers just bypasses dual-stack lite altogether, right, so the limitation doesn't apply to that traffic?

Exactly.
Thus, dual-stack hosts will need time less and less IPv4 ports.
Suggesting in an RFC that they may need over time several thousands IPv4 ports would therefore be misleading.

>>> If the principle is agreed, I can propose detailed words myself to improve the draft.

Is it right, then, that you welcome the proposal to revise the text?

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Aug 2010 09:43:16 +0200

Hi Alain,
More in line.

> How do you even know this is happening?

The draft rightly accepts to put "a hard limit on the maximum number of port usable by single user".
I don't see why what is done when this maximum is exceeded wouldn't be also OK in case of fixed allocations.

> This may or may bot be an issue if we are talking about 10k ports per customers

... and even less with fixed allocation with 5 customers per v4 address ;-).
(This assigns 12,288 ports per customer, right?).

The point is not to recommend fixed allocation, but just to be neutral.

> , but as pressure mounts on the IPv4 space and the address compression ratio need to be increased, you soon end-up with much less ports per customers.

This is ignoring that, as more and more connections become IPv6, the number of IPv4 ports needed per customer will decrease.
The address-compression ratio possible with fixed allocations will increase accordingly.

> And then what?

In this respect, suggesting that host might safely continue to be IPv4-only because CGNs, DS-lite, PCP, TuRN STUN, ICE, etc. would in my understanding be extremely counterproductive. 
The only recommendation that IMHO makes sense is to asap enable dual-stacks, in client and server hosts, wherever it is possible.
If this is done, dynamic allocations might never be necessary in many places.

In any case, the point is not to prohibit overbooking.
It is only, in the context of DS-lite, to avoid recommending overbooking while there are clear circumstances where it isn't needed, and as it makes AFTR operation significantly more complex.

> All this being said, the discussion of the advantages or inconvenients of A+B belong  to the A+P mailing list.

This is a discussion is about fixed vs dynamic port allocations in the context of DS-lite.
The stake, which is an improvement of draft-ietf-softwire-dual-stack-lite-06, seems clearly in the scope of Softwire.

Regards,
RD

---

From: <[email-masked]>
Date: Thu, 12 Aug 2010 10:22:30 +0200

Dear all,

We have raised this point during the last call which has been issued on version 03 of the draft and suggested to remove this section from the draft since it is not normative and also because this depends on the taste of each SP and their deployment context. A reference to http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-01#page-22 would be sufficient IMHO. "Dynamic vs. Static" and "Port set vs. Individual ports" discussion can be elaborated further in draft-intarea-shared-addressing-issues if required. 

Promoting assigning individual ports and not bulk of ports has aside effects including to increase the log files and it may reduce the number sessions that can be processed simultaneously by the AFTR (i.e., the performance of the AFTR are increased if a port set is allocated instead of individual ports). At least this should be mentioned.

I re-iterate my suggestion to remove this section from the core text of the draft. 

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Rémi Després
Envoyé : mercredi 11 août 2010 17:38
À : Softwires
Cc : Ralph Droms
Objet : [Softwires] dual-stack-lite-06 - Too biased against static port sharing

Helo all,

Regards,
RD

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Aug 2010 14:13:09 +0200

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Aug 2010 14:42:38 +0200

Hi Ralph,

Please ignore the previous message, prematurely sent with no substance in it (apologies).

> traffic to IPv6 servers just bypasses dual-stack lite altogether, right, so the limitation doesn't apply to that traffic?

Right.
Using IPv6 where possible is therefore the best approach against port shortage in IPv4.

>> 3. Where applicable static sharing is much simpler to operate.

Apparently, this point should be better documented in IETF.
Would draft-ietf-intarea-shared-addressing-issues-01 be a good place for that?

>> If the principle is agreed, I can propose detailed words myself to improve the draft.

Med has independently suggested to just delete the section on static vs dynamic port allocations from the DS-lite draft.
This would be sufficient to cover my point in this draft.

Regards,
RD

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Aug 2010 07:09:53 -0700

I think a lot of the text in section 8.4.1 is a matter of opinion or speculation; perhaps it would be better to describe the pros and cons of dynamic and fixed port assignment without making a recommendation before we have much deployment experience.

- Ralph

On Aug 11, 2010, at 6:50 PM 8/11/10, Alain Durand wrote:

> The later part of this comment is IMHO a matter of opinion...
> It is very hard to know for sure how much IPv4 translation will be needed in the feature.

---

From: Alain Durand <[email-masked]>
Date: Thu, 12 Aug 2010 09:58:47 -0700

If we want to remove text that is not strictly protocol related, I'll then suggest we take the entire section 8.4 and the Appendix C out.

  - Alain.

---

From: "Yiu L. Lee" <[email-masked]>
Date: Thu, 12 Aug 2010 18:44:08 -0400

If 8.4 and Appendix C cause any concern, I agree with Alain to remove both
sections.

On 8/12/10 10:09 AM, "Ralph Droms" <[email-masked]> wrote:

> I think a lot of the text in section 8.4.1 is a matter of opinion or
> speculation; perhaps it would be better to describe the pros and cons of
> dynamic and fixed port assignment without making a recommendation before we
> have much deployment experience.
> 
> - Ralph
> 
>>>> 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.
>> 
>> The major issue with any scheme that allocates a fixed number of ports is
>> what do you do when that number is exhausted?
>> How do you even know this is happening? This may or may bot be an issue if we
>> are talking about 10k ports per customers,
>> but as pressure mounts on the IPv4 space and the address compression ratio
>> need to be increased, you soon end-up with much less ports per customers. And
>> then what?
>> 
>> 
>> Logs can indeed be simpler to manage, sure. But this is a trade-off. Other
>> parts of the systems are more complex, see above.
>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 13 Aug 2010 10:46:50 +0200

> If 8.4 and Appendix C cause any concern, I agree with Alain to remove both

+1 to delete them.
RD

---

From: Francis Dupont <[email-masked]>
Date: Wed, 18 Aug 2010 21:48:08 +0200

In your previous mail you wrote:

   We have raised this point during the last call which has been
   issued on version 03 of the draft and suggested to remove this
   section from the draft since it is not normative and also because
   this depends on the taste of each SP and their deployment
   context. A reference to http://tools.ietf.org/html/
   draft-ietf-intarea-shared-addressing-issues-01#page-22
   would be sufficient IMHO. "Dynamic vs. Static" and "Port set
   vs. Individual ports" discussion can be elaborated further in
   draft-intarea-shared-addressing-issues if required.
   
=> IMHO it is the best option (and to make the draft smaller is
a good goal :-).

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 18 Aug 2010 21:50:17 +0200

If we want to remove text that is not strictly protocol related,
   I'll then suggest we take the entire section 8.4 and the Appendix C
   out.
   
=> +1