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