Hi Magnus, to, 2020-04-02 kello 22:56 +0300, Miika Komu kirjoitti: > > > 4. MTU impact of NAT traversal. > > > > Section 5.1 states > > "It is worth noting that UDP encapsulation of HIP packets reduces > > the > > Maximum Transfer Unit (MTU) size of the control plane by 12 > > bytes." > > > > There is also a similar text in Section 5.11: > > > > It is worth noting that UDP encapsulation of ESP reduces the MTU > > size > > of data plane by 8 bytes. > > > > I think the document needs a discussion and impact on MTU which > > this > > NAT > > traversal has on the HIP packets being sent. - First of all there > > appears to be > > more packet expansions happening in some cases, for example the > > RELAY_HMAC > > option expands packets on one leg. - Secondly, HIP requires IP > > fragementation > > support, however IP fragmentation through NAT is commonly not > > working. Thus an > > HIP packet being UDP encapsulated that results in packet exceeding > > MTU will > > likely end up in an MTU black hole on path. > > > > The addition of the NAT traversal encapsulation actually increases > > the need for > > MTU discovery or care in MTU handling by the HIP initiator. I think > > there need > > to be discussion of that in the document. > > I am stil iterating some text on this, I hope Jeff Ahrenholz can help > with this.
I got text from Jeff Ahrenholz and Robert Moskowitz: Section 5.2 replaced this: It is worth noting that UDP encapsulation of HIP packets reduces the Maximum Transfer Unit (MTU) size of the control plane by 12 bytes. with: UDP encapsulation of HIP packets reduces the Maximum Transfer Unit (MTU) size of the control plane by 12 bytes (8-byte UDP header plus 4-byte zero SPI marker), and the data plane by 8 bytes. This encapsulation overhead increases the need for MTU discovery. A HIP host SHOULD have the option to enable ICMP path MTU discovery (PMTUD) [RFC1063] [RFC8201]. Otherwise, support for IP fragmentation is required, which may not be commonly supported through NATs. When HIP encapsulation is implemented using a virtual tunneling interface, consider using a reduced MTU (e.g. 1400) by default. Additional HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further increase the size of certain HIP packets. It is worth noting that further HIP extensions can trim off 8 bytes in the ESP header by negotiating implicit IV support in the ESP_TRANSFORM parameter as described in [RFC8750]. Does this address your concerns? Btw, I would remove the following redundant statement in "RELAYED_ADDRESS and MAPPED_ADDRESS Parameters" section: It is worth noting that UDP encapsulation of ESP reduces the MTU size of data plane by 8 bytes. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
