In your previous mail you wrote: > I failed to see how Stateless DS-Lite is different from B4 translated > DS-lite. We need to first understand what sd-NAT is trying to solve, then > decide whether it is needed or not.
=> I agree and IMHO they have the same issue: the per-CPE port range is far too easy to track from the Internet side. IMHO the port restricted CPE is a good idea (it should be deployable in most existing CPEs without changing a bit to kernels) but CGN should provide an algorithmic (including the identity) port translation to shuffle CPE port ranges. > We can easily define a method in the B4 translated DS-lite draft. We have > few on the table (i.e. dhcpv4 over v6 transport, dhcpv6, radius, pcp). We > can ask the WG to decide which one should be in the base spec. This is how > RFC5959 was written. Alternatively, we can do what RFC6333 does. RFC6333 > doesn't have any provision method defined except referring to RFC6334. => I agree on the principle but we should answer to a question first: do we want a mechanism for DS-Lite only or a mechanism applicable to DS-Lite, NAT44 and any other IPv4 CGN? > I need use cases. We don't have any issue using dhcp to manage ip address, > I fail to see why we need a different method to manage port-set. => me too. > Also, if the ISP suddenly changes the port range, what happens to > the existing sessions? The CPE should close all the existing > sessions or wait until the sessions are done? => I had the same question and there are two solutions: a smooth hard to implement and a rude easy to implement, beginning with the second: - flush the whole context (your first case) - kill only connections which are no longer valid (there is nothing to do for them and you can be lucky...) To wait is not an option because they are already blocked by the CGN. > Case 2, sd-aftr must keep track of the ports and don't assign them > to another user until the sessions are done. This sounds adding > load to the aftr. => this is incompatible with port ranges and the fact the lifetime of a session is potentially unbound. So there is nothing smooth/ user-friendly you can do on the SD-CGN other than never restrict assigned port ranges. > port assignment is so important, why not use ds-lite instead? => perhaps to try to make port reassignment of a lower order of annoyance than address reassignment? Regards francis.dup...@fdupont.fr _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
