Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Dear Qiong, Yes, port ranges can be used in a CGN-based architecture too to reduce log file volume as discussed in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02#section-3.1.3 but then you should be aware you loose a feature offered by the CGN which is: * The possibility to log the destination IP address for legal storage purposes in case the server does not implement RFC6302. If RFC6302 is largely deployed, then this feature is not needed. There are a lot of trade-offs and there is no universal answers to these trade-offs. Cheers, Med De : Qiong [mailto:bingxu...@gmail.com] Envoyé : mardi 16 août 2011 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc Škoberne; softwires@ietf.org; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi, Med, and Nejc, Please see inline. You indeed loose agressive sharnig ratio, but you have somewhat more flexible addressing. Also, the CPEs can be then really simple devices, excluding any of the NAPT functionality, doing only stateless encapsulation. However, what you loose/gain is irrelevant for my point. I think this section should be modified in a way like the logging section or any other appropriate way, which explains, that this is not the benefit of the stateless nature, but rather the benefit of the static port allocation. [Qiong]: +1 Agree. Med: Your point is valid and the text should be updated accordingly. My comment aims to show that the comparison is not so that trivial. We can claim the stateful with port ranges can provide similar features as the stateless or the binding mode but we always forget to mention this lead to loose one of the characteristics of the stateful. We captured a similar discussion in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-01#section-4.2: [Qiong]: In our situation, we do not regard aggressive sharing ratio as a vital important feature since the static port multiplex ratio is already enough for us. Besides, even for session-based CGN like ds-lite, we would still prefer to pre-define port-range for customers because our centralized log server can not deal with massive session-based log events. So it seems more reasonable for us to adopt static port arrangement which can largely reduce the log volume. Best regards Qiong Sun 5.2. Port Utilisation Efficiency CGN-based solutions, because they can dynamically assign ports, provide better IPv4 address sharing ratio than stateless solutions (i.e., can share the same IP address among a larger number of customers). For Service Providers who desire an aggressive IPv4 address sharing, a CGN-based solution is more suitable than the stateless. If a Service Provider adopts an aggressive address sharing ratio, it is likely to be attempted by enforcing a NAT port overloading mode and as a consequence some applications will break. However, as more and more hosts become dual-stack enabled, the need for ports in IPv4 is likely to decrease. The insurance to have the full set of 64K ports per host will be one of the incentives to have them IPv6 capable. Moreover, Service Providers should offload some services to IPv6 (e.g., DNS, VoIP). ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
From: Qiong [mailto:bingxu...@gmail.com] Sent: Wednesday, August 17, 2011 12:29 AM To: BOUCADAIR Mohamed OLNC-NAD-TIP Cc: softwires@ietf.org; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi, Med, and Nejc, Please see inline. You indeed loose agressive sharnig ratio, but you have somewhat more flexible addressing. Also, the CPEs can be then really simple devices, excluding any of the NAPT functionality, doing only stateless encapsulation. However, what you loose/gain is irrelevant for my point. I think this section should be modified in a way like the logging section or any other appropriate way, which explains, that this is not the benefit of the stateless nature, but rather the benefit of the static port allocation. Xiaohong: It's a trade-off between efficiency of log and address sharing ratio for stateful solution. I do agree it's a good trade-off for stateful, but one more good option for stateful doesn't make stateless less valuable, so neither see it is too much to do with stateless motivation, nor think it is necessary to document too much in the stateless motivation draft, as long as the stateless motivation is more focused on the requirement of stateless other than comparisons between the two. [Qiong]: +1 Agree. Med: Your point is valid and the text should be updated accordingly. My comment aims to show that the comparison is not so that trivial. We can claim the stateful with port ranges can provide similar features as the stateless or the binding mode but we always forget to mention this lead to loose one of the characteristics of the stateful. We captured a similar discussion in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-01#section-4.2: [Qiong]: In our situation, we do not regard aggressive sharing ratio as a vital important feature since the static port multiplex ratio is already enough for us. Besides, even for session-based CGN like ds-lite, we would still prefer to pre-define port-range for customers because our centralized log server can not deal with massive session-based log events. So it seems more reasonable for us to adopt static port arrangement which can largely reduce the log volume. Xiaohong: I suppose you're saying it is valuable to you to have this trade-off for stateful. Personally, I do see its value too, but again it is not too much to do with stateless motivation. Cheers, Xiaohong Best regards Qiong Sun 5.2. Port Utilisation Efficiency CGN-based solutions, because they can dynamically assign ports, provide better IPv4 address sharing ratio than stateless solutions (i.e., can share the same IP address among a larger number of customers). For Service Providers who desire an aggressive IPv4 address sharing, a CGN-based solution is more suitable than the stateless. If a Service Provider adopts an aggressive address sharing ratio, it is likely to be attempted by enforcing a NAT port overloading mode and as a consequence some applications will break. However, as more and more hosts become dual-stack enabled, the need for ports in IPv4 is likely to decrease. The insurance to have the full set of 64K ports per host will be one of the incentives to have them IPv6 capable. Moreover, Service Providers should offload some services to IPv6 (e.g., DNS, VoIP). ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Softwire Interim meeting
Le 17 août 2011 à 10:08, Ole Troan a écrit : ... Yong and I would like to make a decision soon, please send us email directly if you intend to come and tell us which set of dates is more convenient. Please respond by August 11th, we will formally announce the meeting with the logistic information end of next week. a real life meeting to hash out the stateless solutions is a splendid idea. But an expensive one too! Since the announced deadline for practical organization has already been passed, I personally believe that a better approach is to get enough Softwire time in Taipei for enough WG work. In the mean time, it looks like the mailing-list is working well. Last point, hashing out solutions will be more efficient in Taipei if based on available drafts at that time. Regards, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] SA46T questions
Dear Naoki, However, in my honest opinion, I am confused a little about target technology in softwire. Well, me too. This is why I am trying very hard lately to understand things first. SA46T and SA46T-AS is just a tunneling technology. The other side, in my understanding, DS-Lite and 4rd is combination technology of tunneling and NAT. For DS-Lite, I agree. However, for 4rd NAT is not necessary. As 4rd draft says: Although 4rd is designed primarily to support IPv4 deployment to a customer site (such as a residential home network) by an SP, it can equally be applied to an individual host acting as a CE router. So if you have a host, acting as a CE router, supporting 4rd technology, you don't need NAPT44 in it. So in this regard, it is completely the same as SA46T-AS. At least this is how I understand it. In my understanding, DS-Lite is CGN + Tunneling combination, so CGN + SA46T combination may possible. I think this combination may say DS-Lite. I wouldn't use DS-Lite in any other context, since it is now an independent Proposed Standard. It is as it is. The tunneling there is clearly specified. To similar, 4rd make NAT in CPE assumption. I don't understand 4rd is just tunneling function, or combination with CPE NAT. In the standing point of SA46T-AS, as you point out, SA46T-AS + CPE NAT combination may possible. See above. Both DS-Lite and 4rd is the combination technology for access network. However, I also have interests to apply SA46T-AS to the server environment. Well, not necessarily, why? It's just a technology, I can't see why you couldn't use it in an enterprise as well? I think your trade-off analysis is very important. If adding SA46T/SA46T-AS technology to your analysis table, I think DS-Lite + SA46T and SA46T-AS + CPE NAT is appropriate. Well, I don't agree with DS-Lite + SA46T, I would rather make it SA46T + CGN. However, since your SA46T-AS already is an address sharing solution and it mentions NAT in one of the scenarios (in the draft), I don't think it needs to be combined with anything. So in the end, we have (regarding SA46T): - SA46T (tunneling only) - SA46T+CGN (NAPT44 placed in the core) - SA46T-AS (directly implemented in the host or NAPT44 placed in the CPE) Do you agree? Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] draft-murakami-softwire-4v6-translation
Dear authors, as far as I can understand your draft, you make NAPT44 in the CE obligatory. However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight 4over6 A+P drafts. So I suggest that you make it optional in 4via6 translation as well, since it might be desired for some environments to connect hosts supporting 4via6 translation technology, directly to the IPv6 network. In this case, you don't need the translator. Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Softwire Interim meeting
On 2011-08-17 04:08, Ole Troan wrote: it would be good to have at least 4 weeks notice for travel arrangements to be made. Not only would it be good, it is required. http://www.ietf.org/iesg/statement/interim-meetings.html If we are to meet on September 15-16, the meeting must be announced today. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-murakami-softwire-4v6-translation
Dear Nejc, as far as I can understand your draft, you make NAPT44 in the CE obligatory. [Gang] Yes. This is to avoid the problem where there are applications that attempt to bind to specific ports that are not part of the allowed port range. However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight 4over6 A+P drafts. [Gang] I guess this is always the case for port constrained mechanisms. So I suggest that you make it optional in 4via6 translation as well, since it might be desired for some environments to connect hosts supporting 4via6 translation technology, directly to the IPv6 network. In this case, you don't need the translator. [Gang] Could you help to elaborate the environment ? Many thanks Gang ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-murakami-softwire-4v6-translation
Dear Gang, as far as I can understand your draft, you make NAPT44 in the CE obligatory. [Gang] Yes. This is to avoid the problem where there are applications that attempt to bind to specific ports that are not part of the allowed port range. Well, if the application/operating system supports the standard/protocol/technology, then it should only bind to the port, which CPE would normally use to translate source ports of the packets. If there is no such operating system/application, NAPT44 must be used, of course. However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight 4over6 A+P drafts. [Gang] I guess this is always the case for port constrained mechanisms. Of course. But you could support various scenarios in the scope of your draft, not only the common CPE one. So I suggest that you make it optional in 4via6 translation as well, since it might be desired for some environments to connect hosts supporting 4via6 translation technology, directly to the IPv6 network. In this case, you don't need the translator. [Gang] Could you help to elaborate the environment ? Sure. I can imagine a Linux implementation of 4via6 translation support. If enabled, the TCP/IP stack would only bind to specific ports (from the range). If you check the section III./C of the following paper: http://zhuyc.info/globecom08mivi.pdf the authors propose a modification to the system call related to bind() in the socket library of the operating system. Then I could just connect my home gateway-server directly to the ISPs network, providing support for 4via6 translation and that's it. Also, I see is as a use case in non-ISP environments, where you could have IPv6-only, but 4via6 enabled server networks, with servers supporting 4via6 translation. Like SA46T-AS, for example. The main advantage of all this is of course that the IPv4 address is then natively configured on the (virtual) interface. -- Other than that, I still am very curious what are the differences between your draft and draft-xli-behave-divi-03. I would be very happy if you could elaborate on that. Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Softwire Interim meeting
a real life meeting to hash out the stateless solutions is a splendid idea. But an expensive one too! Since the announced deadline for practical organization has already been passed, I personally believe that a better approach is to get enough Softwire time in Taipei for enough WG work. +1 Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-murakami-softwire-4v6-translation
Dear Nejc, On 2011/08/17, at 22:58, Nejc Škoberne wrote: Dear Gang, as far as I can understand your draft, you make NAPT44 in the CE obligatory. [Gang] Yes. This is to avoid the problem where there are applications that attempt to bind to specific ports that are not part of the allowed port range. Well, if the application/operating system supports the standard/protocol/technology, then it should only bind to the port, which CPE would normally use to translate source ports of the packets. If there is no such operating system/application, NAPT44 must be used, of course. However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight 4over6 A+P drafts. [Gang] I guess this is always the case for port constrained mechanisms. Of course. But you could support various scenarios in the scope of your draft, not only the common CPE one. We assume that all applications/OSes doesn't aware port restricted environment. However, there is a case where an application would be allocated a port which is inside of port set occasionally. So I suggest that you make it optional in 4via6 translation as well, since it might be desired for some environments to connect hosts supporting 4via6 translation technology, directly to the IPv6 network. In this case, you don't need the translator. [Gang] Could you help to elaborate the environment ? Sure. I can imagine a Linux implementation of 4via6 translation support. If enabled, the TCP/IP stack would only bind to specific ports (from the range). If you check the section III./C of the following paper: http://zhuyc.info/globecom08mivi.pdf the authors propose a modification to the system call related to bind() in the socket library of the operating system. The modification of 'to the system call related to bind()' is out of scope in our draft. Then I could just connect my home gateway-server directly to the ISPs network, providing support for 4via6 translation and that's it. Also, I see is as a use case in non-ISP environments, where you could have IPv6-only, but 4via6 enabled server networks, with servers supporting 4via6 translation. Like SA46T-AS, for example. The main advantage of all this is of course that the IPv4 address is then natively configured on the (virtual) interface. -- Other than that, I still am very curious what are the differences between your draft and draft-xli-behave-divi-03. I would be very happy if you could elaborate on that. IMHO, address mapping rule and port distribution algorithm are the difference. Let me think that if 4rd is configured with 'DomainIPv6Prefix == 2001:db8::/32', 'CEIPv6PrefixLength == /72' and 'Domain4rdPrefix == 0/0' for example. 40bits EA-bits are divided to 32bits IPv4 address part and 8bits port-set ID part. The length of the port-set ID expresses that address sharing ratio. The bits pattern of the port-set ID expresses port-set index of modulo operation, described in the divi. cheers, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] are multiple Domain IPv6 prefixes possible?
It seems to me, when delegating CE ipv6 prefix, a longest match might be used. But when forwarding a IPv4 packet, a longest match is useless, because domain 4rd prefixes don't overlap. Thanks, washam 2011/8/17 Rémi Després despres.r...@laposte.net: Le 17 août 2011 à 03:10, Jacni Qin a écrit : hi Remi, On 8/16/2011 4:27 PM, Rémi Després wrote: ... As already discussed privately, I don't know realistic cases where two rules would have IPv6 or IPv4 overlapping prefixes. Consequently, it seems that longest match, while being permitted, doesn't need to be a requirement. If there are multiple ways for CPE to decide the IPv6 prefix, we have to specify the order of priority. e.g., firstly check if there is any implication assigned along with the rules, no? then choose the longest match. BTW, I think the longest match is not bad. It isn't bad, agreed, because it gives the same result as first match when prefixes don't overlap. It shouldn't however be made a _requirement_ if there is no well understood use case because that additional complexity, small but real. Whether there may be realistic configurations where prefix overlap is useful remains AFAIK an open question. I have serious doubts, but no time now to argue in details. IMHO, It's up to those who argue in favor of longest match to provide at least one realistic example (if there is one). Then we will agree (or discuss). Is that fair? Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
