Jari Arkko writes: Cheryl Madson worries about the effects the
per-virtual interface SPD policies have an path MTU discovery.  Here's
the problem: depending on which type of packet (e.g. HOTI vs. payload
packet) goes out on the virtual tunnel interface towards the home
agent, the result is either IPsec encapsulation or some other
encapsulation. These encapsulations have a different header overhead.
However, typically MTU determination is on implementations is made
*before* the packet enters a specific interface. This means that
depending on which encapsulation has been used to determine the path
MTU, long packets will either (a) be too long and have to be
fragmented eventually or (b) be too short and not take the full
advange of the available MTU.

What can we do? The virtual interfaces are in part a result of our
optimized packet formats (use care-of addresses instead of HAO), in
part a result of certain other things. Taking them out at this
stage would be hard. Note that the above issue is mainly an
efficiency issue, i.e., things will still work even if the
right MTU is not being used. It is also something that a good
implementation can take care of by considering the MTU issue
beyond the selection of the interface.

Recommendation: Add some text clarifying the implications of
the partial IPsec encapsulation inside a virtual interface,
to warn the implementors that they need to consider this.

----------------

Vijay Devarapalli responds to Jari Arkko: I am fine with adding the
text, but I am not sure if I understood the issue correctly.

Isnt this a generic problem? Lets assume the following scenario.

    host1--------SG1=============SG2--------host2

SG1 and SG2 are IPsec gateways. when host1 sends packets to host2, it
doesnt know that SG1 is adding a tunnel and an IPsec header to each
packet.

in MIPv6

    MN===========================HA---------CN

host1 and SG1 collapse into the same node. SG2 is HA.

am I missing something?

> What can we do? The virtual interfaces are in part a result of our
> optimized packet formats (use care-of addresses instead of HAO), in
> part a result of certain other things. 
 
With optimized packet format you just add an outer IPv6 
header. with non-optimized format, you add a home address 
option in addition to an IPv6 header. the issue exists
irrespective of the format used, right?
 
> Taking them out at this
> stage would be hard. Note that the above issue is mainly an
> efficiency issue, i.e., things will still work even if the
> right MTU is not being used. It is also something that a good
> implementation can take care of by considering the MTU issue
> beyond the selection of the interface.
 
This is always true. if a node is using Mobile IPv6, the IP
stack on that node should leave room for two tunnel headers 
(atleast one) before constructing a packet.
 
----------------

Jari Arkko responds to Vijay Devarapalli: Good points. Maybe you are
not missing anything. Why don't we reject this as a problem. In fact,
when I think about this, the issue sems even more general: it even
appears for "eth0" if not all packets are treated IPsec-wise the same
way on "eth0".

----------------

----------------