Michael Richardson <mcr+i...@sandelman.ca> wrote:
> Based upon conversations on the list, this proposal might not even be
IPsec.
> At least, it's not proto=50(ESP)/51(AH), as they are asking for a new
> extension header type.
> The proposal would require allocation of a SPI for a destination address
> which is not the receiving system of the SA.
> It would be negotiated with IKEv2, but that part seems neither here nor
> there.Ben, I asked on an (CDN) IX list if anyone supported >1500 byte packets. Even if you have the slimest possible pseudo-AH header, it will take at least a dozen bytes for the authentication data, which means at least 1520 byte packets or so. None of them support >1500. Now, private peering could certainly arrange 1600 byte packets, and I'll bet that many IXs could be persuaded to up their port limits, but this is a definite concern. ip-tfs lets you slice/dice packets so that they all fit into 1500, and maybe that would be a good option to consider. Different flows could have different treatments, all arranged by IKEv2. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
