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 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 > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
