Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

Mark Smith <> Tue, 31 October 2017 08:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7529F1398CA for <>; Tue, 31 Oct 2017 01:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OEronH9iiwMY for <>; Tue, 31 Oct 2017 01:13:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D94E9138A4C for <>; Tue, 31 Oct 2017 01:13:38 -0700 (PDT)
Received: by with SMTP id g11so9760372vkd.13 for <>; Tue, 31 Oct 2017 01:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I4qkzu3iG9VxGk+gzJj8skJN6I+VlrEq9DokqDo9UnE=; b=Nbnv3ZiVYN567LCHIBj9VcqvbvLwWMSOz3jPbxkeqeFC5Dx+g6/zxeJaCqHK+gz1gy 1uSm+DenHjfr+a/dIz+RrscCfaEtt84HUxN3BUqmvBTv31OytuZRpr5tLya7jy3P8cVz +Xhpi9lDB3n40cckcBfYKpFRmVHCSZPDd4MRhuG3xk3MzMRhrubr0h7ij9kqfKUZBMVw pFErLKeAMjUhkRKxWyT6s/UTEbQVZ4HPVsnxw/wGjhQHsoKtqbtzELRPL4+nUR0m+9q8 v1CfxtaMSdhROHpxASj+zB7Eow5xfv+bF+f90mKFaSd3vM1vKDezIqglhmZpspqCZ/OH MWUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I4qkzu3iG9VxGk+gzJj8skJN6I+VlrEq9DokqDo9UnE=; b=sgQAfh5JNHDDuguG8X4l+020Bf4JtwCM8mA2Bm0a92sV6rrPCMIqpByvVfatNfpmo/ vh2h57HspjZlCvj+WQ4bCdakJ5KFTq9hJMXRpw7JdmM3skIxybMPKKVUoH3OGH89QiUm 8Up53kAuQ1N3U9cLQrYOHhGUV6A22XnxjtdmiXG1vPpU/S2rHIR5R2iMioukTypSlUcy iDxwbXfCnNgF1Y/T35kDfEH0eDewrO8b+3Nd9K1QBAWFiFb5doATOn6KSoN28jva6dg8 y4MlT4Lrzg9LecUoY1LecIgn9AZz8ekDCYvus2ltzBKvYKYoHos3b2j3DEeNxWPwN3QG uplQ==
X-Gm-Message-State: AMCzsaUVocmQI1BXD1ChLJbEyp2r8rnd2EejPUC4KXCrSCsWUKeTC+Jw 8uCr/4H+pe9dtKnDIB1geWSReXjw/Vnqj4ceA7Q=
X-Google-Smtp-Source: ABhQp+SvxihNuvXuh3zKqpkoTTLg57+s29qZYcvfyxPOGHPcmy27UkkVqBz+yAteoEgEZMU4CqTw2/CWruURJB9N0Mo=
X-Received: by with SMTP id i7mr741381vkg.11.1509437617678; Tue, 31 Oct 2017 01:13:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 31 Oct 2017 01:13:36 -0700 (PDT)
Received: by with HTTP; Tue, 31 Oct 2017 01:13:36 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Mark Smith <>
Date: Tue, 31 Oct 2017 19:13:36 +1100
Message-ID: <>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Michael Richardson <>
Cc: 6man WG <>
Content-Type: multipart/alternative; boundary="001a114e2da6032f0e055cd355a8"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Oct 2017 08:13:41 -0000

On 31 Oct. 2017 11:02, "Michael Richardson" <> wrote:

Tim, Tim and John, thanks again for taking on 6434bis.

Let me open a can of worms, now that the draft deadline has just passed :-)

We argued lots in producing RFC8200 that one solution for inserting headers
mid-way was to add an IPIP header.   If we really think that this is
operationally possible(*), then I think we need to write text in 6434bis to
it true.

For some uses of IPIP-based header insertion there can be clearly a node (a
router probably) which could then remove the newly inserted header, and the
IPIP header added can be addressed to that node (%).   This is an IPIP
tunnel.  I
believe that LISP does something like this, and many of us are familiar with
IPsec tunnel mode as well.

For many other uses, the only obvious target for the IPIP header is the same
destination address as what was originally there, and so a packet like:
            IP{src:A, dst: B} ULP

            IP{src:D, dst: B} IP{src:A, dst: B} ULP

And I think that most host stacks discard such things unless configured to
expect a tunnel from D.

What to do?

I'd like to make it clear that the above construct is valid and that hosts
SHOULD process it to remove the first IPIP hader and then process the packet
as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then

I don't think this decapsulation is forwarding. Forwarding is really just
what to do when receiving a packet with a DA that doesn't match the
device's address(es). Hosts drop them, routers see what the forwarding
table says to do with them.

The processing you're describing is passing the payload, post
decapsulation, to the payload processing module indicated by the payload
type field in the previous header.

In the case of IPinIP, the host supports the payload type of IPinIP or
protocol 4, and knows that a payload of that type gets submitted to the
IPv4 packet processing module. If the DA of the payload IP packet matches
the host's, then it should be processed the same way as the former outer
packet was. IPinIPinIP should be processed the same way as IPinIP.


There are also implications for security devices, but in most respects I
don't think that they are different than for extension headers.

As an aside, it would also be nice if we could say that an IPsec AH header
with an unknown SPI should be skipped as if it wasn't even there (including
any subsequent IP header as above..)  This is essentially a similar
situation.  I suspect that this statement is even more controversial.

(*)- I think it's operationally possible, and draft-ietf-roll-useofrplinfo
     explains how to do it within the controlled environment of an LLN.
     I spent half the morning putting final touches to that...

(%)- for the cases where an "exit" node is easy to identify, and the traffic
     is guarantee to get to, doing a non-IPIP header insertion is even
     to argue for.  Any arguments that the packet might "escape" being
     un-molested are arguments for why 6434bis has to deal with IPIP

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

IETF IPv6 working group mailing list
Administrative Requests: