>
> What I would've expected to happen is that 'Gateway A' would send out
> two fragmented IPv6 packets containing the encrypted data. 'Gateway A'
> is the originator of the IPv6 ESP packet so it can fragment these.
> This similar to how it's done for IPv4. When the ESP is fragmented
> then the IPv6 packet from 'client A' is left intact/not fragmented.
>
> With my - limited - understanding of the IPv6 RFC I think this would
> be allowed.
Parts from the IPv6 RFC that I think are relevant:
5. Packet Size Issues
IPv6 requires that every link in the internet have an MTU of 1280
octets or greater. On any link that cannot convey a 1280-octet
packet in one piece, link-specific fragmentation and reassembly must
be provided at a layer below IPv6.
+
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernets (simple
or bridged); PPP links; X.25, Frame Relay, or ATM
networks; and internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself.
*My* interpretation from this: an IPv6 IPsec tunnel is considered a "link"
in the IPv6 RFC.
This means that the mtu inside an IPsec tunnel - which tunnels IPv6
traffic - must be at least 1280 octets.
What this technically means for IPsec: when the path-mtu between the
two IPsec Gateways is 1280 then the IPsec tunnel should still provide
a 1280 octets mtu inside the IPsec tunnel.
The way it can do this is by transmitting fragmented IPv6 ESP packets.
[Data inside the tunnel is *not* fragmented]
Before continuing: is my understanding correct? and/or does everyone
agree with the above?
Is it reasonable to expect tunneling to work when path-mtu between
the IPsec gateways is 1280?
(In case it is reasonable then one can discuss what the mtu inside
the tunnel should be when path-mtu is 1280 (or better put when
path-mtu - ESP overhead < 1280) - but let's leave that discussion
for later)
