Hi Francis, Thanks for your reply. Please see inline.
On Wed, Mar 14, 2012 at 12:55 AM, Francis Dupont <francis.dup...@fdupont.fr>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. > > > (*) 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
