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

Pekka Savola <pekkas@netcore.fi> Fri, 02 June 2006 05:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2Ri-00067V-KE; Fri, 02 Jun 2006 01:43:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2Rh-00067Q-Jc for int-area@ietf.org; Fri, 02 Jun 2006 01:43:41 -0400
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm2Rc-0000OI-QZ for int-area@ietf.org; Fri, 02 Jun 2006 01:43:41 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k525hW7m012949; Fri, 2 Jun 2006 08:43:33 +0300
Date: Fri, 02 Jun 2006 08:43:32 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: int-area@ietf.org
Message-ID: <Pine.LNX.4.64.0606020830220.12705@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: ClamAV 0.88.2/1505/Thu Jun 1 21:29:37 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: "Charles E. Perkins" <charliep@iprg.nokia.com>
Subject: [Int-area] IP-in-IP, TTL decrementing when forwarding and BITW
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Errors-To: int-area-bounces@lists.ietf.org

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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area