Re: [Softwires] Clarification of the stateles/stateful discussion
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 4rd stateless address mapping from its possible application to various encapsulation and translation mechanisms. When done, hopefully soon, this could influence the way to structure your comparison table. Regards, RD Le 11 août 2011 à 22:00, Nejc Škoberne a écrit : 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 stateless/stateful IPv4 across IPv6 comparison isn't limited to IPv4 shared addresses (applies also to exclusive IPv4 customer addresses). - If there is, in BR/AFBR's, no Customer state (i.e. no states referring to individual IPv6 prefixes), there can't be per-transport-connection state either. - CE-CE direct paths are possible only if IPv4/IPv6 mappings of BR/AFBR's don't depend on Customer state. The proposed document structure is as follows, with pros and cons for each section: a) Stateful per transport connection (and also stateful per customer IPv6 prefix) e.g. DS-lite with CGN b) Stateful per customer IPv6 prefix (but Stateless per transport connection) e.g. draft-cui-softwire-host-4over6-06 c) Stateless per customer IPv6 prefix (and also stateless per transport connection) - Hub-an-spoke TBD - Direct CE-CE paths (mesh) . Encapsulation based e.g. draft-murakami-softwire-4rd-00 alias . Translation based e.g. draft-murakami-softwire-4v6-translation-00 I think we really need such a comparison document. As a newcomer I spent a lot of time digging up all the scattered documents here and it wasn't easy grasp the big picture of what has been proposed. I think we also need a trade-off analysis document, which I am writing at the moment. Anyway, I am not sure I agree with the structure suggested. I think we should try to be even more general and try to abstract all packet manipulations. I have prepared a table which tries to document all so-far implemented combinations (IPv4 address sharing mechanisms + 4via6 mechanisms, the intersection includes all but NAT444, which is only IPv4 address sharing mechanism and Public 4over6 which is only a 4via6 mechanism). It would be useful to know if any of the missing combinations might be useful in practice as well, I hope this table will help in determining that. I will be very happy to hear any comments on the comparison. It's only a 1-page table. The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf Thanks, Nejc ___ 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] SA46T questions
Hi. Hejc, (2011/08/15 22:43), Nejc Škoberne wrote: SA46T does not have address sharing mechanism. However, SA46T-AS have address sharing mechanism. That is A+P like mechanism. SA46T-AS is documented in http://tools.ietf.org/html/draft-matsuhira-sa46t-as-01 In this version, two usages is discussed, one is clients environments, and other is server environments. As far as I can see from the SA46T-AS draft, you just embed 16-bit port number in the SA46T-AS address, is this correct? This means, you cannot have a port range, but only 1 port per CPE allocated. I guess I am missing something here? That's depend on prefix length. If prefix length is 128bits, only one port per SA46T-AS tunnel endpoint is allocated. However, If prefix length is 128 - 8 = 120bit, 2^8 = 256 ports per SA46T-AS tunnel endpoint are allocated. And also, if prefix length is 128 - 16 =112bit, 2~16 = 65536 ports per SA46T-AS tunnel endpoint are allocated, and this case dose not share one IP address. Number of ports can be selected by prefix length. Also, you say in the 5th section, that ICMPv4 doesn't work. But for for this, you can make an ALG, like with other address sharing mechanisms? I think having ICMPv4 work is quite a crucial thing in such a mechanism. Yes, your comment is correct. I merely describe a general rule. And I agree your point. --- Question to others: what do you think about this? Should I also include this one into the table of IPv4 address sharing mechanisms? Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Clarification of the stateles/stateful discussion
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 say what IPv4 address and UDP/TCP port allocation policy must be supported. The same goes for provisioning additional IPv4 addresses and port ranges. Is this correct? Also, some of us are currently working on separating the 4rd stateless address mapping from its possible application to various encapsulation and translation mechanisms. When done, hopefully soon, this could influence the way to structure your comparison table. This would indeed be very useful. I will certainly work on it as soon as the document is publicly available. Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Clarification of the stateles/stateful discussion
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 way since as far as I understand, DS-Lite RFC doesn't say what IPv4 address and UDP/TCP port allocation policy must be supported. I see. Then unspecified in the DS-lite column might be another way to express it. BTW, colors don't seem necessary. Without them, one avoids having to decide whether IPv4 address and UDP/TCP port allocation policy is red or green ;-). The same goes for provisioning additional IPv4 addresses and port ranges. Is this correct? Also, some of us are currently working on separating the 4rd stateless address mapping from its possible application to various encapsulation and translation mechanisms. When done, hopefully soon, this could influence the way to structure your comparison table. This would indeed be very useful. I will certainly work on it as soon as the document is publicly available. Excellent. Look forward to it. RD Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] draft-operators-softwire-stateless-4v6-motivation
Hello, I have some comments on your draft, see inline. Regards, Nejc --- 2. Terminology This document makes use of the following terms: Stateful 4/6 solution (or stateful solution in short): denotes a solution where the network maintains user-session states relying on the activation of a NAT function in the Service Providers' network [I-D.ietf-behave-lsn-requirements]. The NAT function is responsible for sharing the same IPv4 address among several subscribers and to maintain user-session state. Stateless 4/6 solution (or stateless solution in short): denotes a solution which does not require any user-session state (seeSection 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. In an IPv4 address sharing context, dedicated functions are required to be enabled in the CPE router to restrict the source IPv4 port numbers. Within this document, port set and port range terms are used interchangeably. [NS: If we consider a stateful A+P solution, we don't necessarily have a dependency between an IPv6 prefix and IPv4 address. Also, we don't have any user-session state in the Service Provider's network. We do, however, have some user state (in order to do stateful tunneling, for example). Maybe this is included in user-session in your terminology, but then I think it would be appropriate to define the term user-session clearly.] ... 3.1.5. Bandwidth Saving In same particular network scenarios (e.g., wireless network ), spectrum is very valuable and scarce resource. Service providers usually wish to eliminate unnecessary overhead to save bandwidth consumption in such environment. Service providers need to consider optimizing the form of packet processing when encapsulation is used. Since existing header compression techniques are stateful, it is expected that stateless solution minimize overhead introduced by the solution. [NS: I don't understand this section, but that may be just me. Maybe is there a better way to explain the point?] ... 3.3.1. Implicit Host Identification Service Providers do not offer only IP connectivity services but also added value services (a.k.a., internal services). Upgrading these services to be IPv6-enabled is not sufficient because of legacy devices. In some deployments, the delivery of these added-value services relies on implicit identification mechanism based on the source IPv4 address. Due to address sharing, implicit identification will fail [I-D.ietf-intarea-shared-addressing-issues]; replacing implicit identification with explicit authentication will be seen as a non acceptable service regression by the end users (less Quality of Experience (QoE)). When a stateless solution is deployed, implicit identification for internal services is likely to be easier to implement: the implicit identification should be updated to take into account the port range and the IPv4 address. Techniques as those analyzed in [I-D.boucadair-intarea-nat-reveal-analysis] are not required for the delivery of these internal services if a stateless solution is deployed. [NS: I don't think this is true only for stateless solutions. If we have a stateful solution with static port allocation (as you mention in section 3.1.3), then implementing such an implicit host identification which uses also port information, is doable as well.] ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Dear Med, [NS: If we consider a stateful A+P solution, we don't necessarily have a dependency between an IPv6 prefix and IPv4 address. Also, we don't have any user-session state in the Service Provider's network. Med: Fully agree. FWIW, this is what we called Binding Table A+P Mode in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4. This is exactly what I had in mind. We do, however, have some user state (in order to do stateful tunneling, for example). Maybe this is included in user-session in your terminology, but then I think it would be appropriate to define the term user-session clearly.] Med: We assumed the definition of state as mentioned in RFC1958; but I agree the terminology should be much more clearer. Yes, state is implicitly defined there, however user-session is not defined anywhere. [NS: I don't think this is true only for stateless solutions. If we have a stateful solution with static port allocation (as you mention in section 3.1.3), then implementing such an implicit host identification which uses also port information, is doable as well.] Med: I Agree. But then you loose other benefits of the stateful: have an aggressive address sharing ratio. 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. Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] are multiple Domain IPv6 prefixes possible?
Hi, 2011/8/16 Rémi Després despres.r...@laposte.net: Hi Tetsuya-san, I agree, of course, on the need to support several mapping rules. Is there anywhere in the draft to mention how to deliver these rules? As my understanding, the provisions described in section 4 only can generate a mapping rule, how about deliver multiple mapping rules. But IMHO one point needs clarification (see below). Le 16 août 2011 à 02:03, Tetsuya Murakami a écrit : Hi Washam, We can allow to use multiple mapping rules in a 4rd domain. ... When delegating an IPv6 prefix from the network, the corresponding mapping rule whose domain ipv6 prefix has the longest match with the delegated ipv6 prefix, can be selected. 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. Have the same feeling, ipv4 prefixes/addresses/port-set don't overlap, per my understanding. Thanks, washam Would you have such use cases to share? Regards, RD Also, when forwarding an IPv4 packet to another CE, the corresponding mapping rule whose domain 4rd prefix has the longest match with the the destination ipv4 address, can be selected. It is stated in section 5.1.1 and section 7 a little bit in the draft. Thanks, Tetsuya Murakami On 2011/08/14, at 5:52, Washam Fan wrote: Hi, It seems to me only one domain IPv6 prefix is allowed, per draft-murakami-softwire-4rd-00. But I see no issue if we allow multiple domain IPv6 prefixes. E.g., when a CE tries to encapsulate a outbound IPv4 package, the matched rule can tell which domain ipv6 prefix can be used for building outer IPv6 destination address. Thanks, washam ___ 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] are multiple Domain IPv6 prefixes possible?
Le 16 août 2011 à 16:06, Washam Fan a écrit : Hi, 2011/8/16 Rémi Després despres.r...@laposte.net: Hi Tetsuya-san, I agree, of course, on the need to support several mapping rules. Is there anywhere in the draft to mention how to deliver these rules? You can look at draft-mrugalski-dhc-dhcpv6-4rd-00. Some update will be necessary, AFAIK, but this gives an idea of what can be done once parameters are agreed on. As my understanding, the provisions described in section 4 only can generate a mapping rule, how about deliver multiple mapping rules. But IMHO one point needs clarification (see below). Le 16 août 2011 à 02:03, Tetsuya Murakami a écrit : Hi Washam, We can allow to use multiple mapping rules in a 4rd domain. ... When delegating an IPv6 prefix from the network, the corresponding mapping rule whose domain ipv6 prefix has the longest match with the delegated ipv6 prefix, can be selected. 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. Have the same feeling, ipv4 prefixes/addresses/port-set don't overlap, per my understanding. Thanks, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hi Rémi, Yes, there was a vote in favour of adopting this document as a WG document but as you know this vote should be confirmed in the ML. A call for adoption should normally be issued by the chairs according to the IETF procedure. As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 16 août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc Škoberne; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org; softwires@ietf.org Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi Med, At the last meeting, a vote was taken to decide whether this draft should become a WG draft. The answer has been a crystal clear yes, with the common understanding that, as such, it would have to be improved and competed based on WG reactions. IMHO, making it a WG document asap will facilitate discussions like this one: thet will point to the right document. Is there any sort term plan to do what was approved? Kind regards, RD Le 16 août 2011 à 13:48, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear Nejc, Thank you for the comments. Please see my answers inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Nejc Škoberne Envoyé : mardi 16 août 2011 12:25 À : draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Cc : softwires@ietf.org Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation Hello, I have some comments on your draft, see inline. Regards, Nejc --- 2. Terminology This document makes use of the following terms: Stateful 4/6 solution (or stateful solution in short): denotes a solution where the network maintains user-session states relying on the activation of a NAT function in the Service Providers' network [I-D.ietf-behave-lsn-requirements]. The NAT function is responsible for sharing the same IPv4 address among several subscribers and to maintain user-session state. Stateless 4/6 solution (or stateless solution in short): denotes a solution which does not require any user-session state (seeSection 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. In an IPv4 address sharing context, dedicated functions are required to be enabled in the CPE router to restrict the source IPv4 port numbers. Within this document, port set and port range terms are used interchangeably. [NS: If we consider a stateful A+P solution, we don't necessarily have a dependency between an IPv6 prefix and IPv4 address. Also, we don't have any user-session state in the Service Provider's network. Med: Fully agree. FWIW, this is what we called Binding Table A+P Mode in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4. We do, however, have some user state (in order to do stateful tunneling, for example). Maybe this is included in user-session in your terminology, but then I think it would be appropriate to define the term user-session clearly.] Med: We assumed the definition of state as mentioned in RFC1958; but I agree the terminology should be much more clearer. ... 3.1.5. Bandwidth Saving In same particular network scenarios (e.g., wireless network ), spectrum is very valuable and scarce resource. Service providers usually wish to eliminate unnecessary overhead to save bandwidth consumption in such environment.
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
mohamed.boucad...@orange-ftgroup.com wrote, on 08/16/2011 11:03 AM: As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed. For me, the first option makes more sense. I also support adoption of this document and am expecting an adoption call soon. 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] SA46T questions
Dear Naoki, Number of ports can be selected by prefix length. I see. So essentially, SA46T-AS is like 4rd, but with a different port-allocation scheme. Also the IPv4 plane feature (you also call it IPv4 VPN service) can be seen as a variant of multiple 4rd domains in 4rd context. Do you agree? If this is so, I don't really see why would we need a separate specification for this? I mean, we could also define various port-allocation schemes in the 4rd draft (as in RFC 6056, where we have various port randomization algorithms available for implementation). Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hello all, It appears that confirming on this list the vote made in Quebec would be useful. Please see below. Le 16 août 2011 à 17:03, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... there was a vote in favour of adopting this document as a WG document but as you know this vote should be confirmed in the ML. I have seen drafts becoming WG drafts after votes during meetings but, fair enough, let's see if, after the unanimous vote in the meeting, there are serious objections to it now. A call for adoption should normally be issued by the chairs according to the IETF procedure. As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, Support. Some of them were worth having, IMHO. add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Sure. Doing this while the draft is already a WG draft seems to me normal after the vote result (but no objection to doing it right away if found better. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. Offline discussions are of course completely free, and useful, but a WG consensus can only be built in the open, i.e. on the WG mailing list. I am aware of at least part of the offline discussion you refer to, and therefore suppose you meant dynamic vs static AND stateful vs _stateless_. Several pointed out, in that discussion, that the stateless dynamic combination doesn't really make sense. In any case, this discussion hasn't been pursued on the WG list. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward So do I, = +1 That is IMHO the only acceptable option in view of the vote result. but I'm open to the opinions of the working group members on how to proceed. Let's see then. Regards to all, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 16 août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc Škoberne; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org; softwires@ietf.org Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi Med, At the last meeting, a vote was taken to decide whether this draft should become a WG draft. The answer has been a crystal clear yes, with the common understanding that, as such, it would have to be improved and competed based on WG reactions. IMHO, making it a WG document asap will facilitate discussions like this one: thet will point to the right document. Is there any sort term plan to do what was approved? Kind regards, RD Le 16 août 2011 à 13:48, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear Nejc, Thank you for the comments. Please see my answers inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Nejc Škoberne Envoyé : mardi 16 août 2011 12:25 À : draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Cc : softwires@ietf.org Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation Hello, I have some comments on your draft, see inline. Regards, Nejc --- 2. Terminology This document makes use of the following terms: Stateful 4/6 solution (or stateful solution in short): denotes a solution where the network maintains user-session states relying on the activation of a NAT function in the Service Providers' network [I-D.ietf-behave-lsn-requirements]. The NAT function is responsible for sharing the same IPv4 address among several subscribers and to maintain user-session state. Stateless 4/6 solution (or stateless solution in short): denotes a solution which does not require any user-session state (seeSection 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. In an IPv4 address sharing context, dedicated functions are required
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.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
On 8/16/11 5:03 PM, mohamed.boucad...@orange-ftgroup.com wrote: 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: This sounds like a great idea. Nejc Škoberne, Olaf Maennel, myself and some others are already working on something similar, but more in form of scientific paper (you know, two columns and so...). RFC with similar content would also be great. Cheers, Jan Zorz ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hi, On 8/16/2011 11:03 PM, mohamed.boucad...@orange-ftgroup.com wrote: ... As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed. In favor of the first. Cheers, Jacni ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] SA46T questions
Nejc, Basically, I think your point is correct, and I agree with you. However, in my honest opinion, I am confused a little about target technology in softwire. 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. In my understanding, DS-Lite is CGN + Tunneling combination, so CGN + SA46T combination may possible. I think this combination may say DS-Lite. 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. 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. 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. Regards, Naoki Matsuhira. (2011/08/17 0:53), Nejc Škoberne wrote: Dear Naoki, Number of ports can be selected by prefix length. I see. So essentially, SA46T-AS is like 4rd, but with a different port-allocation scheme. Also the IPv4 plane feature (you also call it IPv4 VPN service) can be seen as a variant of multiple 4rd domains in 4rd context. Do you agree? If this is so, I don't really see why would we need a separate specification for this? I mean, we could also define various port-allocation schemes in the 4rd draft (as in RFC 6056, where we have various port randomization algorithms available for implementation). Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hi all, |-Original Message- |From: Rémi Després [mailto:despres.r...@laposte.net] |Sent: Wednesday, August 17, 2011 12:28 AM |To: Softwires-wg |Cc: draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org |Subject: Re: [Softwires] |draft-operators-softwire-stateless-4v6-motivation | |Hello all, | |It appears that confirming on this list the vote made in |Quebec would be useful. Agreed. |Please see below. | |Le 16 août 2011 à 17:03, |mohamed.boucad...@orange-ftgroup.com |mohamed.boucad...@orange-ftgroup.com a écrit : | | ... there was a vote in favour of adopting this document as |a WG document but as you know this vote should be confirmed in the ML. | |I have seen drafts becoming WG drafts after votes during |meetings but, fair enough, let's see if, after the unanimous |vote in the meeting, there are serious objections to it now. | | | A call for adoption should normally be issued by the chairs |according to the IETF procedure. | | As for the content of the next iteration of the document, we |have two options so far: | | (1) Put back some sections which have been removed in -02, | |Support. |Some of them were worth having, IMHO. | | add a new section to discuss dynamic vs. static, | | handle the comments received from J. Arkko, etc. | |Sure. |Doing this while the draft is already a WG draft seems to me |normal after the vote result (but no objection to doing it |right away if found better. | | Or | | 2) An alternative structure has been proposed off-line by A. |Durand: discuss dynamic vs. static and stateful vs. dynamic. | |Offline discussions are of course completely free, and useful, |but a WG consensus can only be built in the open, i.e. on the |WG mailing list. |I am aware of at least part of the offline discussion you |refer to, and therefore suppose you meant dynamic vs static |AND stateful vs _stateless_. |Several pointed out, in that discussion, that the stateless |dynamic combination doesn't really make sense. |In any case, this discussion hasn't been pursued on the WG list. | | The analysis would elaborate the pros and cons of each |solution (static stateless, static stateful, dynamic |stateful,...). This document would be an analysis document and |not a motivation document anymore. This document has no |milestone in the charter IMHO. Note the charter mentions the |following: | | Aug 2011 - Adopt stateless legacy IPv4 solution motivation |document as a Working Group document | | | I personally think the first option is straightforward | |So do I, = +1 |That is IMHO the only acceptable option in view of the vote result. +1 Prefer the first option, as discussion dynamic allocation vs. static allocation in a new section other than discussing on the mailing list sounds to me the more practical and efficient one to meet the Chater milstone. Cheers, Xiaohong | | | but I'm open to the opinions of the working group members on |how to proceed. | |Let's see then. | |Regards to all, |RD | | | | Cheers, | Med | | | -Message d'origine- | De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : |mardi 16 | août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc |Skoberne; | draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org; | softwires@ietf.org Objet : Re: [Softwires] | draft-operators-softwire-stateless-4v6-motivation | | Hi Med, | | At the last meeting, a vote was taken to decide whether this |draft should become a WG draft. | The answer has been a crystal clear yes, with the common |understanding that, as such, it would have to be improved and |competed based on WG reactions. | | IMHO, making it a WG document asap will facilitate |discussions like this one: thet will point to the right document. | | Is there any sort term plan to do what was approved? | | Kind regards, | RD | | | | | Le 16 août 2011 à 13:48, |mohamed.boucad...@orange-ftgroup.com |mohamed.boucad...@orange-ftgroup.com a écrit : | | Dear Nejc, | | Thank you for the comments. Please see my answers inline. | | Cheers, | Med | | | -Message d'origine- | De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] | De la part de Nejc Skoberne Envoyé : mardi 16 août 2011 12:25 À : | draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org | Cc : softwires@ietf.org | Objet : [Softwires] |draft-operators-softwire-stateless-4v6-motivation | | Hello, | | I have some comments on your draft, see inline. | | Regards, | Nejc | | --- | 2. Terminology | | | | This document makes use of the following terms: | | Stateful 4/6 solution (or stateful solution in short): denotes a | solution where the network maintains |user-session | states relying on the activation of a NAT | function in the Service Providers' network | [I-D.ietf-behave-lsn-requirements]. The NAT | function is
Re: [Softwires] are multiple Domain IPv6 prefixes possible?
Sorry. I have a typo. The following address has no meaning...
Sorry again.
Tetsuya Murakami
On 2011/08/16, at 21:16, Tetsuya Murakami wrote:
Hi Remi, Jacni,
We are considering the following situation.
Initially, one 4rd mapping rule can be set like {2408:db8::/32, 10.10.0.0/24,
48}. After that, if renumbering is required, the additional mapping rules are
just distributed such as
{2408:db8:100::/40, 10.10.1.0/24, 48}
{2408:db8:200::/40, 10.10.2.0/24, 48}
...
In this case, it is useful to have a longest match to find the suitable
mapping rule.
Thanks,
Tetsuya Murakami
On 2011/08/16, at 18:10, Jacni Qin wrote:
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.
Cheers,
Jacni
Would you have such use cases to share?
Regards,
RD
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] are multiple Domain IPv6 prefixes possible?
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
