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-pripaddrassign<http://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
