Tero, > -----Original Message----- > From: Tero Kivinen [mailto:[email protected]] > Sent: Tuesday, February 09, 2010 6:03 AM > To: Templin, Fred L > Cc: Dave Dolson; Ed Jankiewicz; Behave WG; [email protected] > Subject: Re: [Softwires] [BEHAVE] PMTU Discovery and ICMPv6 filtering > > Templin, Fred L writes: > > > I believe this is referring to mapping of ICMP "too big" messages. When > > > a tunnel end-point receives a "too big" message, it would have to map > > > the message to an ICMP message for the original host. I believe this > > > could be done in a stateless manner using the packet quoted in the > > > message. (RFC2463 says the "too big" message will include "As much of > > > invoking packet as will fit without the ICMPv6 packet exceeding the > > > minimum IPv6 MTU") > > > > But, if the packet-in-error encapsulated in the ICMP > > PTB message is encrypted and not complete (i.e., only > > the leading 1200 or so bytes of the encrypted packet > > are included), how will the tunnel ingress know how to > > decrypt it in order to do the stateless translation? > > If we are talking about IPsec, then that ICMP packet will have the SPI > of the packet, so the gateway can find the related IPsec SA for the > the packet which caused the PTB message to be sent. After that it > simply stores the maximum path MTU it got from the ICMP message to the > IPsec SA.
That would be a stateful means for determining path MTU. I was responding to the assertion that a stateless method was possible. Fred [email protected] > When the next packet comes through which is bigger than what the MTU > stored for the SA (where the MTU is already modified accordingly to > match the overhead of IPsec headers), it will directly send PTB > message back to the original sender of the packet. > > I.e. it will dynamically find out the PMTU for each IPsec SA (taking > the overhead in to account, as it does know the overhead), and then > send PTB messages if packet is bigger than that. > > See section 8.2.1 of RFC4301: > ---------------------------------------------------------------------- > 8.2.1. Propagation of PMTU > > When an IPsec implementation receives an unauthenticated PMTU > message, and it is configured to process (vs. ignore) such messages, > it maps the message to the SA to which it corresponds. This mapping > is effected by extracting the header information from the payload of > the PMTU message and applying the procedure described in Section 5.2. > The PMTU determined by this message is used to update the SAD PMTU > field, taking into account the size of the AH or ESP header that will > be applied, any crypto synchronization data, and the overhead imposed > by an additional IP header, in the case of a tunnel mode SA. > > In a native host implementation, it is possible to maintain PMTU data > at the same granularity as for unprotected communication, so there is > no loss of functionality. Signaling of the PMTU information is > internal to the host. For all other IPsec implementation options, > the PMTU data must be propagated via a synthesized ICMP PMTU. In > these cases, the IPsec implementation SHOULD wait for outbound > traffic to be mapped to the SAD entry. When such traffic arrives, if > the traffic would exceed the updated PMTU value the traffic MUST be > handled as follows: > > Case 1: Original (cleartext) packet is IPv4 and has the DF > bit set. The implementation SHOULD discard the packet > and send a PMTU ICMP message. > > Case 2: Original (cleartext) packet is IPv4 and has the DF > bit clear. The implementation SHOULD fragment (before or > after encryption per its configuration) and then forward > the fragments. It SHOULD NOT send a PMTU ICMP message. > > Case 3: Original (cleartext) packet is IPv6. The implementation > SHOULD discard the packet and send a PMTU ICMP message. > -- > [email protected] _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
