Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Dear Gang, Please see inline. Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : samedi 17 septembre 2011 10:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Simon Perreault; softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Dear Med, The logic we adopted for guessing complexity of a valid port and for the whole range is as mentioned in http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2: In each analyzed port derivation algorithm, an attacker may implement a redirection loop to detect a significant amount of allowed ports. For all monotonously scattered schemes, the whole Port-Set may be deduced by extrapolation while this is not applicable for contiguous port ranges (because no information about port bounds is leaked in the IPv4-translatable IPv6 address). It seems same criteria applied for these two properties. But why would you get different complexity level for each property targeting to same algorithm? (e.g. For portrange judgment, Guessing Complexity of a Valid Port is low; Guessing Complexity of the whole Port-Set is Medium) Med: For a contiguous port range, if you know port N it is easy to guess the next port. This is why we indicated Low but since the port range bounds are not leaked in the port itself, it is not easy to guess the whole port (hence the Medium). But still the loop vector above applies for all port set allocation algorithms and under some conditions the server may by itself detects the whole port set. For me, the statement is more proper for whole Port-Set prediction. I guess we need to add texts for valid Port prediction? Med: any text proposal is welcome. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Mohamed, all, First, thanks for the analysis draft. It sounds good. Let me try to bring my thought. An interesting point is here. In the algorithms which define offset to exclude ports such as 1024, 4096 whatever, the efficiency of port utilization is decreased, which algorithm is 4rd, and complexity of calculation are increased, which algorithm is dIVI's modulo, when the number of CEs which share an address exceed the number of excluded ports. For example, in the case of that someone uses modulo with excluding under 1024 port, port-set ID is always placed at last 9 bits in a port if the number of CEs which share one address isn't exceed 1024. But when the number of CEs exceed 1024, complexity of modulo operation will be increased to calculate port set ID from port number at BR and CE. In the case of 4rd, which exclude under 4096 port, if CEs over 4096, which CEs share one address, 8K, 16K, 32K of ports are unusable respectively. To keep simple implementation and operation, I think that offset port and the maximum address sharing ratio should be same. So the question is what is the number. 1024 is small a little. 2048 or 4096? I think that first nibble of port to utilize offsetting is helpful for implementation and is easy to read in hex. So In my opinion, 4096 is adequate for both offset port and maximum sharing ratio. If it would be applied to 4rd, a following figure could be depict. Port-set ID is always placed on right after the first nibble. CE's NAT needs to maintain just only fifteen port ranges, and BR and CE just remove first nibble to pick a port set ID from port number in a packet. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port-set |h h h h|x x x x x x x x| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |head |-Port-set ID-|-tail- 4bits max 12bits (0x1-0xF) Second, I think that the character differences of these analyzed algorithms come from where is port-set ID in a port number. Each algorithms is a result of labor to define where are port-set ID bits. I agree with last paragraph in section 2 that says 'the whole Port-Set may be deduced by extrapolation', so it would be predictable port set regardless of which analyzed algorithm generates. If I add one point to the analysis, that is 'Complexity of CE side NAT ports pool configuration and management', which NAT is already distributed to the fields. Several contiguous port ranges are helpful to configure and manage NAT ports pool. On the other hand, scattered scheme increases complexity of configuration and management as the number of ports in port set increased. So I think that having unique port set derivation for each stateless address sharing domain is important.To make variation of port-set indexing, port-set ID mask option could be helpful. As I'm inspired by a discussion with Xiaohong, the port-set ID mask is used for which bits indicate port-set ID. That bits are fully configurable by each operator's domain. In terms of port-set ID mask configuration, the default port indexing is just one of configuration variation. Please see a following figure. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port-set |h h h h| x x x x x x x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |head | ^ ^ ^ ^ ^ ^ ^ 4bits | | | | | | | (0x1-0xF) | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port-set |0 0 0 0|0 1 0 1 1 0 1 1 0 1 1 0| ID mask +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option -- -- must Port-set ID mask be(‘1’ indicates port-set ID bits) zero I have no draft for that yet, but I'd like to discuss at the interim meeting. Have a good weekend, hope to see you in Beijing, next week. cheers, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Dear Med, The logic we adopted for guessing complexity of a valid port and for the whole range is as mentioned in http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2: In each analyzed port derivation algorithm, an attacker may implement a redirection loop to detect a significant amount of allowed ports. For all monotonously scattered schemes, the whole Port-Set may be deduced by extrapolation while this is not applicable for contiguous port ranges (because no information about port bounds is leaked in the IPv4-translatable IPv6 address). It seems same criteria applied for these two properties. But why would you get different complexity level for each property targeting to same algorithm? (e.g. For portrange judgment, Guessing Complexity of a Valid Port is low; Guessing Complexity of the whole Port-Set is Medium) For me, the statement is more proper for whole Port-Set prediction. I guess we need to add texts for valid Port prediction? Many thanks Gang ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Le 15 sept. 2011 à 14:15, mohamed.boucad...@orange-ftgroup.com a écrit : Hi Rémi, I checked draft-despres-softwire-4rd-addmapping again and you reverse only the L bits identifying the PSID. This is why I'm puzzled how it is possible to support differentiated port sets (which means distinct PSID of distinct length e.g., 4 and 6). Length L used by AFTRs to build IPv6 addresses is in general longer than the (unknown) PSID of the destination CPE. Unless some truncation is needed, in order to the DST subnet prefix to exceed 64 bits), it is L = 14 (top of page 12). BTW, the next version of 4rd-addmapping should include significantly simpler and clearer port-set algorithm. Following in particular your own comments, this algorithm will no longer be influenced by the controversial UPnP friendliness objective. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Satoru-san, Thank you for your question. Answer below. Le 14 sept. 2011 à 05:28, Satoru Matsushima a écrit : Hi Remi-san, I have one question. On 2011/09/14, at 2:42, Rémi Després wrote: Le 13 sept. 2011 à 18:08, mohamed.boucad...@orange-ftgroup.com a écrit : Hi Rémi, Thank you or your answer but my question was not on the CPE side but the operations at the border router side. The point is that, with the new 4rd, an AFTR that sends an IPv4 packet to a CPE doesn't need to know the length of the CPE IPv6 prefix of that BR. This is a major difference with the old 4rd where this length was a rule parameter. (It is now a parameter only with the CPE-cascade option, to be ignored for this discussion.) As detailed in Figure 2, the BR includes in the subnet prefix of the IPv6 address L bits from the A+P port. This length L is 14 bits unless it has to be limited for this prefix to fit into 64 bits. Regarding the 4rd CEs are not cascaded, do you assume that the BR imply 64 bits length for all CE's prefix length if the absence of CE IPv6 prefix length configuration? The AFTR doesn't need to imply any CPE prefix length to build the right DST subnet prefix (64 bits). Let's take the example of sec. 6 (A), namely: +++-+ | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) | +++-+ | 192.32../12|2001:db0::/28 | 2001:db0::::/64 | +++-+ +-+--+--+---+ | CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of | | | address | pattern | ports | +-+--+--+---+ | 2001:db1::/48 | 192.33.17.17 | NA | 64K | | 2001:db2::2000::/52 | 192.34.34.34 | xxx0100x | 3840 | +-+--+--+---+ Let's assume that the AFTR has A+P packets to send to CPE IPv4 addresses 192.33.17.17 and 192.34.34.34 respectively, and both with dst port 0x4445. The L port bits to be included in subnet prefixes are then 2888::/15 (reversed order port bits 0-14). Destination subnet prefixes then comprise: - The Domain IPv6 prefix 2001:db0::/28 - 32 - 12 = 20 rightmost bits of IPv4 addresses, :1000::/20 and :2000::/20 respectively - 2888::/15 - One padding bit set to 0 They are: - 2001:db1::2888::/64 - 2001:db2::2888::/64 Each one starts with the CPE IPv6 prefix of the right dst CPE, which is enough to reach it. Hope it clarifies. Kind regards, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Med, Le 14 sept. 2011 à 07:40, mohamed.boucad...@orange-ftgroup.com a écrit : ... I didn't get my answer yet. I'm looking for the explanation about the behaviour of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned with port sets of different sizes. What is the configuration of that node? Please see my answer to Satoru-san. Copy enclosed below. Cheers, RD -- The AFTR doesn't need to imply any CPE prefix length to build the right DST subnet prefix (64 bits). Let's take the example of sec. 6 (A), namely: +++-+ | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) | +++-+ | 192.32../12|2001:db0::/28 | 2001:db0::::/64 | +++-+ +-+--+--+---+ | CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of | | | address | pattern | ports | +-+--+--+---+ | 2001:db1::/48 | 192.33.17.17 | NA | 64K | | 2001:db2::2000::/52 | 192.34.34.34 | xxx0100x | 3840 | +-+--+--+---+ Let's assume that the AFTR has A+P packets to send to CPE IPv4 addresses 192.33.17.17 and 192.34.34.34 respectively, and both with dst port 0x4445. The L port bits to be included in subnet prefixes are then 2888::/15 (reversed order port bits 0-14). Destination subnet prefixes then comprise: - The Domain IPv6 prefix 2001:db0::/28 - 32 - 12 = 20 rightmost bits of IPv4 addresses, :1000::/20 and :2000::/20 respectively - 2888::/15 - One padding bit set to 0 They are: - 2001:db1::2888::/64 - 2001:db2::2888::/64 Each one starts with the CPE IPv6 prefix of the right dst CPE, which is enough to reach it. Hope it clarifies. - Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 13 septembre 2011 19:42 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 13 sept. 2011 à 18:08, mohamed.boucad...@orange-ftgroup.com a écrit : Hi Rémi, Thank you or your answer but my question was not on the CPE side but the operations at the border router side. The point is that, with the new 4rd, an AFTR that sends an IPv4 packet to a CPE doesn't need to know the length of the CPE IPv6 prefix of that BR. This is a major difference with the old 4rd where this length was a rule parameter. (It is now a parameter only with the CPE-cascade option, to be ignored for this discussion.) As detailed in Figure 2, the BR includes in the subnet prefix of the IPv6 address L bits from the A+P port. This length L is 14 bits unless it has to be limited for this prefix to fit into 64 bits. The result can be a subnet prefix that typically differs from the CPE IPv6 prefix, with some extra port bits after the CPE IPv6 prefix. However, because the subnet prefix does start with the CPE IPv6 prefix, the packet reaches the CPE. There, the 4rd IID is enough for the packet to be recognized as a 4rd packet. Is this, now, the explanation you were looking for? Cheers, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 17:05 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes. Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A. Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Remi-san, On 2011/09/14, at 15:20, Rémi Després wrote: ... Let's take the example of sec. 6 (A), namely: +++-+ | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) | +++-+ | 192.32../12|2001:db0::/28 | 2001:db0::::/64 | +++-+ +-+--+--+---+ | CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of | | | address | pattern | ports | +-+--+--+---+ | 2001:db1::/48 | 192.33.17.17 | NA | 64K | | 2001:db2::2000::/52 | 192.34.34.34 | xxx0100x | 3840 | +-+--+--+---+ Let's assume that the AFTR has A+P packets to send to CPE IPv4 addresses 192.33.17.17 and 192.34.34.34 respectively, and both with dst port 0x4445. If I understand your algorithm correctly, the port number of the example should be '0x4449'. The L port bits to be included in subnet prefixes are then 2888::/15 (reversed order port bits 0-14). Also, should it be '0x2444'? Destination subnet prefixes then comprise: - The Domain IPv6 prefix 2001:db0::/28 - 32 - 12 = 20 rightmost bits of IPv4 addresses, :1000::/20 and :2000::/20 respectively - 2888::/15 - One padding bit set to 0 They are: - 2001:db1::2888::/64 - 2001:db2::2888::/64 Each one starts with the CPE IPv6 prefix of the right dst CPE, which is enough to reach it. Hope it clarifies. Now I understand how your algorithm works. The CEs which comply your algorithm, almost address spaces are consumed for 4rd except /64 prefixes which last bit of prefix is set. Is it correct? cheers, --satoru Kind regards, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Med, On 2011/09/14, at 14:40, mohamed.boucad...@orange-ftgroup.com wrote: Hi Rémi, I didn't get my answer yet. I'm looking for the explanation about the behaviour of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned with port sets of different sizes. What is the configuration of that node? If I correctly understand his algorithm, the size of port sets depend on delegated IPv6 prefix length to each CE. As the example in his mail, a CE gets /48, then it uses whole IPv4 address, another CE gets /52, then it uses an IPv4 address with restricted to 3840 ports. cheers, --satoru Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 13 septembre 2011 19:42 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 13 sept. 2011 à 18:08, mohamed.boucad...@orange-ftgroup.com a écrit : Hi Rémi, Thank you or your answer but my question was not on the CPE side but the operations at the border router side. The point is that, with the new 4rd, an AFTR that sends an IPv4 packet to a CPE doesn't need to know the length of the CPE IPv6 prefix of that BR. This is a major difference with the old 4rd where this length was a rule parameter. (It is now a parameter only with the CPE-cascade option, to be ignored for this discussion.) As detailed in Figure 2, the BR includes in the subnet prefix of the IPv6 address L bits from the A+P port. This length L is 14 bits unless it has to be limited for this prefix to fit into 64 bits. The result can be a subnet prefix that typically differs from the CPE IPv6 prefix, with some extra port bits after the CPE IPv6 prefix. However, because the subnet prefix does start with the CPE IPv6 prefix, the packet reaches the CPE. There, the 4rd IID is enough for the packet to be recognized as a 4rd packet. Is this, now, the explanation you were looking for? Cheers, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 17:05 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes. Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A. Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs First, note that, because of privileged-port exclusion for fairness, port-set sizes of 4rd are 15/16 * 2^k. For (1): - POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have 15/16*4096=3840 ports per CPE). - POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have 15/16*1024=960 ports per CPE). For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of length L+2 to m CPEs. OK? 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
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, Thank you or your answer but my question was not on the CPE side but the operations at the border router side. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 17:05 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes. Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A. Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs First, note that, because of privileged-port exclusion for fairness, port-set sizes of 4rd are 15/16 * 2^k. For (1): - POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have 15/16*4096=3840 ports per CPE). - POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have 15/16*1024=960 ports per CPE). For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of length L+2 to m CPEs. OK? Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, I didn't get my answer yet. I'm looking for the explanation about the behaviour of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned with port sets of different sizes. What is the configuration of that node? Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 13 septembre 2011 19:42 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 13 sept. 2011 à 18:08, mohamed.boucad...@orange-ftgroup.com a écrit : Hi Rémi, Thank you or your answer but my question was not on the CPE side but the operations at the border router side. The point is that, with the new 4rd, an AFTR that sends an IPv4 packet to a CPE doesn't need to know the length of the CPE IPv6 prefix of that BR. This is a major difference with the old 4rd where this length was a rule parameter. (It is now a parameter only with the CPE-cascade option, to be ignored for this discussion.) As detailed in Figure 2, the BR includes in the subnet prefix of the IPv6 address L bits from the A+P port. This length L is 14 bits unless it has to be limited for this prefix to fit into 64 bits. The result can be a subnet prefix that typically differs from the CPE IPv6 prefix, with some extra port bits after the CPE IPv6 prefix. However, because the subnet prefix does start with the CPE IPv6 prefix, the packet reaches the CPE. There, the 4rd IID is enough for the packet to be recognized as a 4rd packet. Is this, now, the explanation you were looking for? Cheers, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 17:05 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes. Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A. Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs First, note that, because of privileged-port exclusion for fairness, port-set sizes of 4rd are 15/16 * 2^k. For (1): - POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have 15/16*4096=3840 ports per CPE). - POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have 15/16*1024=960 ports per CPE). For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of length L+2 to m CPEs. OK? Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Med, Here is an update concerning 4rd-addmapping in this draft (sec 2.1.6): +---+-+ | Property | Value | +---+-+ |Complexity | -- | | Address Sharing Ratio | 1:2^p, p up to 14 | | Number of ports in a Port-Set | 2^p * 15/16 | | Guessing Complexity of a Valid Port | -- | | Guessing Complexity of the whole Port-Set | -- | |Excluded ports | 0-4095, to be 0-1023| | Minimal Sharing Ratio | 1:1 | | Maximal Sharing Ratio | 1:16K | |Multiple Port Sets | Supported | | Differentiated Port Sets | Supported | | DomPref Flexibility | Supported | |IPv4 traffic Isolation | Supported | |Prefix Aggregation | Preserved | |Encode Routing Bits in 64 bits | Supported | | Compliancy with RTP/RTCP | Compliant | +---+-+ The line on Multiple Port Sets has been kept, but you announcement that it will be deleted is understood and approved. It is also understood that you intend to distinguish Differentiated port set sizes Per-customer from Per customer class (a clarifying distinction) A suggestion is to also distinguish between Per-customer with PRR states from Per customer without PRR states. (The new 4rd has been designed to support the latter, which is useful for direct CPE-CPE routes. This isn't the case of all proposals.) Another criterion that differentiates proposals is whether the port set derivation depends on Domain-specific parameters, or is purely algorithmic without parameter. As we discussed, I also work on tables listing differentiating features of proposed solutions. They distinguish functional features of: - port-set specifications - IPv6 address formats of CPEs and AFTRs - Packet formats for IPv6-domain traversal They are intended to be easily modifiable, so as to be a temporary tool to facilitate discussion. FYI, Alain having expressed interest in having them in draft form before the meeting, I plan to edit the draft this week. Cheers, RD Le 5 sept. 2011 à 18:44, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. ... ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, Thank you for this input. As for the differentiated port sets, I'm planning to add the following properties to -01 of draft-bsd-* (need to be discussed with my co-authors): o Differentiated Port Sets (Bound to the same IP address): Capability to assign port sets of different sizes to customers assigned with the same IPv4 address. o Differentiated Port Sets (Network Level): Capability to assign port sets of different sizes to customers attached to the same network. These properties aim to assess the ability of the solution to define different classes of customers having distinct port usage needs. This feature can be supported by dedicating distinct IPv4 address pools but this impacts route aggregation. To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs Thanks. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 12:01 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, Here is an update concerning 4rd-addmapping in this draft (sec 2.1.6): +---+-+ | Property | Value | +---+-+ |Complexity | -- | | Address Sharing Ratio | 1:2^p, p up to 14 | | Number of ports in a Port-Set | 2^p * 15/16 | | Guessing Complexity of a Valid Port | -- | | Guessing Complexity of the whole Port-Set | -- | |Excluded ports | 0-4095, to be 0-1023| | Minimal Sharing Ratio | 1:1 | | Maximal Sharing Ratio | 1:16K | |Multiple Port Sets | Supported | | Differentiated Port Sets | Supported | | DomPref Flexibility | Supported | |IPv4 traffic Isolation | Supported | |Prefix Aggregation | Preserved | |Encode Routing Bits in 64 bits | Supported | | Compliancy with RTP/RTCP | Compliant | +---+-+ The line on Multiple Port Sets has been kept, but you announcement that it will be deleted is understood and approved. It is also understood that you intend to distinguish Differentiated port set sizes Per-customer from Per customer class (a clarifying distinction) A suggestion is to also distinguish between Per-customer with PRR states from Per customer without PRR states. (The new 4rd has been designed to support the latter, which is useful for direct CPE-CPE routes. This isn't the case of all proposals.) Another criterion that differentiates proposals is whether the port set derivation depends on Domain-specific parameters, or is purely algorithmic without parameter. As we discussed, I also work on tables listing differentiating features of proposed solutions. They distinguish functional features of: - port-set specifications - IPv6 address formats of CPEs and AFTRs - Packet formats for IPv6-domain traversal They are intended to be easily modifiable, so as to be a temporary tool to facilitate discussion. FYI, Alain having expressed interest in having them in draft form before the meeting, I plan to edit the draft this week. Cheers, RD Le 5 sept. 2011 à 18:44, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes. Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A. Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs First, note that, because of privileged-port exclusion for fairness, port-set sizes of 4rd are 15/16 * 2^k. For (1): - POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have 15/16*4096=3840 ports per CPE). - POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have 15/16*1024=960 ports per CPE). For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of length L+2 to m CPEs. OK? Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Dear Gang, The logic we adopted for guessing complexity of a valid port and for the whole range is as mentioned in http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2: In each analyzed port derivation algorithm, an attacker may implement a redirection loop to detect a significant amount of allowed ports. For all monotonously scattered schemes, the whole Port-Set may be deduced by extrapolation while this is not applicable for contiguous port ranges (because no information about port bounds is leaked in the IPv4-translatable IPv6 address). Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de GangChen Envoyé : jeudi 8 septembre 2011 18:19 À : Simon Perreault Cc : softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) 2011/9/7, Simon Perreault simon.perrea...@viagenie.ca: mohamed.boucad...@orange-ftgroup.com wrote, on 09/07/2011 03:28 AM: What I have done is I clarified the text as follows: o Complexity: Reflects the complexity level of understanding the algorithm and the expected complexity to configure an implementation. A subjective criteria is not very useful for comparing algorithms. +1 Here's a suggestion: configuration complexity could be measured in terms of the number of parameters necessary. This is an objective criteria. Criteria should be as objective as possible, especially for Guessing Complexity of a Valid Port Not sure whether there are some mathematical guidance could help to evaluate computational complexity? Maybe time complexity is a candidate BRs Gang ___ 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, Please see inline. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@free.fr] Envoyé : mercredi 7 septembre 2011 10:56 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : GangChen; softwires@ietf.org; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Med, More comments in line. Le 7 sept. 2011 à 07:35, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear Gang, As per the following property: o Complexity: Complexity level of the algorithm I agree this can be split into several sub items but in -00 we used it to reflect the level of complexity to understand the algorithm and to configure it. These are two different subjects. Difficulty to understand can be due to insufficient quality of explanations. In this respect, I know what I have written in the past was quite perfectible. I expect the 4rd-addmapping draft to be clearer on several points, but it certainly can be clarified further. Questions raised in the WG are helpful for that. Med: This is IMHO an important aspect for the operational teams who are in charge of dimensioning the A+P space. Easiness of usability is important. Difficulty to configure is rather minimal with solutions that are completely stateless. Having High complexity for 4rd-addmapping can therefore be misleading. Med: Not all the port indexing schemes on the table have the same complexity level. As I mentioned earlier, we need to depict this somehow. I would really appreciate if you can evaluate other port algorithms and share your evaluation. (The Complexity criterion is also commented in my previous mail.) Cheers, RD I know Nejc had some experience in configuring for instance Murakami's 4rd implementation. He found that it was much more complex to understand than the portrange algorithm and the modulo algorithm. The text will be clarified. Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : mardi 6 septembre 2011 18:10 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hello Authors, I think the draft did really good analysis on several mapping algorithm, especially properties evaluation part. One question for clarification: I saw several properties are COMPLEXITY related. Just wondering to know what kind of criteria you adopt to judge different levels(i.e. Low, Medium, High) ? I guess it would be beneficial if you could take some words to describe the criteria. Many thanks Gang 2011/9/6, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename: draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date: 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, Please see inline. Cheers, Med De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mercredi 7 septembre 2011 14:06 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Jacni Qin; Softwires-wg; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Oops, e) to be deleted from the list below (same feature as c)) Le 7 sept. 2011 à 11:02, Rémi Després a écrit : Hi Med, Thank you for the detailed analysis of our draft. Please see some first comments in line. Le 7 sept. 2011 à 07:22, mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com a écrit : Hi Jacni, Please see inline. Cheers, Med De : Jacni Qin [mailto:ja...@jacni.com] Envoyé : mardi 6 septembre 2011 11:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; softwires@ietf.orgmailto:softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) hi Med, all, Thanks for writing this, it helps. A couple of quick comments below, *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. IMHO, separating port-set indexing and IPv6 address format would be a clarification. [Med] OK, I will do. Here is a tentative contribution in this direction. Major criteria to evaluate port-indexing methods: [Med] In fact we are not evaluating the algorithm at this stage but only characterizing them with a set of properties. a) Fairness (no CPE gets well-known ports 0-1023) [Med] We indicate whether this range is excluded or not in the properties table. But, this can be seen also as a loss of port utilization efficiency. b) RTP/RTCP compatibility c) Stateless BR support of multiple CPE-port-set sizes [Med] As I mentioned in another e-mail, I added two properties in the table: o Differentiated Port Sets (Network Level): Capability to assign port sets of different sizes to customers attached to the same network. o Differentiated Port Sets (same IP address): Capability to assign port sets of different sizes to customers assigned with the same IPv4 address. d) UPnP friendliness (interleaved port sets) [Med] I guess you are referring to IGD:1. Difficult to assess for at least two reasons: (1) IGD:1 is broken and (2) implementations adopt several behaviour (incremental or random). e) Support of differentiated sharing ratios without per-CPE states in BRs Major criteria to evaluate IPv6 address formats of CPEs: i) Compatibility with IPv4 routes between CPEs as direct as IPv6 routes. (This implies A+P-IPv6 derivation without per-CPE state) j) No impact on the assignment plan of IPv6 prefixes to CPE's. (This excludes in particular full IPv4 addresses in CPE IPv6 prefixes.) k) Optional support of CPE cascades (the suffix field of the 4rd mapping proposals, explained in the 4rd-addmapping draft) OTOH, complexity comparisons, although worth keeping in mind at this stage, are premature (largely subjective before optimized codes have been worked on for stabilized methods). So far, making sure all methods have AFAIK O(1) complexity should IMHO be be sufficient. When clear about other criteria, thin optimization can become relevant. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Le 8 sept. 2011 à 08:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : De : Rémi Després [mailto:despres.r...@laposte.net] ... ... criteria to evaluate port-indexing methods: [Med] In fact we are not evaluating the algorithm at this stage but only characterizing them with a set of properties. OK, just a vocabulary ambiguity. We share the same objective. a) Fairness (no CPE gets well-known ports 0-1023) [Med] We indicate whether this range is excluded or not in the properties table. But, this can be seen also as a loss of port utilization efficiency. Yes, it has to be considered. Now: - Giving 15 ports, as proposed in the two 4rd variants, where 16 ports can be given by relaxing the fairness constraint isn't a big deal. - After a recent exchange of information with Christian Huitema, I understand that excluding only the well-known ports 0-1023 is enough. Then the port-set-size reduction due to fairness can become 1/64 instead of 1/16, which is even more negligible. ... d) UPnP friendliness (interleaved port sets) [Med] I guess you are referring to IGD:1. Difficult to assess for at least two reasons: (1) IGD:1 is broken and (2) implementations adopt several behaviour (incremental or random). I-D.draft-deng-v6ops-aplusp-experiment-result is IMHO a useful reference on this subject. Having read it, I now share the view that if a port set is abundantly scattered, version 1 of UPnP will work better. This is useful because, I have been told, this version of UPnP is significantly deployed. If this is wrong, please let me know. If despite the above, the final consensus would be that IETF doesn't care about this feature, the latest 4rd address mapping can easily be simplified accordingly. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Le 8 sept. 2011 à 08:05, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit ... De : Rémi Després [mailto:despres.r...@free.fr] ... Difficulty to understand can be due to insufficient quality of explanations. In this respect, I know what I have written in the past was quite perfectible. I expect the 4rd-addmapping draft to be clearer on several points, but it certainly can be clarified further. Questions raised in the WG are helpful for that. Med: This is IMHO an important aspect for the operational teams who are in charge of dimensioning the A+P space. Easiness of usability is important. Same view on this. Difficulty to configure is rather minimal with solutions that are completely stateless. Having High complexity for 4rd-addmapping can therefore be misleading. Med: Not all the port indexing schemes on the table have the same complexity level. As I mentioned earlier, we need to depict this somehow. I would really appreciate if you can evaluate other port algorithms and share your evaluation. In my understanding, all proposed algorithms are, once understood, sufficiently easy to program. All can be executed in a time bounded by a small constant, but one whose value depends on code optimization. IMHO, it is more effective to analyze first functional characteristics and their individual motivations. This avoids to spend time, at this stage, on detailed discussions on how to optimize code for all analyzed solutions. (This can be done in a second phase for the retained solution(s)). Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
2011/9/7, Simon Perreault simon.perrea...@viagenie.ca: mohamed.boucad...@orange-ftgroup.com wrote, on 09/07/2011 03:28 AM: What I have done is I clarified the text as follows: o Complexity: Reflects the complexity level of understanding the algorithm and the expected complexity to configure an implementation. A subjective criteria is not very useful for comparing algorithms. +1 Here's a suggestion: configuration complexity could be measured in terms of the number of parameters necessary. This is an objective criteria. Criteria should be as objective as possible, especially for Guessing Complexity of a Valid Port Not sure whether there are some mathematical guidance could help to evaluate computational complexity? Maybe time complexity is a candidate BRs Gang ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Satoru, What I have done is I clarified the text as follows: o Complexity: Reflects the complexity level of understanding the algorithm and the expected complexity to configure an implementation. Is this fine or you think we need to elaborate further? Cheers, Med -Message d'origine- De : Satoru Matsushima [mailto:satoru.matsush...@gmail.com] Envoyé : mercredi 7 septembre 2011 09:03 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : GangChen; softwires@ietf.org; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, 2011/9/7 mohamed.boucad...@orange-ftgroup.com: Dear Gang, As per the following property: o Complexity: Complexity level of the algorithm I agree this can be split into several sub items but in -00 we used it to reflect the level of complexity to understand the algorithm and to configure it. I know Nejc had some experience in configuring for instance Murakami's 4rd implementation. He found that it was much more complex to understand than the portrange algorithm and the modulo algorithm. The text will be clarified. Interesting discussion. It would be nice if you and us clarify that the complexity for what, and for who. cheers, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Med, More inline please, On 9/7/2011 1:22 PM, mohamed.boucad...@orange-ftgroup.com wrote: *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. Ok, and just FYI, there are some design objectives discussed in http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-00#page-5 which may be useful to you. *) For despres-4rd, Differentiated Port Sets Supported, through different piece of rules, delegated CPE prefixes of different length. [Med] the concern is more on the border router side, can you please check if the operations are still stateless at the border side? Yes, actually the multiple rules ([IPv6 DomPref, IPv4 DomPref] pairs) are used to accommodate fragmented IPv4 address spaces. BTW, I'm envisaging having two properties here: (1) Differentiated Port Sets (network level) (2) Differentiated Port Sets (bound to the same shared address) IPv4 traffic Isolation supported [Med] Ok. This is supported by assigning two prefixes. Not necessary, for encapsulation, the next header can be used to distinguish the traffic. In addition, a special IID is defined, which can be used in the translation context. Cheers, Jacni ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Mohamed, I am a developer of 4rd which is used by Nejc. From my perspective, the complexity is not coming from the algorithm itself but I think the complex is depend on the implementation as well. So, I don't think it is good to make a conclusion with a given implementation only. In fact, I have already improved my 4rd implementation. Nejc is using the old version. I think I could improve 4rd configuration in the latest version of my implementation. So, I think we should clarify the complexity from clear cannon which should be coming from many perspective such as algorithm, implementation, etc. Thanks, Tetsuya Murakami On 2011/09/06, at 22:35, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: Dear Gang, As per the following property: o Complexity: Complexity level of the algorithm I agree this can be split into several sub items but in -00 we used it to reflect the level of complexity to understand the algorithm and to configure it. I know Nejc had some experience in configuring for instance Murakami's 4rd implementation. He found that it was much more complex to understand than the portrange algorithm and the modulo algorithm. The text will be clarified. Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : mardi 6 septembre 2011 18:10 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hello Authors, I think the draft did really good analysis on several mapping algorithm, especially properties evaluation part. One question for clarification: I saw several properties are COMPLEXITY related. Just wondering to know what kind of criteria you adopt to judge different levels(i.e. Low, Medium, High) ? I guess it would be beneficial if you could take some words to describe the criteria. Many thanks Gang 2011/9/6, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename: draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date: 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Le 7 sept. 2011 à 09:55, Satoru Matsushima a écrit : ... And from my experience, none of configuration complexity for 4rd implementations. These don't require any complicated configuration to generate port-set from port-set ID. +1 (in addition to my personal comments) RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Med, More comments in line. Le 7 sept. 2011 à 07:35, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear Gang, As per the following property: o Complexity: Complexity level of the algorithm I agree this can be split into several sub items but in -00 we used it to reflect the level of complexity to understand the algorithm and to configure it. These are two different subjects. Difficulty to understand can be due to insufficient quality of explanations. In this respect, I know what I have written in the past was quite perfectible. I expect the 4rd-addmapping draft to be clearer on several points, but it certainly can be clarified further. Questions raised in the WG are helpful for that. Difficulty to configure is rather minimal with solutions that are completely stateless. Having High complexity for 4rd-addmapping can therefore be misleading. (The Complexity criterion is also commented in my previous mail.) Cheers, RD I know Nejc had some experience in configuring for instance Murakami's 4rd implementation. He found that it was much more complex to understand than the portrange algorithm and the modulo algorithm. The text will be clarified. Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : mardi 6 septembre 2011 18:10 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hello Authors, I think the draft did really good analysis on several mapping algorithm, especially properties evaluation part. One question for clarification: I saw several properties are COMPLEXITY related. Just wondering to know what kind of criteria you adopt to judge different levels(i.e. Low, Medium, High) ? I guess it would be beneficial if you could take some words to describe the criteria. Many thanks Gang 2011/9/6, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename: draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date: 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Med, Thank you for the detailed analysis of our draft. Please see some first comments in line. Le 7 sept. 2011 à 07:22, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Hi Jacni, Please see inline. Cheers, Med De : Jacni Qin [mailto:ja...@jacni.com] Envoyé : mardi 6 septembre 2011 11:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) hi Med, all, Thanks for writing this, it helps. A couple of quick comments below, *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. IMHO, separating port-set indexing and IPv6 address format would be a clarification. Here is a tentative contribution in this direction. Major criteria to evaluate port-indexing methods: a) Fairness (no CPE gets well-known ports 0-1023) b) RTP/RTCP compatibility c) Stateless BR support of multiple CPE-port-set sizes d) UPnP friendliness (interleaved port sets) e) Support of differentiated sharing ratios without per-CPE states in BRs Major criteria to evaluate IPv6 address formats of CPEs: i) Compatibility with IPv4 routes between CPEs as direct as IPv6 routes. (This implies A+P-IPv6 derivation without per-CPE state) j) No impact on the assignment plan of IPv6 prefixes to CPE's. (This excludes in particular full IPv4 addresses in CPE IPv6 prefixes.) k) Optional support of CPE cascades (the suffix field of the 4rd mapping proposals, explained in the 4rd-addmapping draft) OTOH, complexity comparisons, although worth keeping in mind at this stage, are premature (largely subjective before optimized codes have been worked on for stabilized methods). So far, making sure all methods have AFAIK O(1) complexity should IMHO be be sufficient. When clear about other criteria, thin optimization can become relevant. *) o Multiple Port Ranges: Capability to assign multiple contiguous port ranges to a single PRD Jacni: I guess this only applies to portrange which offers contiguous port-set. So, I would suggest removing this property. [Med] Ok. *) For despres-4rd, Differentiated Port Sets Supported, through different piece of rules, delegated CPE prefixes of different length. [Med] the concern is more on the border router side, can you please check if the operations are still stateless at the border side? Yes, still stateless. The BR doesn't need to know the length of a CPE prefix to build an address that starts with the CPE prefix. It may have bits beyond the CPE prefix, but the CPE ignores them. Kind regards, RD BTW, I'm envisaging having two properties here: (1) Differentiated Port Sets (network level) (2) Differentiated Port Sets (bound to the same shared address) IPv4 traffic Isolation supported [Med] Ok. This is supported by assigning two prefixes. IPv4 traffic is recognized by the fact that Interface ID is a 4rd IID (sec 5.3) Prefix Aggregation supported, since the IPv6 address planning is not affected. [Med] Ok. I'll come back to you later if I get more. Cheers, Jacni On Tuesday, September 06, 2011 12:44:48 AM, mohamed.boucad...@orange-ftgroup.com wrote: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename : draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date : 2011-09-05 This document analyzes
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Oops, e) to be deleted from the list below (same feature as c)) Le 7 sept. 2011 à 11:02, Rémi Després a écrit : Hi Med, Thank you for the detailed analysis of our draft. Please see some first comments in line. Le 7 sept. 2011 à 07:22, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Hi Jacni, Please see inline. Cheers, Med De : Jacni Qin [mailto:ja...@jacni.com] Envoyé : mardi 6 septembre 2011 11:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) hi Med, all, Thanks for writing this, it helps. A couple of quick comments below, *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. IMHO, separating port-set indexing and IPv6 address format would be a clarification. Here is a tentative contribution in this direction. Major criteria to evaluate port-indexing methods: a) Fairness (no CPE gets well-known ports 0-1023) b) RTP/RTCP compatibility c) Stateless BR support of multiple CPE-port-set sizes d) UPnP friendliness (interleaved port sets) e) Support of differentiated sharing ratios without per-CPE states in BRs Major criteria to evaluate IPv6 address formats of CPEs: i) Compatibility with IPv4 routes between CPEs as direct as IPv6 routes. (This implies A+P-IPv6 derivation without per-CPE state) j) No impact on the assignment plan of IPv6 prefixes to CPE's. (This excludes in particular full IPv4 addresses in CPE IPv6 prefixes.) k) Optional support of CPE cascades (the suffix field of the 4rd mapping proposals, explained in the 4rd-addmapping draft) OTOH, complexity comparisons, although worth keeping in mind at this stage, are premature (largely subjective before optimized codes have been worked on for stabilized methods). So far, making sure all methods have AFAIK O(1) complexity should IMHO be be sufficient. When clear about other criteria, thin optimization can become relevant. *) o Multiple Port Ranges: Capability to assign multiple contiguous port ranges to a single PRD Jacni: I guess this only applies to portrange which offers contiguous port-set. So, I would suggest removing this property. [Med] Ok. *) For despres-4rd, Differentiated Port Sets Supported, through different piece of rules, delegated CPE prefixes of different length. [Med] the concern is more on the border router side, can you please check if the operations are still stateless at the border side? Yes, still stateless. The BR doesn't need to know the length of a CPE prefix to build an address that starts with the CPE prefix. It may have bits beyond the CPE prefix, but the CPE ignores them. Kind regards, RD BTW, I'm envisaging having two properties here: (1) Differentiated Port Sets (network level) (2) Differentiated Port Sets (bound to the same shared address) IPv4 traffic Isolation supported [Med] Ok. This is supported by assigning two prefixes. IPv4 traffic is recognized by the fact that Interface ID is a 4rd IID (sec 5.3) Prefix Aggregation supported, since the IPv6 address planning is not affected. [Med] Ok. I'll come back to you later if I get more. Cheers, Jacni On Tuesday, September 06, 2011 12:44:48 AM, mohamed.boucad...@orange-ftgroup.com wrote: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of propertiesare used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Re-, Please see inline. Cheers, Med De : Jacni Qin [mailto:ja...@jacni.com] Envoyé : mercredi 7 septembre 2011 10:12 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, More inline please, On 9/7/2011 1:22 PM, mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com wrote: *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. Ok, and just FYI, there are some design objectives discussed in http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-00#page-5 which may be useful to you. [Med] The document is now online, could you please check the list available at: http://tools.ietf.org/html/draft-boucadair-softwire-stateless-rfc6052-update-00#section-3. Do you see additional requirements to be inspired from the pointer you provided? thanks. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
mohamed.boucad...@orange-ftgroup.com wrote, on 09/07/2011 03:28 AM: What I have done is I clarified the text as follows: o Complexity: Reflects the complexity level of understanding the algorithm and the expected complexity to configure an implementation. A subjective criteria is not very useful for comparing algorithms. Here's a suggestion: configuration complexity could be measured in terms of the number of parameters necessary. This is an objective criteria. 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
hi Med, all, Thanks for writing this, it helps. A couple of quick comments below, *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. *) o Multiple Port Ranges: Capability to assign multiple contiguous port ranges to a single PRD Jacni: I guess this only applies to portrange which offers contiguous port-set. So, I would suggest removing this property. *) For despres-4rd, Differentiated Port Sets Supported, through different piece of rules, delegated CPE prefixes of different length. IPv4 traffic Isolation supported Prefix Aggregation supported, since the IPv6 address planning is not affected. I'll come back to you later if I get more. Cheers, Jacni On Tuesday, September 06, 2011 12:44:48 AM, mohamed.boucad...@orange-ftgroup.com wrote: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename : draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date : 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hello Authors, I think the draft did really good analysis on several mapping algorithm, especially properties evaluation part. One question for clarification: I saw several properties are COMPLEXITY related. Just wondering to know what kind of criteria you adopt to judge different levels(i.e. Low, Medium, High) ? I guess it would be beneficial if you could take some words to describe the criteria. Many thanks Gang 2011/9/6, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename: draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date: 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Jacni, Please see inline. Cheers, Med De : Jacni Qin [mailto:ja...@jacni.com] Envoyé : mardi 6 septembre 2011 11:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) hi Med, all, Thanks for writing this, it helps. A couple of quick comments below, *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. *) o Multiple Port Ranges: Capability to assign multiple contiguous port ranges to a single PRD Jacni: I guess this only applies to portrange which offers contiguous port-set. So, I would suggest removing this property. [Med] Ok. *) For despres-4rd, Differentiated Port Sets Supported, through different piece of rules, delegated CPE prefixes of different length. [Med] the concern is more on the border router side, can you please check if the operations are still stateless at the border side? BTW, I'm envisaging having two properties here: (1) Differentiated Port Sets (network level) (2) Differentiated Port Sets (bound to the same shared address) IPv4 traffic Isolation supported [Med] Ok. This is supported by assigning two prefixes. Prefix Aggregation supported, since the IPv6 address planning is not affected. [Med] Ok. I'll come back to you later if I get more. Cheers, Jacni On Tuesday, September 06, 2011 12:44:48 AM, mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com wrote: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename : draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date : 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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
[Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename: draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date: 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
