In your previous mail you wrote: > 1) - we would have to define the DHCP port option. Not difficult but > same amount of work as defining a new ICMP type.
=> is it a joke? DHCP has an extension mechanism, not ICMP. > 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. => I don't understand the argument: - there is no lease time for an option - when the ISP change the port range it raises an ICMP error for the first packet which falls outside the new range - when the CPE receives the ICMP error it refreshes the port range info So the mechanism doesn't rely in the info being carried in the ICMP. Note this doesn't solves 2 cases where the ICMP can't help: - when the port range is in fact the ICMP echo ID range - when the port range is extended > 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. => there are many ways to solve this, for instance the server can refuse to give an IP address or recognize the CPE as being not SD-CPE capable, etc. > 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. => ICMPv4 administratively prohibited (no need for a new message). > 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). => port 0 is invalid so will be likely drop sooner than expected. I don't even believe the ICMP stuff of draft-penno-softwire-sdnat could work in a lab, so in the real world... Regards [email protected] _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
