Re: Hop Limit in Inner Header (IPv6)

[Peter Curran <[e-mail]>]

It sounds as if there is a danger of creating an illogicality here.

When IPv6 automatic tunnels are used to connect two IPv6/IPv4 nodes (across
an IPv4 network of any size) then the inner packet hop-limit is not
decremented because both hosts are on the same logical link connecting
them.  As the packet is not *forwarded* into the tunnel, then the hop-limit
remains unchanged.

By the same logic, why should the hop-limit be decremented when the packet
is being sent across an IPSEC tunnel that exists between the same two nodes?

IMHO, this shouuld not happen because it is not logical.  If the packet
originated on a 3rd node, was passed to the 1st and then sent down a tunnel
to the 2nd then I agree the hop-limit should be deceremented - the packet
is forwarded from one link to another.

The proposed mechanism will break NDP.

Another question that should be considered relates to the scope of the IPv6
addresses. Is it illogical for an IPSEC tunnel to exist between two nodes,
if the end-points of the tunnel are recognised by link local addresses and
yet not on the same physical link?  What if they are not on the same site?

In the former case, link local addresses could be assigned to the tunnel
ends - the two devices will be on the same logical link.

Peter
TICL


At 21:27 16/04/98 -0400, Steve Bellovin wrote:
>	    From: Karen Heron <[e-mail]>
>	    Date: Wed, 15 Apr 1998 07:49:03 -0400
>	
>	    In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Constructio
>	n
>	    for Tunnel Mode, the inner header Hop Limit is decremented.  This
>	    will cause problems for securing IPv6 NDP traffic.  The hop limit i
>	s
>	    set to 255 in NDP packets and checked in the receiving node to make
>	    sure it came from the same link.  If this NDP exchange is secured
>	    using tunnel mode and the hop limit is decremented before the packe
>	t
>	    is encapsulated, the receiving node will reject the NDP packet and
>	    neighbor discovery will fail, even if the two nodes are on the same
>	    link.  Should the Hop Limit not be decremented for locally generate
>	d
>	    traffic?  If not, I don't see how NDP traffic can be secured using
>	    tunnel mode - maybe I've missed something in the drafts that said
>	    this.  If this question has already been answered, I'd appreciate a
>	    pointer to the discussion (I didn't see it in the archives).
>	
>	Karen,
>		I would think that if a packet originates at host A, and the
>	packet then gets encapsulated by security gateway G and sent down the
>	IPSEC tunnel to host B, that host A and host B are not on the same
>	network.  
>	
>		In fact, even if the packet is originated and encapsulated at
>	host A, and sent over a IPSEC tunnel, which might send the packet
>	halfway across the world, when it is decapsulated at host B, the hop
>	count should be decremented, since it is extremely unlikely that they
>	are really "neighbors".
>	
>		I'm not completely familiar with what exactly NDP is trying to
>	do, but if you're using tunnel mode, you can't distinguish between
>	whether your communications partner is on the same ethernet, or on the
>	wrong side of MAE-EAST (you can tell that by the number of packets tha
>	t
>	get dropped, though :-).  If this is what NDP is trying to do, then
>	fundamentally you shouldn't be using tunnel mode.  Whether you always
>	decrement the hop count, as the spec currently states, or never
>	decrement the hop count, you still don't know whether someone is next
>	door or on the other side of the planet.
>
>My own view is that a tunnel is a virtual wire between two nodes.  NDP
>should work across that tunnel only to the extent that the packet
>originated on one endpoint and terminated on the other.  ("Neighbor" is
>a topological construct here, and ignores phyiscal reality.)
>