Re: [Int-area] IP-in-IP, TTL decrementing when forwarding and BITW

FWIW, there are two cases I considered where tunnel decrementing might
not occur:

	1) BITW
		typically this is for IPsec tunnels, which are
		spec'd in 4301, but which in spirit ought to follow
		2003

		they might also be used for range-extenders

	2) host-host tunnels
		in this case, there is no forwarding step,
		i.e., packets generated at the same node
		as the tunnel encapsulator and destined
		for the same node as the tunnel decapsulator

Joe

Pekka Savola wrote:
> Hi,
> 
> In TCPM WG, while discussing draft-ietf-tcpm-tcp-antispoof section
> 3.2.1, we came across something that may or may not be an issue in
> IP-in-IP tunneling spec (RFC 2003).  The spec says (see below) "[inner
> header TTL is decremented], if the tunneling is being done as part of
> forwarding the datagram, ..."
> 
> Joe's interpretation is that BITW implementations of IP-in-IP need not
> decrement inner header TTL.  Personally, I don't think RFC 2003 was even
> intended to cover BITW implementations.
> 
> This may become important if you want to apply GTSM (i.e. TTL=255
> checking) to encapsulated packets between the two endpoints of the
> tunnel.  If BITW implementation is acceptable, the topological area
> where TTL=255 applies expands slightly.
> 
> Does anyone recall the intent of the RFC?
> Is anyone aware of BITW implementations of RFC 2003?
> Or do folks have strong feelings what the intent should be?
> 
> Joe Touch said:
>> RFC2003, sec 3.1, third-to-last (emphasis mine):
>>
>>   When encapsulating a datagram, the TTL in the inner IP header is
>>   decremented by one **if the tunneling is being done as part of
>>   forwarding the datagram**; **otherwise, the inner header TTL is not
>>   changed during encapsulation**.  If the resulting TTL in the inner IP
>>   header is 0, the datagram is discarded and an ICMP Time Exceeded
>>   message SHOULD be returned to the sender.  An encapsulator MUST NOT
>>   encapsulate a datagram with TTL = 0.
>>
>> If that packet is generated at that node, or if the packet is sent to
>> the tunnel in a non-forwarding (BITW) step, that decrement would not
>> happen.
>>
>>   The TTL in the inner IP header is **not changed when decapsulating**.
>>   If, after decapsulation, the inner datagram has TTL = 0, the
>>   decapsulator MUST discard the datagram. If, after decapsulation, the
>>   decapsulator forwards the datagram to one of its network interfaces,
>>   **it will decrement the TTL as a result of doing normal IP
>> forwarding**.
>>   See also Section 4.4.
>>
>> The decapsulator decrements only if forwarding - again, if the packet
>> stops at the destination or if the device isn't a forwarder (BITW), that
>> wouldn't happen.
> 

Re: [Int-area] IP-in-IP, TTL decrementing when forwarding and BITW

Attachment: signature.asc