Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Alain Durand [mailto:adur...@juniper.net] > Envoyé : jeudi 15 mars 2012 12:11 > À : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG; > draft-cui-softwire-b4-translated-ds-lite > Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. > draft-cui-softwire-b4-translated-ds-lite > 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. Med: This is deployment-specific. The behaviour to follow when a port-restricted device issues port out of its allocated range should be IMO SP specific and can not be dictated by the specification. > > > (*) 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. > > 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. Med: Changing the size of the port range is part of planned operations. With DHCP, an SP can change the port range much in advance. This is nothing something which can be done without advanced planning. I don't see an advantage of ICMP here. > This allows for more flexibility in micro-managing ports. Med: This is also doable with DHCP and PCP by tweaking the Lease and the Lifetime. > 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 Med: This doable with existing ICMP messages. Nothing prevent the AFTR to drop the packet and send back an ICMP Destination Unreachable message Code 3 "Port unreachable error" or Code 13 "Communication administratively prohibited". > 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. Med: No need to define a new ICMP message for this. Why not using e.g. ICMP Type 3 Code 13? _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
