> > > >This is a deployment issue. You have 3 variants of DS-Lite CPEs: >a) Basic 6333 DS-Lite, b) B4 translated DS-lite, and c) Stateless DS-Lite. >You want to be able able to accommodate all 3 variants from the same AFTR. >Re-Nating instead of dropping ensure that if a subscriber uses a variant >b) when >he is provisioned to use port restricted, then traffic still flows. > 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.
> > (*) Question 4: Given this list, is there really a need for the > proposed ICMP-based solution? > >IMHO, not specifying the technology to get pot range and >living this to implementation is a serious shortcoming. >We need to standardize one method. 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. > >Med: But the question is why ICMP-based method is needed? Why not using >port-restricted DHCPv4 options for instance? > > >1) - we would have to define the DHCP port option. Not difficult but same >amount of work as defining a new ICMP type. >2) - with the ICMP message, the ISP can change the port range without >having to wait for the lease time of the DHCP option to expire. > This allows for more flexibility in micro-managing ports. 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. In the end, A+P is extending the address with more bits from the port. 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? Case 1, it will affect user experience; 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. If dynamic port assignment is so important, why not use ds-lite instead? >3) - if we use a DHCP option, the client has to proactively ask for it. >If it does not, it will think it has the full IP address. That leads to >situations that may be difficult to debug, as the customer will not >understand why some TCP session works and some don't, the root cause >being that the CPE does not have any feedback from the NAT in the AFTR If the CPE was configured to get A+P but only asked for A, I consider this is a configuration error. Even aftr used icmp to provision the port, the CPE could still think it has the full address. I don't see how icmp could solve configuration error. >4) - so we'll need a new ICMP message anyway to signal the CPE that >something is wrong if/when it sends packets outside of the range. > >The advantage of the DHCP option is that the CPE does not need to send >the packet with src port 0 at regular intervals, this is all taken care >by the DHCP machinery. IMHO, this does not outweight the issues mentioned >above, especially 3) & 4). > >Alain >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
