Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Francis, Please see inline. Cheers, Med -Message d'origine- De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Envoyé : mardi 13 mars 2012 17:56 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG; draft-cui-softwire-b4-translated-ds-lite Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm Med: Ok, thanks. But this is not clear in the -02 of draft-penno-*. - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet Med: Agree. (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) Med: I failed to get your first point. Could you please clarify? Thanks. (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? = I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) Med: applications using referral need to know the external IP address. I failed to see why this is simpler compared to draft-cui-*. (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. = my read of the SD-NAT mechanism is the public IP address is the same at each side of the SD-CGN. Med: This is not clear in -02 of the draft-penno-*. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? = see previous item (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 Med: It is not reasonable when you don't have a DHCPv4 server but use PCP for instance. (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? = too many drafts...? Med: I think it is fair to cite draft-donley-*. More seriously I have more concerns about too simple algorithms deployed in the SD-CGN, for instance the: [1024...xxx] - [N...N-1024+xxx] where p' = p + N - 1024 is good for tests or demos but makes CPEs too easy to trace, I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). Med: We don't have the constraint of MAP so I would not exclude pseudo-random port set algos (see http://tools.ietf.org/html/draft-tsou-softwire-port-set-algorithms-analysis-01#section-3.3) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite
Re-, Thanks Rajiv for the pointer. BTW unlike the constraints we have in MAP (e.g., the bits forming PSID must be adjacent), draft-cui-* and the like can use pseudo-random algorithms to generate port ranges. Cheers, Med -Message d'origine- De : Rajiv Asati (rajiva) [mailto:raj...@cisco.com] Envoyé : mardi 13 mars 2012 21:19 À : Francis Dupont; BOUCADAIR Mohamed OLNC/NAD/TIP; o...@cisco.com Cc : Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno-softwire-sd...@tools.ietf.org Objet : RE: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). I agree. GMA is defined here, btw - http://tools.ietf.org/html/draft-mdt-softwire-mapping-address- and-port-0 2#section-4.1 Cheers, Rajiv -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Francis Dupont Sent: Tuesday, March 13, 2012 12:56 PM To: mohamed.boucad...@orange.com Cc: Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno- softwire-sd...@tools.ietf.org Subject: Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4- translated-ds-lite In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? = I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. = my read of the SD-NAT mechanism is the public IP address is the same at each side of the SD-CGN. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? = see previous item (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 - it states DS-Lite so there is no direct IPv4 available - so IMHO the question is more about the DHCPv4-over-IPv6 application and is more for the DHC WG (BTW please don't bounce this issue between the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 itself) Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? = if they are the same the answer is easy (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: = BTW we need a better definition of deterministic. My proposal is it means the mapping follows an algorithm (and it is the case on the SD-CGN, BTW not on the SD-CPE). (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? = too many drafts...? More seriously I have more concerns about too simple algorithms deployed in the SD-CGN, for instance the: [1024...xxx] - [N...N-1024+xxx] where p' = p + N - 1024 is good for tests or demos but makes CPEs too easy to
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Dear Qiong, Please see inline. Cheers, Med De : Qiong [mailto:bingxu...@gmail.com] Envoyé : mercredi 14 mars 2012 00:50 À : Francis Dupont Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno-softwire-sd...@tools.ietf.org Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? [Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have described the ICMP processing in section 10. And we have verified that it works fine in all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem here. [Med] I know it is confusing but these are two distinct issues. draft-penno-* defines a new method using ICMP to learn ports. Please refer to http://tools.ietf.org/html/draft-penno-softwire-sdnat-02#section-5 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
Le 2012-03-14 à 06:51, Maoke a écrit : 2012/3/13 Rémi Després despres.r...@laposte.net 2012-03-13 12:02, Maoke : 2012/3/13 Rémi Després despres.r...@laposte.net ... The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. I missed this one. None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place. alright. so 4rd-U doesn't not support all existing transport protocol either. Never said that without qualifying which protocols. but i suppose you may make an update in the 4rd-u-06 so that a new if...else... is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft. In the Note in 4.4 (7), the first sentence is: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. It can become: This guarantees that, for all protocols that use the same checksum algorithm as TCP and have ports at the same place, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. Similarly, in the comparison table, H6 is: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as future protocols using the TCP checksum algorithm It can become: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any future protocol that might use the TCP checksum algorithm and ports at the same place but this is not my point. my point is: there must be something we don't know (non omnia possumus omnes). even we have gone through the RFCs, there might be some other proprietary L4 protocols, or experimental protocols. even they are minority, i don't think ignoring their existance in our solution fits the spirit of the Internet. it might be argued that NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may makes his own NAT44, either attached to the CE or separated. if 4rd-U respects such an effort, it should state currently blahblabla L4 protocols are supported. the similar statement applies to the RFC6145 or MAP as well. i somehow am hard to accept words like far fetched theoretical problem. If I had thought it might be so, I would have avoided the word. the L4-recalculate is a generic, architectural solution, surely needing codes for every L4 protocol. but this generality in architecture makes RFC6145 or MAP-T equipment be easily enhanced to support anything new with the same logic. but for the 4rd-U BR, it looks to me we cannot have the unified logic for all (even limited to existing and well-known) L4 protocols. only my 2 cents. With amendments above, the point is AFAIK completely covered: everything is rigorously true, and worth noting. Thanks for the useful reference to the RDP of RFC1151. RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 06:51, Maoke a écrit : 2012/3/13 Rémi Després despres.r...@laposte.net 2012-03-13 12:02, Maoke : 2012/3/13 Rémi Després despres.r...@laposte.net ... The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. I missed this one. None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place. alright. so 4rd-U doesn't not support all existing transport protocol either. Never said that without qualifying which protocols. but i suppose you may make an update in the 4rd-u-06 so that a new if...else... is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft. In the Note in 4.4 (7), the first sentence is: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. It can become: This guarantees that, for all protocols that use the same checksum algorithm as TCP and have ports at the same place, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. Similarly, in the comparison table, H6 is: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as future protocols using the TCP checksum algorithm It can become: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any future protocol that might use the TCP checksum algorithm and ports at the same place then it is fine. with these statement, 4rd-U can support - TCP - UDP - DCCP - any future or less well-known protocol as long as it uses TCP checksum and port at the same place as a counterpart, we may suggest MAP-T to state it supports - TCP - UDP - DCCP (with enforcing it rather than RFC6145's optional) - any future or less well-known protocol, no matter what layout it is nor how the checksum is defined, with the similar logic of L4 checksum recalculation ;-) maoke but this is not my point. my point is: there must be something we don't know (non omnia possumus omnes). even we have gone through the RFCs, there might be some other proprietary L4 protocols, or experimental protocols. even they are minority, i don't think ignoring their existance in our solution fits the spirit of the Internet. it might be argued that NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may makes his own NAT44, either attached to the CE or separated. if 4rd-U respects such an effort, it should state currently blahblabla L4 protocols are supported. the similar statement applies to the RFC6145 or MAP as well. i somehow am hard to accept words like far fetched theoretical problem. If I had thought it might be so, I would have avoided the word. the L4-recalculate is a generic, architectural solution, surely needing codes for every L4 protocol. but this generality in architecture makes RFC6145 or MAP-T equipment be easily enhanced to support anything new with the same logic. but for the 4rd-U BR, it looks to me we cannot have the unified logic for all (even limited to existing and well-known) L4 protocols. only my 2 cents. With amendments above, the point is AFAIK completely covered: everything is rigorously true, and worth noting. Thanks for the useful reference to the RDP of RFC1151. RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
Le 2012-03-14 à 10:00, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 06:51, Maoke a écrit : 2012/3/13 Rémi Després despres.r...@laposte.net 2012-03-13 12:02, Maoke : 2012/3/13 Rémi Després despres.r...@laposte.net ... The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. I missed this one. None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place. alright. so 4rd-U doesn't not support all existing transport protocol either. Never said that without qualifying which protocols. but i suppose you may make an update in the 4rd-u-06 so that a new if...else... is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft. In the Note in 4.4 (7), the first sentence is: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. It can become: This guarantees that, for all protocols that use the same checksum algorithm as TCP and have ports at the same place, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. Similarly, in the comparison table, H6 is: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as future protocols using the TCP checksum algorithm It can become: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any future protocol that might use the TCP checksum algorithm and ports at the same place then it is fine. with these statement, 4rd-U can support - TCP - UDP - DCCP - any future or less well-known protocol as long as it uses TCP checksum and port at the same place as a counterpart, we may suggest MAP-T to state it supports - TCP - UDP - DCCP (with enforcing it rather than RFC6145's optional) - any future or less well-known protocol, no matter what layout it is nor how the checksum is defined, with the similar logic of L4 checksum recalculation Maybe I get the point you are making: you implicitly consider that BR and CE modifications can be synchronized. This is feasible if ISPs provide all CE nodes, but not in the general case. Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). To be even more precise, H6 of the comparison table can be: For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, DCCP and UDP-Lite are supported, as well as future protocols using the TCP checksum algorithm and ports at the same place Does this cover the point? RD ;-) maoke but this is not my point. my point is: there must be something we don't know (non omnia possumus omnes). even we have gone through the RFCs, there might be some other proprietary L4 protocols, or experimental protocols. even they are minority, i don't think ignoring their existance in our solution fits the spirit of the Internet. it might be argued that NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may makes his own NAT44, either attached to the CE or separated. if 4rd-U respects such an effort, it should state currently blahblabla L4 protocols are supported. the similar statement applies to the RFC6145 or MAP as well. i somehow am hard to accept words like far fetched theoretical problem. If I had thought it might be so, I would have avoided the word. the L4-recalculate is a generic, architectural solution, surely needing codes for every L4 protocol. but this generality in architecture makes RFC6145 or MAP-T equipment be easily enhanced to support anything new with the same logic. but for the 4rd-U BR, it looks to me we cannot have the unified logic for all (even limited to existing and well-known) L4 protocols. only my 2 cents. With amendments above, the point is AFAIK completely covered: everything is rigorously true, and worth noting. Thanks for the useful reference to the RDP of RFC1151. RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:00, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 06:51, Maoke a écrit : 2012/3/13 Rémi Després despres.r...@laposte.net 2012-03-13 12:02, Maoke : 2012/3/13 Rémi Després despres.r...@laposte.net ... The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. I missed this one. None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place. alright. so 4rd-U doesn't not support all existing transport protocol either. Never said that without qualifying which protocols. but i suppose you may make an update in the 4rd-u-06 so that a new if...else... is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft. In the Note in 4.4 (7), the first sentence is: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. It can become: This guarantees that, for all protocols that use the same checksum algorithm as TCP and have ports at the same place, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. Similarly, in the comparison table, H6 is: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as future protocols using the TCP checksum algorithm It can become: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any future protocol that might use the TCP checksum algorithm and ports at the same place then it is fine. with these statement, 4rd-U can support - TCP - UDP - DCCP - any future or less well-known protocol as long as it uses TCP checksum and port at the same place as a counterpart, we may suggest MAP-T to state it supports - TCP - UDP - DCCP (with enforcing it rather than RFC6145's optional) - any future or less well-known protocol, no matter what layout it is nor how the checksum is defined, with the similar logic of L4 checksum recalculation Maybe I get the point you are making: you implicitly consider that BR and CE modifications can be synchronized. This is feasible if ISPs provide all CE nodes, but not in the general case. i don't consider their modifications are synced but i do consider that each device, either BR or CE, should has a specification on its supported functionalities. Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. To be even more precise, H6 of the comparison table can be: For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, DCCP and UDP-Lite are supported, as well as future protocols using the TCP checksum algorithm and ports at the same place i actually think the original text is fine. For shared IPv4 addresses is not needed for 4rd-U, to my understanding, nor needed to MAP-T. maoke Does this cover the point? RD ;-) maoke but this is not my point. my point is: there must be something we don't know (non omnia possumus omnes). even we have gone through the RFCs, there might be some other proprietary L4 protocols, or experimental protocols. even they are minority, i don't think ignoring their existance in our solution fits the spirit of the Internet. it might be argued that NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may makes his own NAT44, either attached to the CE or separated. if 4rd-U respects such an effort, it should state currently blahblabla L4 protocols are supported. the similar statement applies to the RFC6145 or MAP as well. i somehow am hard to accept words like far fetched theoretical problem. If I had thought it might be so, I would have avoided the word. the L4-recalculate is a generic, architectural solution, surely needing codes for every L4 protocol. but this generality in architecture makes RFC6145 or MAP-T equipment be easily enhanced to support anything new with the same logic. but for
[Softwires] MAP support of IPv4 prefixes?
Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02, Sec. 1 says:: the residual IPv4 over IPv6 mechanisms must be capable of...Provisioning an IPv4 prefix, an IPv4 address or a shared IPv4 address. (We all agree, I think, that this is important.) Sec.5.2 says: The MAP IPv6 address is created by concatenating the End-user IPv6 prefix with the MAP subnet-id and the interface-id as specified in Section 6. Sec6 says: The Interface identifier format is based on the format specified in section 2.2 of [RFC6052], with the added PSID format field (i.e. with at least a full embedded IPv4 address) What should be done for a CE that is provisioned an IPv4 prefix, i.e. several IPv4 addresses, is in my understanding unclear. Could you please clarify the intent? Thanks, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Med, see inline response to your questions wrt sd-nat-02 On Mar 13, 2012, at 10:58 AM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the correct IPv4 address and port by the CPE before being encapsulated in IPv6. In that scenario, the AFTR decapsulate the traffic, check IPv4 address port range are indeed assigned to that IPv6 user, then forward the packet. There is only one level of NAT, done by the CPE In 'compatibility' mode, if the CPE fails to enforce the proper port range, the AFTR will perform a second level of NAT. (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? in SD-nat, the 2nd NAT is only there to enable 'legacy' DS-Lite CPEs or DS-lite + B4 translated CPEs to interoperate with stateless DS-Lite CPEs. (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): o DHCPv4: the DHCPv4 protocol should be extended to support port-set allocation [I-D.bajko-pripaddrassignhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.bajko-pripaddrassign]. Besides, the DHCP message should send to the concentrator over IPv6. The concentrator can be the DHCP server or DHCP relay agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP requests simultaneously to acquire a number ports within the same IPv4 address, or use [I-D.tsou-pcp-natcoordhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.tsou-pcp-natcoord] for one-time port-set allocation. o DHCPv6: the DHCPv6 protocol should be extended to support port-set allocation [I-D.boucadair-dhcpv6-shared-address-optionhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.boucadair-dhcpv6-shared-address-option]. o IPCP: IPCP should be extended to carry the port-set. [RFC6431http://tools.ietf.org/html/rfc6431] gives an example. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? IMHO, not specifying the technology to get pot range and living this to implementation is a serious shortcoming. We need to standardize one method. (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. Same as above, we need to have one common technology that is implemented by everyone. This is the only way to guaranty interoperability. Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? The IPv4 address to put as src address of v4 traffic by the CPE before encapsulating in IPv6 and sending to AFTR. (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? No Alain. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Alain, It's a little confusing now. Let me try to get things clear. So the sd-nat-02 is not quite similar to the earlier version, the mechanism somehow changes. In my understanding, now the principle of the mechanism is similar to the lightweight 4over6 draft, but I may miss something here. My question is, how is it stateless or deterministic, and how is IPv6 anycast for multiple AFTRs working? Seems the draft is suggesting that we put an identical profile on each AFTR, the content of which is the mapping between IPv6 address and IPv4 address+port range for all the CPEs (And of course, we can try to find some protocol to synchronize the mapping automatically). Did I get this correctly? 2012/3/14 Alain Durand adur...@juniper.net: Hi Med, see inline response to your questions wrt sd-nat-02 On Mar 13, 2012, at 10:58 AM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the correct IPv4 address and port by the CPE before being encapsulated in IPv6. In that scenario, the AFTR decapsulate the traffic, check IPv4 address port range are indeed assigned to that IPv6 user, then forward the packet. There is only one level of NAT, done by the CPE In 'compatibility' mode, if the CPE fails to enforce the proper port range, the AFTR will perform a second level of NAT. (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? in SD-nat, the 2nd NAT is only there to enable 'legacy' DS-Lite CPEs or DS-lite + B4 translated CPEs to interoperate with stateless DS-Lite CPEs. (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): o DHCPv4: the DHCPv4 protocol should be extended to support port-set allocation [I-D.bajko-pripaddrassignhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.bajko-pripaddrassign]. Besides, the DHCP message should send to the concentrator over IPv6. The concentrator can be the DHCP server or DHCP relay agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP requests simultaneously to acquire a number ports within the same IPv4 address, or use [I-D.tsou-pcp-natcoordhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.tsou-pcp-natcoord] for one-time port-set allocation. o DHCPv6: the DHCPv6 protocol should be extended to support port-set allocation [I-D.boucadair-dhcpv6-shared-address-optionhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.boucadair-dhcpv6-shared-address-option]. o IPCP: IPCP should be extended to carry the port-set. [RFC6431http://tools.ietf.org/html/rfc6431] gives an example. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? IMHO, not specifying the technology to get pot range and living this to implementation is a serious shortcoming. We need to standardize one method. (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. Same as above, we need to have one common technology that is implemented by everyone. This is the only way to guaranty interoperability. Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? The IPv4 address to put as src address of v4 traffic by the CPE before encapsulating in IPv6 and sending to AFTR. (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? No Alain. ___ Softwires mailing list
Re: [Softwires] MAP support of IPv4 prefixes?
Remi, Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02, Sec. 1 says:: the residual IPv4 over IPv6 mechanisms must be capable of...Provisioning an IPv4 prefix, an IPv4 address or a shared IPv4 address. (We all agree, I think, that this is important.) Sec.5.2 says: The MAP IPv6 address is created by concatenating the End-user IPv6 prefix with the MAP subnet-id and the interface-id as specified in Section 6. Sec6 says: The Interface identifier format is based on the format specified in section 2.2 of [RFC6052], with the added PSID format field (i.e. with at least a full embedded IPv4 address) What should be done for a CE that is provisioned an IPv4 prefix, i.e. several IPv4 addresses, is in my understanding unclear. Could you please clarify the intent? section 6 says: In the case of an IPv4 prefix, the IPv4 address field is right-padded with zeroes up to 32 bits. The PSID field is left-padded to create a 16 bit field. For an IPv4 prefix or a complete IPv4 address, the PSID field is zero. if you find this unclear, feel free to contribute better text. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
In your previous mail you wrote: In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) [Qiong] Thanks for clarification. It seems this is not mentioned when to adopt and how to process the second NAT in current version of sd-nat. But still, I would prefer a solution without double-NAT. = my answer is simple: 1- it is technically possible but IMHO should not be deployed in the real world. 2- one can avoid only the second NAT itself, not the packet reassembly for instance. 3- the second NAT is a pretty simple one and is stateless (i.e., you can drop the CGN box and hotplug a replacement box with the same config: customers should see only the packets dropped during the operation. BTW we have a plan to show this at the next IETF meeting). = but the ICMP-based solution is deeply broken so is it a real advantage? [Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have described the ICMP processing in section 10. And we have verified that it works fine in all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem here. = my comment was about the ICMP-base solution for the configuration in Reinaldo Penno's I-D. Of course I have no concern about raising admin prohib ICMPs when a port out-of-range packet is filtered (in fact it is a great idea). For the ICMP echo service you can map it using the ID as the (source) port, it works well but if you'd like to use this from the Internet side you need a modified ping where you can set the ID to use (I can provide one if you want to try: IMHO it is better to be able to ping SD-CPEs and not only the SD-CGN). Question 5-1: Why MUST? IMHO, this is deployment-specific. = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 - it states DS-Lite so there is no direct IPv4 available - so IMHO the question is more about the DHCPv4-over-IPv6 application and is more for the DHC WG (BTW please don't bounce this issue between the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 itself) [Qiong] I still think it is deployment-specific. For operators who perfer to deploy PCP solution, it is nature for them to adopt PCP-base or PCP-extension (pcp-natcoord). For operators who would like to deploy DHCPv4-over-IPv6, port-range can be assigned in this way. = I misunderstood your concern: in fact you prefer something which provides the whole config, not only the IPv4 address. So the issue is not the 2.1 but the 2.1 and 2.2 (i.e., DHCPv4 over IPv6 for the external address, and ICMP for the port range) together, and you already know what I think about 2.2. [Qiong] Since it is a stateless solution, I also prefer the GMA algorithm which has been discusses widely in the WG. = yes, it has many advantages. But to come back to the first point, it is for the second NAT (:-)! Regards francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Re-, Thanks Alain for the answers. Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : mercredi 14 mars 2012 12:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG; draft-cui-softwire-b4-translated-ds-lite Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Hi Med, see inline response to your questions wrt sd-nat-02 On Mar 13, 2012, at 10:58 AM, mohamed.boucad...@orange.commailto:mohamed.boucadair@orange. com mohamed.boucad...@orange.commailto:mohamed.boucadair@orange. com wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the correct IPv4 address and port by the CPE before being encapsulated in IPv6. In that scenario, the AFTR decapsulate the traffic, check IPv4 address port range are indeed assigned to that IPv6 user, then forward the packet. There is only one level of NAT, done by the CPE Med: Ok, got it. This is the same as per draft-cui-*. In 'compatibility' mode, if the CPE fails to enforce the proper port range, the AFTR will perform a second level of NAT. Med: If the ultimate target is to remove the NAT module from the AFTR, I would see this compatibility mode as an implementation detail. BTW, why a CPE will fail to restrict the port? I see at least two cases: (1) want to grab more ports but this is not legitimate; I would vote for discarding those packets instead of NATing them. (2) the CPE does not support port-restriction: in that case why not use classic DS-Lite instead of NATing twice. (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 Med: Ok, thanks. So for draft-penno-* two provisioning means are required (compared to basic DS-Lite) * DHCPv4 for IPv4 address allocation * ICMP for port range configuration. I must admit the rationale behind this choice is not clear to me. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? IMHO, not specifying the technology to get pot range and living this to implementation is a serious shortcoming. We need to standardize one method. Med: But the question is why ICMP-based method is needed? Why not using port-restricted DHCPv4 options for instance? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] MAP support of IPv4 prefixes?
Le 2012-03-14 à 13:17, Ole Trøan a écrit : Remi, Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02, Sec. 1 says:: the residual IPv4 over IPv6 mechanisms must be capable of...Provisioning an IPv4 prefix, an IPv4 address or a shared IPv4 address. (We all agree, I think, that this is important.) Sec.5.2 says: The MAP IPv6 address is created by concatenating the End-user IPv6 prefix with the MAP subnet-id and the interface-id as specified in Section 6. Sec6 says: The Interface identifier format is based on the format specified in section 2.2 of [RFC6052], with the added PSID format field (i.e. with at least a full embedded IPv4 address) What should be done for a CE that is provisioned an IPv4 prefix, i.e. several IPv4 addresses, is in my understanding unclear. Could you please clarify the intent? section 6 says: In the case of an IPv4 prefix, the IPv4 address field is right-padded with zeroes up to 32 bits. The PSID field is left-padded to create a 16 bit field. For an IPv4 prefix or a complete IPv4 address, the PSID field is zero. OK if you find this unclear, feel free to contribute better text. I have to agree that the spec is already clear enough. Sorry for how I asked the question. Maybe you could improve the first sentence of sec. 6 to say:: The Interface identifier format is based on the format specified in section 2.2 of [RFC6052], with the added PSID format field, or with an IPv4 prefix instead of an IPv4 address. Thanks, RD cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Question about hub-and-spoke operation in MAP
Ole, Tomek, I couldn't figure out by how CEs can be required to work hub-and-spoke without some DHCPv6 indication: - If two CEs apply the same BMR to their delegated IPv6 prefixes, how do they know whether their ISP expects direct paths between them (mesh) or BR hairpinning (hub-and-spoke)? Sorry for bothering you if I missed something obvious. RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
In your previous mail you wrote: However, the draft seems give people impression there is only one NAT at CPE(i.e. 2.3. Stateless DS-Lite CPE operation) and AFTR is responsible for decapsulation and IPv4 package validation. Did I miss something? = yes, the SD-CGN (the SD-AFTR with DS-Lite) runs a second NAT but only on port (vs. address and port) and following algorithm (aka stateless). Regards francis.dup...@fdupont.fr PS: you can expand the algorithm application to a table of static mapping rules (it provides an easy way to configure a standard NAT as a SD-CGN without a line of C code :-). ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
In your previous mail you wrote: = I leave the draft-penno-* unclear items to Reinaldo... (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) Med: I failed to get your first point. Could you please clarify? Thanks. = when what you can see from the Internet is a big port range per customer it is trivial to track/trace customers. So what I call none algorithm (i.e., no port translation by the SD-CGN) or direct algorithm (i.e., port translation by adding a constant, the difference between the first/base port of ranges) are bad according to (quoting draft-tsou-softwire-port-set-algorithms-analysis): A good port set definition algorithm must be reversible, easy to implement, and should be able to define non-continuous or random port sets for better security, be able to exclude the well known ports, 0 ~ 1023 or 0 ~ 4095, etc. (BTW the last point doesn't apply to ICMP echo IDs) The note is about no second NAT, i.e., none algorithm. Med: applications using referral need to know the external IP address. = this comment is about the second NAT so as it doesn't translate the IP address is out of context (but I agree there are more needs for the external address than the external port) = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 Med: It is not reasonable when you don't have a DHCPv4 server but use PCP for instance. = PCP doesn't provide your IPv4 address. In fact, if you don't know your assigned IPv4 address you can't run PCP, nor any applications over IPv4 (note DHCPv4 is not over IPv4 exactly for this reason). Med: We don't have the constraint of MAP so I would not exclude pseudo-random port set algos (see draft-tsou-softwire-port-set-algorithms-analysis-01#section-3.3) = I have no concern about them as soon as enough information is given to SD-CPEs (including SD-B4s in the DS-Lite case) so they can compute external ports as visible from the Internet. Regards francis.dup...@fdupont.fr PS: in fact for implementing a PCP/NAT-PMP/UPnP-IGD/etc service on a SD-CPE you need the SD-CGN algo parameters to implement: - something giving the next local (i.e., SD-CPE WAN side) external port. Note ++ is never enough as one must stay inside the allowed port range. - something (I call it map) giving the external port as visible from the Internet from the local external port value (i.e., applying the SD-CGN algo in the CPE to Internet way). Note this must not fail when the input is a valid (i.e., in range) value. - something (I call it unmap) giving the local external port from the value as visible from the Internet. Note this can be failed if the port doesn't belong to the customer translated port range (nothing really new: we already know a random external port is likely unavailable on a CGN). ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
Hi Maoke and Remi, Thanks very much for discussing this issue on the mailing-list. I guess the points are now clear for both options. IMHO, there is no one better than the other, it is all about choice of implementation. Perhaps it is time for more people to comment how they feel for both options. Thanks again for the great discussion. B.R., Yiu From: Maoke fib...@gmail.com Date: Wed, 14 Mar 2012 09:46:06 + To: Rémi Després despres.r...@laposte.net Cc: Softwires WG softwires@ietf.org, Yong Cui cuiy...@tsinghua.edu.cn Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:00, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 06:51, Maoke a écrit : 2012/3/13 Rémi Després despres.r...@laposte.net 2012-03-13 12:02, Maoke : 2012/3/13 Rémi Després despres.r...@laposte.net ... The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. I missed this one. None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place. alright. so 4rd-U doesn't not support all existing transport protocol either. Never said that without qualifying which protocols. but i suppose you may make an update in the 4rd-u-06 so that a new if...else... is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft. In the Note in 4.4 (7), the first sentence is: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. It can become: This guarantees that, for all protocols that use the same checksum algorithm as TCP and have ports at the same place, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. Similarly, in the comparison table, H6 is: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as future protocols using the TCP checksum algorithm It can become: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any future protocol that might use the TCP checksum algorithm and ports at the same place then it is fine. with these statement, 4rd-U can support - TCP - UDP - DCCP - any future or less well-known protocol as long as it uses TCP checksum and port at the same place as a counterpart, we may suggest MAP-T to state it supports - TCP - UDP - DCCP (with enforcing it rather than RFC6145's optional) - any future or less well-known protocol, no matter what layout it is nor how the checksum is defined, with the similar logic of L4 checksum recalculation Maybe I get the point you are making: you implicitly consider that BR and CE modifications can be synchronized. This is feasible if ISPs provide all CE nodes, but not in the general case. i don't consider their modifications are synced but i do consider that each device, either BR or CE, should has a specification on its supported functionalities. Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. To be even more precise, H6 of the comparison table can be: For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, DCCP and UDP-Lite are supported, as well as future protocols using the TCP checksum algorithm and ports at the same place i actually think the original text is fine. For shared IPv4 addresses is not needed for 4rd-U, to my understanding, nor needed to MAP-T. maoke Does this cover the point? RD ;-) maoke but this is not my point. my point is: there must be something we don't know (non omnia possumus omnes). even we have gone through the RFCs, there might be some other proprietary L4 protocols, or experimental protocols. even they are minority, i don't think ignoring their existance in our solution fits the spirit of the Internet. it might be argued that NAT44 doesn't support such L4 protocols now,
Re: [Softwires] Question about hub-and-spoke operation in MAP
Remi, I couldn't figure out by how CEs can be required to work hub-and-spoke without some DHCPv6 indication: - If two CEs apply the same BMR to their delegated IPv6 prefixes, how do they know whether their ISP expects direct paths between them (mesh) or BR hairpinning (hub-and-spoke)? that's correct it needs to be provisioned. either explicitly or implicitly (via the rules). cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
I am a little lost. Let's put the double-nat aside for a moment. Except the fact that sd-nat uses icmp for port-set provisioning, what else different between Lightweight 4over6 vs. sd-nat? Am I missing something? For Lightweight 4over6, we can use anycast for redundancy. I fail to see what sd-nat does more than Lightweight 4over6. /Yiu On 3/14/12 8:47 AM, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Med: But the question is why ICMP-based method is needed? Why not using port-restricted DHCPv4 options for instance? smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the correct IPv4 address and port by the CPE before being encapsulated in IPv6. In that scenario, the AFTR decapsulate the traffic, check IPv4 address port range are indeed assigned to that IPv6 user, then forward the packet. There is only one level of NAT, done by the CPE = this means the port range will be visible as it in the Internet, IMHO this is not acceptable. And IMHO it is not the job of the SD-CPE (i.e., it is the SD-CGN one) to translate the port range to something far harder to track/trace. In 'compatibility' mode, if the CPE fails to enforce the proper port range, the AFTR will perform a second level of NAT. = if I understand well the compatibility mode is just the standard DS-Lite where the B4 performs spurious and useless translation? So in particular the only change for the AFTR is the customer IPv4 address? (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? in SD-nat, the 2nd NAT is only there to enable 'legacy' DS-Lite CPEs or DS-lite + B4 translated CPEs to interoperate with stateless DS-Lite CPEs. = I believe it is more 'to be supported' than 'to interoperate with stateless DS-Lite CPEs. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): o DHCPv4: the DHCPv4 protocol should be extended to support port-set allocation [I-D.bajko-pripaddrassignhttp://tools.ietf.org/html/ draft-cui-softwire-b4-translated-ds-lite-05# ref-I-D.bajko-pripaddrassign]. Besides, the DHCP message should send to the concentrator over IPv6. The concentrator can be the DHCP server or DHCP relay agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. = the IPv6-Transport DHCP Relay Agent (TRA, vs, the CRA, IPv6-Transport Client Relay Agent) o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP requests simultaneously to acquire a number ports within the same IPv4 address, = I can't see how this has a real chance to work... IMHO, not specifying the technology to get port range and living this to implementation is a serious shortcoming. We need to standardize one method. = I agree (on the one method, *not* on the proposed method). Thanks francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Me too. And another comment: In sd-nat, it says More importantly, that draft (lightweight 4over6) does not explain how this solution can be deployed in a regular DS-Lite environment. I think this is a deployment issue and lightweight 4over6 can definitely be deployed in a regular DS-Lite environment. We have run a Coexistent test with DS-Lite (refer to http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in Appendix 1.3). It would be very easy and simple. Thoughts? Best wishes Qiong On Wed, Mar 14, 2012 at 10:32 PM, Lee, Yiu yiu_...@cable.comcast.comwrote: I am a little lost. Let's put the double-nat aside for a moment. Except the fact that sd-nat uses icmp for port-set provisioning, what else different between Lightweight 4over6 vs. sd-nat? Am I missing something? For Lightweight 4over6, we can use anycast for redundancy. I fail to see what sd-nat does more than Lightweight 4over6. /Yiu On 3/14/12 8:47 AM, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Med: But the question is why ICMP-based method is needed? Why not using port-restricted DHCPv4 options for instance? ___ 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] IPv4 Residual Deployment - Unified-standard proposal 4rd
2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:46, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:00, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 06:51, Maoke a écrit : 2012/3/13 Rémi Després despres.r...@laposte.net 2012-03-13 12:02, Maoke : 2012/3/13 Rémi Després despres.r...@laposte.net ... The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. I missed this one. None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place. alright. so 4rd-U doesn't not support all existing transport protocol either. Never said that without qualifying which protocols. but i suppose you may make an update in the 4rd-u-06 so that a new if...else... is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft. In the Note in 4.4 (7), the first sentence is: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. It can become: This guarantees that, for all protocols that use the same checksum algorithm as TCP and have ports at the same place, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. Similarly, in the comparison table, H6 is: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as future protocols using the TCP checksum algorithm It can become: For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any future protocol that might use the TCP checksum algorithm and ports at the same place then it is fine. with these statement, 4rd-U can support - TCP - UDP - DCCP - any future or less well-known protocol as long as it uses TCP checksum and port at the same place as a counterpart, we may suggest MAP-T to state it supports - TCP - UDP - DCCP (with enforcing it rather than RFC6145's optional) - any future or less well-known protocol, no matter what layout it is nor how the checksum is defined, with the similar logic of L4 checksum recalculation Maybe I get the point you are making: you implicitly consider that BR and CE modifications can be synchronized. This is feasible if ISPs provide all CE nodes, but not in the general case. i don't consider their modifications are synced but i do consider that each device, either BR or CE, should has a specification on its supported functionalities. Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. 1. I agree that, between CEs and BRs, there can be no problem for DCCP (provided the draft is completed to this effect). The comparison table was explicitly made with existing drafts, and intended to be updatable. 2. The MAP-T draft is also claimed to allow communication between IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in the domain that are using IPv4-mapped IPv6 address. In this case, AFAIK, the backward compatibility problem exists Thought? surely it does not exist. that statement applies to the MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same deployment of equipments should support double-translation, single-translation, and native IPv6 accesses simultanenously. that's one of the points of the MAP-T. - maoke To be even more precise, H6 of the comparison table can be: For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, DCCP and UDP-Lite are supported, as well as future protocols using the TCP checksum algorithm and ports at the same place i actually think the original text is fine. For shared IPv4 addresses is not needed for 4rd-U, to my understanding, nor needed to MAP-T. Will see what to do, then, when changes to the MAP-T draft concerning DCCP are known. RD maoke Does this cover the point? RD ;-) maoke but
[Softwires] Apology
Behcet, I apologize. Even if we differ on what constitutes a multicast solution, I was wrong to refer to your drafts in a pejorative manner. Tom Taylor ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
