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

Fernando Gont <fgont@si6networks.com> Sun, 12 November 2017 21:22 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0161273B1 for <ipv6@ietfa.amsl.com>; Sun, 12 Nov 2017 13:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.852
X-Spam-Level:
X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP5kWyRwFO58 for <ipv6@ietfa.amsl.com>; Sun, 12 Nov 2017 13:22:36 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F901124F57 for <ipv6@ietf.org>; Sun, 12 Nov 2017 13:22:36 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4] (unknown [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 177D980548; Sun, 12 Nov 2017 22:22:28 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Cc: "C. M. Heard" <heard@pobox.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Fernando Gont <fernando@gont.com.ar>
References: <CACL_3VETxNVQ+YD5j6ZiWjycQ=ojAuWwB23offNdVKm+S9c_7A@mail.gmail.com> <23308.1509623865@obiwan.sandelman.ca> <CACL_3VFrcombGczXU6Zz=Pk1u2GE=wGG-r+yEefdHai1REqXmQ@mail.gmail.com> <c8911f45-2afc-9d26-c0a8-1017d034a251@gmail.com> <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com> <12447.1510153859@obiwan.sandelman.ca> <c104cb05-ee8f-7958-338b-1e30aa7942d1@gmail.com> <C62FA0EB-A212-47D0-B527-CB53946E127F@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <45f01790-0561-68b9-e245-0a126c7e110b@si6networks.com>
Date: Sun, 12 Nov 2017 14:52:35 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <C62FA0EB-A212-47D0-B527-CB53946E127F@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SIwb_wR_jNtsScESo0ybo8uvdO0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Nov 2017 21:22:38 -0000

Hi, Bob,

On 11/12/2017 10:50 AM, Bob Hinden wrote:
> I went back and looked at the RFC8200 text that deals with header insertion.  It does not actually mention IPIP.  The published text in Section 4. "IPv6 Extension Headers" regarding header insertion is:
> 
>    Extension headers (except for the Hop-by-Hop Options header) are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node (or each of the set of nodes,
>    in the case of multicast) identified in the Destination Address field
>    of the IPv6 header.
> 
>    The Hop-by-Hop Options header is not inserted or deleted, but may be
>    examined or processed by any node along a packet's delivery path,
>    until the packet reaches the node (or each of the set of nodes, in
>    the case of multicast) identified in the Destination Address field of
>    the IPv6 header.  The Hop-by-Hop Options header, when present, must
>    immediately follow the IPv6 header.  Its presence is indicated by the
>    value zero in the Next Header field of the IPv6 header.
> 
> Some earlier drafts include IPIP as a way of inserting headers, but that wasn’t included in what became RFC8200.

Does IPIP simply mean tunelling IP over IP?

If so, that'd be tunneling, rather than "header insertion".

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492