Hi Suresh,
On 2/11/13 7:08 PM, Suresh Krishnan wrote:
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.
I agree. But that rationale should be in the draft.
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.
Then I would ask that a reference be put in to give readers an example.
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.
You still have the issue of the middlebox setting that ID to something
that potentially impacts fragmentation reassembly. So, I would still
like to know how that 100% success ratio was collected.
Regards,
Brian
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
