Hi Francis, Please see inline.
Cheers, Med > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] > Envoyé : mardi 13 mars 2012 17:56 > À : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : [email protected]; 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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
