Hi Brian, Thanks for the review. I wanted to clarify three points that you raised and I will ask the authors take care of the rest.
On 02/11/2013 04:11 PM, Brian Haberman wrote: > 7. In Section 4.1.2, it would be good to describe any issues that the > approach has with the original use of the Identification field for > fragmentation reassembly. If a middlebox changes the ID field, weird > things can/will happen if those packets are fragmented somewhere. Agree. I think this is precisely the reason that the mechanism for putting the HOST_ID in the IP-ID is a non-starter. > 11. Is Section 4.6 theoretical or is there a specific reference that can > be added for this technique? There are several mechanisms that use port sets for IPv4 address sharing. A+P (RFC6346) is one such mechanism. > 15. Section 5 > > * Shouldn't there be an additional metric that covers the impact/cost of > needing client or middlebox code changes? > > * Where did the 100% success ratio for IP-ID come from? There have been > documented cases of OSes setting the Identification field to zero. If > that is true, the success ratio can't be 100% can it? This technique involves the translator (and not the sender) setting the IP-ID field. That is why it can still work with OSes on senders setting the IP-ID to zero. Thanks Suresh _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
