Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
In your previous mail you wrote: Today, if a user generates a packet using an illegal IPv4 source address, what would we do? We could drop the packet silently by doing source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should drop the packet silently. = it is a bit different in this case because it is not an illegal port but a misconfigured port. I agree to drop junk packets but for misconfed it is better to send an ICMP 3/13 (unreachable / admin prohibited) by default with a knob to silently drop (in the case you believe there should not be misconfed, for instance because you froze the config 6 month ago). 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
On Mar 17, 2012, at 12:44 PM, Qi Sun wrote: Hi Med, I've read through the draft-penno-* and IMHO it is reasonable in the view of deployment. By configuring the profile (i.e. the per-subscriber mapping table) in the AFTRs, the SPs can achieve an explicit binding between the IPv4 address + port-set and the customer. This can mean the customer pay for the ownership of the IPv4 address + port-set. It is easy to associate address(port-set) assignment with authentication. Best Regards! Qi Sun Thank you for your comment. Indeed, it is both simple and necessary to know on the AFTR which ports belong to which subscriber. It is simple because this can be configured out-of-band (think netconf) from a centralized repository. Note, that, using a centralized repository for subscriber -- IPv4 address port mapping, the service provider has the flexibility to allocate different numbers of ports according to the subscriber profile. More, because the association subscriber -- IPv4 address and port is known, there is no need for logging of any sort on the AFTR. It is necessary because the AFTR is the only place where we can enforce IPv4 ingress filtering, ie put ACLs to check that the incoming tunneled traffic from any given customer is using a legitimate IPv4 address and source port. When the incoming traffic does not match those ingress filtering rules, an ICMP error message must be returned. The idea in SD-NAT is to use this ICMP message to carry the information about the correct port range to use. 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
Today, if a user generates a packet using an illegal IPv4 source address, what would we do? We could drop the packet silently by doing source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should drop the packet silently. On 3/20/12 9:06 AM, Alain Durand adur...@juniper.net wrote: It is necessary because the AFTR is the only place where we can enforce IPv4 ingress filtering, ie put ACLs to check that the incoming tunneled traffic from any given customer is using a legitimate IPv4 address and source port. When the incoming traffic does not match those ingress filtering rules, an ICMP error message must be returned. The idea in SD-NAT is to use this ICMP message to carry the information about the correct port range to use. 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
Hi Yiu, Sending back an ICMP message when receiving a port out of range should be configurable IMHO. When receiving a port out of range, the behaviour of REQ#12 (A, B and C) of http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05#section-3 can be followed by the AFTR. No need to define a new ICMP message for this; ICMP message Type 3 Code 13 is fine for this. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : mardi 20 mars 2012 16:39 À : Alain Durand; Qi Sun 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 Today, if a user generates a packet using an illegal IPv4 source address, what would we do? We could drop the packet silently by doing source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should drop the packet silently. On 3/20/12 9:06 AM, Alain Durand adur...@juniper.net wrote: It is necessary because the AFTR is the only place where we can enforce IPv4 ingress filtering, ie put ACLs to check that the incoming tunneled traffic from any given customer is using a legitimate IPv4 address and source port. When the incoming traffic does not match those ingress filtering rules, an ICMP error message must be returned. The idea in SD-NAT is to use this ICMP message to carry the information about the correct port range to use. ___ 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, I read through the draft-penno-* and IMHO it is reasonable in the view of deployment. By configuring the profile (i.e. the per-subscriber mapping table) in the AFTRs, the SPs can achieve an explicit binding between the IPv4 address + port-set and the customer. This can mean the customer pay for the ownership of the IPv4 address + port-set. It is easy to associate address(port-set) assignment with authentication. Best Regards Qi Sun___ 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 Francis, Please see inline, and sorry if they've been discussed ever :) Looking forward to ur reply~ Best Regards ! Qi Sun From: Francis Dupont Date: 2012-03-14 20:44 To: Qiong 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: 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. [Qi] I failed to catch your idea. IMHO the NAT in the port-restricted CPE should filter the packets of which the port number is out of the assigned range. And such packets is ok to be discarded by the CPE. So will you please give some descriptions on this point? 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. [Qi] Using ICMP for the port range is a new idea AFAIK. However, in order to get the info of the min max port number, it is needed to look up the per-subscriber mapping table which may be huge. I've no idea if it's ok for the ICMP process to do that. And I'm thinking whether it's necessary to make it clear about how to get the min max port number in the draft. [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___ 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 Francis, Yes, you are right. There is no explicit method in PCP to get the external IP address. You know we have both asked for it in early days of PCP but the WG consensus was that we can mimic this by using MAP with short lifetime. As for your PS, this a discussion point for the PCP WG. Cheers, Med -Message d'origine- De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Envoyé : jeudi 15 mars 2012 19:22 À : 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: Med: Why you need an IPv4 address to run PCP? An implementation example would be as follows: * At bootstrap of the CPE, once an AFTR is discovered, use the Plain IPv6 PCP mode and the new opcode and options defined in http://tools.ietf.org/html/draft-tsou-pcp-natcoord-05#section-2 to retrieve an IPv4 address and set of port. = the retrieval of the external address is a function which was explicitely put out of PCP by the WG, for the second you'd like to use an extension which was never discussed. To finish there is a difference between discussing about getting the IPv4 address or getting it with other parameters as port ranges, and my comment is only about the first problem. Regards francis.dup...@fdupont.fr PS: I should add another dimension: do we want a solution for DS-Lite or a solution for DS-Lite, NAT44 or any other kind of IPv4 CGNs? ___ 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-, Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : jeudi 15 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 This is a deployment issue. You have 3 variants of DS-Lite CPEs: a) Basic 6333 DS-Lite, b) B4 translated DS-lite, and c) Stateless DS-Lite. You want to be able able to accommodate all 3 variants from the same AFTR. Re-Nating instead of dropping ensure that if a subscriber uses a variant b) when he is provisioned to use port restricted, then traffic still flows. Med: This is deployment-specific. The behaviour to follow when a port-restricted device issues port out of its allocated range should be IMO SP specific and can not be dictated by the specification. (*) 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? 1) - we would have to define the DHCP port option. Not difficult but same amount of work as defining a new ICMP type. 2) - with the ICMP message, the ISP can change the port range without having to wait for the lease time of the DHCP option to expire. Med: Changing the size of the port range is part of planned operations. With DHCP, an SP can change the port range much in advance. This is nothing something which can be done without advanced planning. I don't see an advantage of ICMP here. This allows for more flexibility in micro-managing ports. Med: This is also doable with DHCP and PCP by tweaking the Lease and the Lifetime. 3) - if we use a DHCP option, the client has to proactively ask for it. If it does not, it will think it has the full IP address. That leads to situations that may be difficult to debug, as the customer will not understand why some TCP session works and some don't, the root cause being that the CPE does not have any feedback from the NAT in the AFTR Med: This doable with existing ICMP messages. Nothing prevent the AFTR to drop the packet and send back an ICMP Destination Unreachable message Code 3 Port unreachable error or Code 13 Communication administratively prohibited. 4) - so we'll need a new ICMP message anyway to signal the CPE that something is wrong if/when it sends packets outside of the range. Med: No need to define a new ICMP message for this. Why not using e.g. ICMP Type 3 Code 13? ___ 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
On Mar 14, 2012, at 2:34 PM, Francis Dupont wrote: 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). This 2nd NAT was the case in sdnat-01. This has changed in sdnat-02, where the SD-CPE pre-shape IPv4 traffic with both address port, so the SD-AFTR does only decapsulation and ACL check. No NAT is done at all in the SD-AFTR. - 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
In your previous mail you wrote: Med: Why you need an IPv4 address to run PCP? An implementation example would be as follows: * At bootstrap of the CPE, once an AFTR is discovered, use the Plain IPv6 PCP mode and the new opcode and options defined in http://tools.ietf.org/html/draft-tsou-pcp-natcoord-05#section-2 to retrieve an IPv4 address and set of port. = the retrieval of the external address is a function which was explicitely put out of PCP by the WG, for the second you'd like to use an extension which was never discussed. To finish there is a difference between discussing about getting the IPv4 address or getting it with other parameters as port ranges, and my comment is only about the first problem. Regards francis.dup...@fdupont.fr PS: I should add another dimension: do we want a solution for DS-Lite or a solution for DS-Lite, NAT44 or any other kind of IPv4 CGNs? ___ 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: Med: The PCP case has been demoed. = My comment is about PCP without any extension. In the second demonstration scenario, the CPE requested several sets of noncontiguous ports (utilizing draft-tsou-pcp-natcoord-03 and draft-zhou-softwire-b4-nat-02). = so this doesn't apply. Regards francis.dup...@fdupont.fr PS: we already have a configuration protocol, it is named DHCP. ___ 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: [Qiong] We also have implemented and demoed in IETF 81th. Please refer to http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in Appendix section. = same: my comment is about the base PCP for port range discovery. 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
In your previous mail you wrote: 1) - we would have to define the DHCP port option. Not difficult but same amount of work as defining a new ICMP type. = is it a joke? DHCP has an extension mechanism, not ICMP. 2) - with the ICMP message, the ISP can change the port range without having to wait for the lease time of the DHCP option to expire. = I don't understand the argument: - there is no lease time for an option - when the ISP change the port range it raises an ICMP error for the first packet which falls outside the new range - when the CPE receives the ICMP error it refreshes the port range info So the mechanism doesn't rely in the info being carried in the ICMP. Note this doesn't solves 2 cases where the ICMP can't help: - when the port range is in fact the ICMP echo ID range - when the port range is extended 3) - if we use a DHCP option, the client has to proactively ask for it. If it does not, it will think it has the full IP address. = there are many ways to solve this, for instance the server can refuse to give an IP address or recognize the CPE as being not SD-CPE capable, etc. 4) - so we'll need a new ICMP message anyway to signal the CPE that something is wrong if/when it sends packets outside of the range. = ICMPv4 administratively prohibited (no need for a new message). The advantage of the DHCP option is that the CPE does not need to send the packet with src port 0 at regular intervals, this is all taken care by the DHCP machinery. IMHO, this does not outweight the issues mentioned above, especially 3) 4). = port 0 is invalid so will be likely drop sooner than expected. I don't even believe the ICMP stuff of draft-penno-softwire-sdnat could work in a lab, so in the real world... 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
In your previous mail you wrote: I failed to see how Stateless DS-Lite is different from B4 translated DS-lite. We need to first understand what sd-NAT is trying to solve, then decide whether it is needed or not. = I agree and IMHO they have the same issue: the per-CPE port range is far too easy to track from the Internet side. IMHO the port restricted CPE is a good idea (it should be deployable in most existing CPEs without changing a bit to kernels) but CGN should provide an algorithmic (including the identity) port translation to shuffle CPE port ranges. We can easily define a method in the B4 translated DS-lite draft. We have few on the table (i.e. dhcpv4 over v6 transport, dhcpv6, radius, pcp). We can ask the WG to decide which one should be in the base spec. This is how RFC5959 was written. Alternatively, we can do what RFC6333 does. RFC6333 doesn't have any provision method defined except referring to RFC6334. = I agree on the principle but we should answer to a question first: do we want a mechanism for DS-Lite only or a mechanism applicable to DS-Lite, NAT44 and any other IPv4 CGN? I need use cases. We don't have any issue using dhcp to manage ip address, I fail to see why we need a different method to manage port-set. = me too. Also, if the ISP suddenly changes the port range, what happens to the existing sessions? The CPE should close all the existing sessions or wait until the sessions are done? = I had the same question and there are two solutions: a smooth hard to implement and a rude easy to implement, beginning with the second: - flush the whole context (your first case) - kill only connections which are no longer valid (there is nothing to do for them and you can be lucky...) To wait is not an option because they are already blocked by the CGN. Case 2, sd-aftr must keep track of the ports and don't assign them to another user until the sessions are done. This sounds adding load to the aftr. = this is incompatible with port ranges and the fact the lifetime of a session is potentially unbound. So there is nothing smooth/ user-friendly you can do on the SD-CGN other than never restrict assigned port ranges. port assignment is so important, why not use ds-lite instead? = perhaps to try to make port reassignment of a lower order of annoyance than address reassignment? 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
In your previous mail you wrote: +1 Re-, Please see inline. (I cut here: too long and unreable with not-ASCII characters, quoted-printable silly coding and long lines) 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
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
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] 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] 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] 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] 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] 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 trace, I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). 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
Hi Francis, Thanks for your reply. Please see inline. On Wed, Mar 14, 2012 at 12:55 AM, Francis Dupont francis.dup...@fdupont.frwrote: 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. (*) 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? [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. (*) 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) [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. 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 trace, I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). [Qiong] Since it is a stateless solution, I also prefer the GMA algorithm which has been discusses widely in the WG. Best wishes Qiong Regards francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
2012/3/14, Francis Dupont francis.dup...@fdupont.fr: 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) 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? BRs Gang ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
