Hi Nejc,
Thanks for this contribution.
+1 to have it pursued.
Maybe it would be better to only cover specifications for which drafts are
available.
(I found the two DSlite? columns confusing, with no document to check their
validity.)
Also, some of us are currently working on separating the
Dear Rémi,
Maybe it would be better to only cover specifications for which drafts are
available.
(I found the two DSlite? columns confusing, with no document to check their
validity.)
I considered this, but then decided to do it this way since as far as I
understand, DS-Lite RFC doesn't
Le 16 août 2011 à 11:23, Nejc Škoberne a écrit :
Dear Rémi,
Maybe it would be better to only cover specifications for which drafts are
available.
(I found the two DSlite? columns confusing, with no document to check
their validity.)
I considered this, but then decided to do it this
Hello Nejc,
your comparison does not appear to include:
http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00
Also, feel free to use/refer to the table in:
http://tools.ietf.org/html/draft-dec-stateless-4v6-02#section-4.1 , which
although being specific to the stateless variants,
Dear Wojciech,
your comparison does not appear to include:
http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00
Interesting. I guess the idea is the same as in draft-xli-behave-divi-03? Could
you please elaborate a bit on the differences?
Also, feel free to use/refer to the
Dear Reinaldo,
This could be a separate table. The good thing about this table is that is
clean and focused.
I don't think that extending this table on another page will make it less
clean and focused.
Nejc
___
Softwires mailing list
|-Original Message-
|From: Simon Perreault [mailto:simon.perrea...@viagenie.ca]
|Sent: Friday, August 12, 2011 9:22 PM
|To: DENG Xiaohong ESP/PEK
|Cc: raj...@cisco.com; despres.r...@laposte.net; softwires@ietf.org
|Subject: Re: [Softwires] Clarification of the
|stateles/stateful
-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf
Of Simon Perreault
Sent: Friday, August 12, 2011 10:01 AM
To: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
On 2011-08-11 16:00, Nejc Škoberne wrote:
The PDF
and infrastructures.
Cheers,
Rajiv
-Original Message-
From: Reinaldo Penno [mailto:rpe...@juniper.net]
Sent: Friday, August 12, 2011 12:26 PM
To: Rajiv Asati (rajiva); Simon Perreault; softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
: Wednesday, August 10, 2011 5:35 AM
| To: despres.r...@laposte.net; Rajiv Asati (rajiva)
| Cc: softwires@ietf.org
| Subject: RE: [Softwires] Clarification of the stateles/stateful
|discussion
|
|
|
| |-Original Message-
| |From: Rémi Després [mailto:despres.r...@laposte.net]
| |Sent: Wednesday
of the stateles/stateful
| discussion
|
|
|
| |-Original Message-
| |From: Rémi Després [mailto:despres.r...@laposte.net]
| |Sent: Wednesday, August 03, 2011 4:02 PM
| |To: Rajiv Asati (rajiva)
| |Cc: softwires@ietf.org
| |Subject: Re: [Softwires] Clarification of the stateles/stateful
On 2011-08-11 07:01, xiaohong.d...@orange-ftgroup.com wrote:
But I don't understand will the figure be different with 'scattered'
port-set NAT? To my knowledge, it's something todo with app's
behaviours and NAT type(EIM in our test). Would you explain if I miss
something? Thanks
As it was
Hello all,
I am working on a trade-off analysis of IPv4 address sharing mechanisms. I am
replying to Remi's e-mail (sent before I subscribed to the list):
I therefore worked out a way to present the range of solutions to be
compared,
with the following taken in consideration:
- The
: xiaohong.d...@orange-ftgroup.com [mailto:xiaohong.deng@orange-
ftgroup.com]
Sent: Wednesday, August 10, 2011 5:35 AM
To: despres.r...@laposte.net; Rajiv Asati (rajiva)
Cc: softwires@ietf.org
Subject: RE: [Softwires] Clarification of the stateles/stateful discussion
|-Original
Asati (rajiva)
Cc: softwires@ietf.org
Subject: RE: [Softwires] Clarification of the stateles/stateful
discussion
|-Original Message-
|From: Rémi Després [mailto:despres.r...@laposte.net]
|Sent: Wednesday, August 03, 2011 4:02 PM
|To: Rajiv Asati (rajiva)
|Cc: softwires@ietf.org
Hi Qiong,
in fact, 4rd doesn't require specific format to ipv6 address.
what do you find in 4rd?
--satoru sent from my iPad
On 2011/08/09, at 15:48, Qiong bingxu...@gmail.com wrote:
Hi Yiu, Jacni,
On Tue, Aug 9, 2011 at 9:25 AM, Lee, Yiu yiu_...@cable.comcast.com wrote:
So the only
Hi, Qiong,
Le 9 août 2011 à 08:43, Qiong a écrit :
Hi, Remi,
Thanks for your interests on 'Lightweight 4over6'. Please see inline.
Clarifying what is meant by stateless in different contexts is highly
desirable.
The objective of the 4rd address mapping is
- no per customer state in
Hi Satoru,
I think you answered your question. As you said, it is possible to use 1
port (in theory) to reach 2000 sessions as long as each destination is
different. So given user 256 ports could create a much larger set of NAT
sessions in the CGN.
Cheers,
Yiu
On 8/2/11 2:33 AM, Satoru
satoru.matsush...@gmail.commailto:satoru.matsush...@gmail.com, Jan Zorz @
go6.si j...@go6.simailto:j...@go6.si,
softwires@ietf.orgmailto:softwires@ietf.org
softwires@ietf.orgmailto:softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
In our
...@go6.si, softwires@ietf.org mailto:softwires@ietf.org
softwires@ietf.org mailto:softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
In our consideration, lightweight AFTR is not doing port-range
routing. In this lightweight AFTR, it would firstly
To: Yiu L. LEE yiu_...@cable.comcast.commailto:yiu_...@cable.comcast.com
Cc: Qiong bingxu...@gmail.commailto:bingxu...@gmail.com,
softwires@ietf.orgmailto:softwires@ietf.org
softwires@ietf.orgmailto:softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
hi
...@gmail.com mailto:bingxu...@gmail.com,
softwires@ietf.org mailto:softwires@ietf.org softwires@ietf.org
mailto:softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
hi,
If I understand it correctly, a per user address/port mapping table is
maintained
Hi Yiu and all,
Agree that the CE-CE communication will be possible for LW AFTR because the
rules are not store in the CE but in the LW AFTR.
Should be CE--LW AFTR--CE style, is that what you mean
here?
But my main question is both technical are so similar, can we have a
@ietf.orgmailto:softwires@ietf.org
softwires@ietf.orgmailto:softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
hi Yiu,
On 8/9/2011 10:28 AM, Lee, Yiu wrote:
Agree that the CE-CE communication will be possible for LW AFTR because the
rules are not store
Couple thoughts.
1. The current draft doesn't specify the static mapping rule like what 4rd
does. So I guess we can't compare this to 4rd.
2. I keep thinking what are the difference of this and PRR. I guess
Qiong's PRR definition is the forwarding decision would be done in the
FIB. I don't
Hi Yiu,
Agree, both.
Couple thoughts.
1. The current draft doesn't specify the static mapping rule like what 4rd
does. So I guess we can't compare this to 4rd.
2. I keep thinking what are the difference of this and PRR. I guess
Qiong's PRR definition is the forwarding decision would be done in
Quiong,
Clarifying what is meant by stateless in different contexts is highly
desirable.
The objective of the 4rd address mapping is
- no per customer state in provider nodes (BR, AFTR...)
- direct customer-customer paths made possible
The 'Lightweight 4over6' proposal has in my understanding
On 2011-08-03 16:44, Tetsuya Murakami wrote:
So the 900G figure is valid *in theory*, but *in practice* we're
stuck with a number of sessions roughly equal to the number of
external ports available on the NAT.
As I mentioned above, the number of NAT session can be greater than
the available
On Aug 4, 2011 5:26 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
On 2011-08-03 16:44, Tetsuya Murakami wrote:
So the 900G figure is valid *in theory*, but *in practice* we're
stuck with a number of sessions roughly equal to the number of
external ports available on the NAT.
On 2011-08-04 11:01, Cameron Byrne wrote:
Yes, because these NATs are endpoint-dependent, which is forbidden by
the BEHAVE RFCs.
It is still very usefull and will be deployed regardless.
Right. But the IETF needs consistency in the advice it provides.
I understand you need to keep your
Hi Simon,
On 2011/08/04, at 5:26, Simon Perreault wrote:
On 2011-08-03 16:44, Tetsuya Murakami wrote:
So the 900G figure is valid *in theory*, but *in practice* we're
stuck with a number of sessions roughly equal to the number of
external ports available on the NAT.
As I mentioned above,
On 8/4/11 8:04 AM, Simon Perreault simon.perrea...@viagenie.ca wrote:
On 2011-08-04 11:01, Cameron Byrne wrote:
Yes, because these NATs are endpoint-dependent, which is forbidden by
the BEHAVE RFCs.
It is still very usefull and will be deployed regardless.
Right. But the IETF needs
: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org]
On Behalf
Of Simon Perreault
Sent: Tuesday, August 02, 2011 9:55 AM
To: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful
discussion
Simon Perreault wrote, on 08/02/2011 09:24 AM:
Satoru Matsushima
To: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful
discussion
Simon Perreault wrote, on 08/02/2011 09:24 AM:
Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
Thanks, a clarification has made to clear a confusion of restricted
port
set/ranges and NAT
On 2011-08-03 09:32, Rémi Després wrote:
I think there is an important point missing from this discussion. It is
tricky but it has important practical consequences.
As I said, The 900G figure is valid, *as long as internal hosts reuse
the same source address+port for different destinations*.
Le 3 août 2011 à 18:04, GangChen a écrit :
2011/8/3, Rémi Després despres.r...@laposte.net:
Also, one should not forget that assigning full IPv4 addresses to DSL
customers who need it remains possible with stateless solutions (presumably
at a price, but we know there is no free lunch).
On 2011/08/02, at 12:10, Jacni Qin wrote:
hi Jan,
On 8/1/2011 10:36 PM, Jan Zorz @ go6.si wrote:
On 8/1/11 1:07 PM, Satoru Matsushima wrote:
So my question is that how dynamic is dynamic, and how static is
static. The analogy of dynamic routing is that dynamic for updating
routing
Hi Lee,
Thank you very much for your interests on 'lightweight 4over6'.
In our consideration, lightweight AFTR is not doing port-range routing. In
this lightweight AFTR, it would firstly lookup a mapping table (recording
[IPv6 address, IPv4 address, Port set]) for a downstream IPv4 packet. Then
On 2011/08/02, at 5:14, Jan Zorz @ go6.si wrote:
On 8/1/11 5:04 PM, Qiong wrote:
So, this is a problem about how to define appropriate port set for our
customers, or to define maximum concurrent subscribers for a given IPv4
address pool. Otherwise, there would either be a waste of resource,
Hi Yiu,
One clarification.
On 2011/08/02, at 2:29, Lee, Yiu wrote:
Actually, Orange Lab did some tests on A+P. They published the results in
v6ops:
http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results-01
In their tests, bittorrent seems use most ports (200). Other
hi Jan,
On 8/1/2011 10:36 PM, Jan Zorz @ go6.si wrote:
On 8/1/11 1:07 PM, Satoru Matsushima wrote:
So my question is that how dynamic is dynamic, and how static is
static. The analogy of dynamic routing is that dynamic for updating
routing information for prefixes but forwarding plane is
Hi Simon,
On 8/1/2011 10:45 PM, Simon Perreault wrote:
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in port-set/range, end
user can exhaust them.
The fact that most ISPs have been successfully operating with 65536 ports per
Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
Thanks, a clarification has made to clear a confusion of restricted port
set/ranges and NAT session table limitation. Even if a CPE is allocated 256
ports, NAT session can be made over 900G sessions in theory. ('2^32'Full
32bits v4 address -
Simon Perreault wrote, on 08/02/2011 09:24 AM:
Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
Thanks, a clarification has made to clear a confusion of restricted port
set/ranges and NAT session table limitation. Even if a CPE is allocated 256
ports, NAT session can be made over 900G sessions
Perreault
Sent: Tuesday, August 02, 2011 9:55 AM
To: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful
discussion
Simon Perreault wrote, on 08/02/2011 09:24 AM:
Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
Thanks, a clarification has made to clear
On 7/29/11 11:41 AM, Rémi Després wrote:
Dear all,
Dave rightly expresses in the Softwire meeting the need to separate/clarify
discussion about:
- Stateless vs stateful
– Static vs dynamic port sets
Does this belong to softwires anymore? New WG maybe?
Cheers, Jan Zorz
On 7/30/11 3:38 PM, Satoru Matsushima wrote:
On 2011/07/30, at 8:26, Peng Wu wrote:
a) Stateful+Dynamic port sets: e.g. DS-Lite
b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06
c) Stateless + Static port set: e.g. 4rd, 4via6 translation
d) Stateless + Dynamic port set:
Well, A+P got enormous amounts of criticism because there was no dynamic
allocations of additional ports.
Now we don't need that anymore, just because stateless solution can't handle
it by design?
I love stateless a+p flavors, but imho we'll need both solutions, stateless
and
Hi, Satoru,
Yes, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address
sharing. But 'lightweight 4over6' has mentioned IPv4 address sharing.
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt
Thanks
Best wishes
Qiong Sun
On Sat, Jul 30, 2011 at 9:57 PM,
Hi Qiong,
On 2011/08/01, at 19:06, Qiong wrote:
Hi, Satoru,
Yes, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address
sharing. But 'lightweight 4over6' has mentioned IPv4 address sharing.
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt
Thanks, I got
On 2011/08/01, at 18:26, Jan Zorz @ go6.si wrote:
Well, A+P got enormous amounts of criticism because there was no dynamic
allocations of additional ports.
Now we don't need that anymore, just because stateless solution can't handle
it by design?
I love stateless a+p flavors, but imho
Le 1 août 2011 à 12:06, Qiong a écrit :
Hi, Satoru,
Yes, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address
sharing. But 'lightweight 4over6' has mentioned IPv4 address sharing.
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt
Thanks for the
Le 1 août 2011 à 11:26, Jan Zorz @ go6.si a écrit :
On 7/30/11 3:38 PM, Satoru Matsushima wrote:
On 2011/07/30, at 8:26, Peng Wu wrote:
a) Stateful+Dynamic port sets: e.g. DS-Lite
b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06
c) Stateless + Static port set: e.g. 4rd,
Le 1 août 2011 à 15:36, Rajiv Asati (rajiva) a écrit :
... Interesting enough, the static port-set is one of the reasons why many
find 4v6 being so useful.
Indeed: operation simplicity, scalability, possible direct CE-CE paths.
Very legitimate.
Regards,
RD
On 8/1/11 4:22 PM, Rémi Després wrote:
Le 1 août 2011 à 15:36, Rajiv Asati (rajiva) a écrit :
... Interesting enough, the static port-set is one of the reasons why many
find 4v6 being so useful.
Indeed: operation simplicity, scalability, possible direct CE-CE paths.
Very legitimate.
Let
On 8/1/11 1:07 PM, Satoru Matsushima wrote:
So my question is that how dynamic is dynamic, and how static is
static. The analogy of dynamic routing is that dynamic for updating
routing information for prefixes but forwarding plane is stateless.
If you imagine dynamic port ranges within
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in port-set/range,
end
user can exhaust them.
The fact that most ISPs have been successfully operating with 65536 ports per
subscriber demonstrates that it is possible to statically
] Clarification of the stateles/stateful discussion
On 8/1/11 4:22 PM, Rémi Després wrote:
Le 1 août 2011 à 15:36, Rajiv Asati (rajiva) a écrit :
... Interesting enough, the static port-set is one of the reasons why many
find 4v6 being so useful.
Indeed: operation simplicity
-boun...@ietf.org]
On Behalf
Of Simon Perreault
Sent: Monday, August 01, 2011 10:45 AM
To: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful
discussion
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign
...@ietf.org [mailto:softwires-boun...@ietf.org]
On Behalf
Of Jan Zorz @ go6.si
Sent: Monday, August 01, 2011 10:37 AM
To: Satoru Matsushima
Cc: softwires@ietf.org
Subject: Re: [Softwires] Clarification of the stateles/stateful
discussion
On 8/1/11 1:07 PM, Satoru Matsushima wrote:
So my
Hi, Jan,
I guess this kind of port exhaustion problem will also exist in dynamic CGN.
Assume the average port number consumed by average subscribers are 2000
(around 32 users per public IPv4 address) and this CGN has 32 concurrent
users at that time with the only public IPv4 address in the
Le 1 août 2011 à 16:31, Jan Zorz @ go6.si a écrit :
On 8/1/11 4:22 PM, Rémi Després wrote:
Le 1 août 2011 à 15:36, Rajiv Asati (rajiva) a écrit :
... Interesting enough, the static port-set is one of the reasons why many
find 4v6 being so useful.
Indeed: operation simplicity,
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in port-set/range,
end
user can exhaust them.
The fact that most ISPs have been successfully operating with 65536 ports per
subscriber demonstrates that it is possible to statically
Le 1 août 2011 à 17:04, Qiong a écrit :
...
So, this is a problem about how to define appropriate port set for our
customers, or to define maximum concurrent subscribers for a given IPv4
address pool. Otherwise, there would either be a waste of resource, or port
exhaustion.
Maybe we can
Hi, Remi,
Agree. I only mean that for some extreme use cases where higher priority
user would like to apply for more ports. But in the foreseeable future, I
also think that two customer classes would be enough.
Thanks.
On Mon, Aug 1, 2011 at 11:53 PM, Rémi Després despres.r...@laposte.netwrote:
+1
On 7/30/11 9:26 AM, Peng Wu wea...@csnet1.cs.tsinghua.edu.cn wrote:
Hi Gang,
Before making such comparison (of course it should be as fair as
possible),
I think we need to state what solution space we are targeting and what
category mode we should take care.
If I understand correctly, I
You are right. The current 'draft-cui-softwire-host-4over6' describes how
a server is provisioned a public IPv4 address over an IPv6-only network.
IPv4 address sharing wasn't discussed in the draft.
On 7/30/11 9:57 AM, Satoru Matsushima satoru.matsush...@gmail.com
wrote:
AFAIK, the
In this case,
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt
couldn't be controversial because it will turn AFTR a PRR.
On 8/1/11 7:07 AM, Satoru Matsushima satoru.matsush...@gmail.com wrote:
If you imagine dynamic port ranges within stateless, it sounds like port
Actually, Orange Lab did some tests on A+P. They published the results in
v6ops:
http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results-01
In their tests, bittorrent seems use most ports (200). Other public apps
use no more than 100 ports. For a family of 5, I think 2000 ports
Sorry typo: I mean this draft could be controversial.
On 8/1/11 1:18 PM, Lee, Yiu yiu_...@cable.comcast.com wrote:
In this case,
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt
couldn't be controversial because it will turn AFTR a PRR.
On 8/1/11 7:07 AM, Satoru
On 8/1/11 5:04 PM, Qiong wrote:
So, this is a problem about how to define appropriate port set for our
customers, or to define maximum concurrent subscribers for a given IPv4
address pool. Otherwise, there would either be a waste of resource, or
port exhaustion. Maybe we can even make some more
On 8/1/11 5:50 PM, Ole Troan wrote:
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in
port-set/range, end user can exhaust them.
The fact that most ISPs have been successfully operating with 65536
ports per subscriber demonstrates
On 2011/08/02, at 5:21, Jan Zorz @ go6.si wrote:
On 8/1/11 5:50 PM, Ole Troan wrote:
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in
port-set/range, end user can exhaust them.
The fact that most ISPs have been successfully
Hi Gang,
Before making such comparison (of course it should be as fair as possible),
I think we need to state what solution space we are targeting and what
category mode we should take care.
If I understand correctly, I would paraphrase as following categories.
a) Stateful+Dynamic port sets:
One clarification.
On 2011/07/29, at 10:18, GangChen wrote:
Before making such comparison (of course it should be as fair as possible),
I think we need to state what solution space we are targeting and what
category mode we should take care.
If I understand correctly, I would paraphrase as
Dear all,
Dave rightly expresses in the Softwire meeting the need to separate/clarify
discussion about:
- Stateless vs stateful
– Static vs dynamic port sets
The need to clarify is IMHO even larger than that.
I therefore worked out a way to present the range of solutions to be compared,
with
Le 29 juil. 2011 à 17:18, GangChen a écrit :
Before making such comparison (of course it should be as fair as possible),
I think we need to state what solution space we are targeting and what
category mode we should take care.
If I understand correctly, I would paraphrase as following
77 matches
Mail list logo
