[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PMTU/DF issues



Hello,

> 		b) hold the PMTU information until another too-big
> 		   packet arrives and then use that packet and the PMTU
> 		   information to construct a ICMP PMTU for the
> 		   originating host (H0).
>
>>This is what is described in RFC-1853:
>>
>>   The router uses the ICMP messages it receives from the interior of a
>>   tunnel to update the soft state information for that tunnel.  When
>>   subsequent datagrams arrive that would transit the tunnel, the router
>>   checks the soft state for the tunnel.  If the datagram would violate
>>   the state of the tunnel (such as the MTU is greater than the tunnel
>>   MTU when Don't Fragment is set), the router sends an appropriate ICMP
>>   error message back to the originator, but also forwards the datagram
>>   into the tunnel.  Forwarding the datagram despite returning the error
>>   message ensures that changes in tunnel state will be learned.
>>
>>Rather than putting all of this into the Architecture document, I'd
>>think it would be more efficacious to update RFC-1853.

	Assuming that by "this" you mean the entire PMTU/DF discussion
	and appendix (as opposed to just the section you copied in your
	email)....  Certainly referencing RFC-1853 seems appropriate.
	However, since PMTU/DF is only one of several IPSEC issues that
	are relevant to IPSEC tunneling and this decision, we'd like to
	discuss the other issues before deciding where to document them.
	For example, RFC-1853 addresses only IPv4 and we plan to discuss
	IPv4 and IPv6 tunneling.

Thank you,
Karen