Re: [v6ops] Operational Consensus on deployment

[Tore Anderson <[e-mail]>]

* Philip Homburg

> One of my replies to Tore already contains an example. Middle box
> implements MSS clamping wrong. This breaks IPv4 for any service that
> has a path MTU of less then the PPPoE MTU.

You're quite right that the header size difference between IPv4 and IPv6
is something one would need to consider. This consideration is similar
to that to other tunneling or translation mechanisms like GRE, DS-Lite,
MAP, 6RD, PPPoE and so forth. There are some differences though:

- It is only really a concern for packets flowing in the client->server
direction (IPv4->IPv6), as a 1500 byte large packet originated by the
IPv6 server would be translated into a 1480 byte large IPv4 packet,
which isn't problematic. (For content providers, most large packets go
in the unproblematic server->client direction.)

- All potential issues can be mitigated by raising the MTU by 20 bytes
(to 1520) in the IPv6 domain (to 1520). While this is of course true for
all the other mechanisms I mentioned too, actually doing it is likely to
be easier to do in a data centre environment than e.g. in an ISP's
access network.

- There is no need for TCP MSS clamping, as the IPv6 servers will
advertise an appropriate TCP MSS to the clients (1440). This causes the
IPv4 clients to limit their packet size to 1480, which translates into
1500 byte large IPv6 packets.

- Finally, for protocols other than TCP (and other protocols that have a
mechanism similar to TCP's MSS), there are two things that can happen
for IPv4 packets larger than 1480 bytes destined for an IPv6 server
(assuming the IPv6 domain's MTU is 1500):
  - If the DF flag is set, it's PMTUD time, as the SIIT gateway will
    emit an ICMPv4 Fragmentation Needed packet. This is likely
    unreliable.
  - If the DF flag isn't set, it results in a fragmented IPv6
    packet. This can be reliable, as the fragmented packets do not
    propagate out of the data centre, and as such the operator can
    ensure that they work.

In any case, the draft already discusses this:

http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html#rfc.section.3.8

Please let me know if you find any of the text there is incorrect,
confusing, incomplete, or if you have other suggestions on how to
improve it.

Tore