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

Brian E Carpenter <> Thu, 02 November 2017 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E386813F8E4 for <>; Thu, 2 Nov 2017 12:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zjuwMxtBBd-Q for <>; Thu, 2 Nov 2017 12:36:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E499F13F8E5 for <>; Thu, 2 Nov 2017 12:36:24 -0700 (PDT)
Received: by with SMTP id a192so481117pge.9 for <>; Thu, 02 Nov 2017 12:36:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8mx2aG6kkotoMsQupUxQispAR4t5Mm3ffH1c2YgGDqM=; b=ZDUhRPGWqZ5maRpm6iMpiNFM+OH5BGjfUWfCUt0HkFMSF2E6Fkmpe7JMqSAaCl8vsR 8u8gE+WleYl+ktp4PNrgTgc6rh2cm2TC4V8qC5YDlSv66cdrMswzdTdg5ZC051095nP/ 5zZL2j9qyc0PZ1peVqMIIhR5ZjwgQTyzIxTAJEMlQtSYqXghdJRKXITjL+lwqeT/mAXV P9toPV/f5NBy27DFpd0H15F9z9VHumTGrU1OlZnXsopeLO9ZDgZtVQX2+9SjJjwtZulF LdrpLgepudSaVSkKMHxYFL87plbQ1OkQMGHPw/Yq5hGvnArnBQB8ID4SDaOTiWdHEA+Z yDlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8mx2aG6kkotoMsQupUxQispAR4t5Mm3ffH1c2YgGDqM=; b=mT+Cd1u2K+57dfqMlBAaS0kZbAn7E0/JqQmqNkZYOJ8fWiZM/s7SzCzfbHZx9du9La fovoypkRB95WSnaRlKuol8AO77Xl/LdsWO91bKhWThRro+5hnEmCFnBPOSiuIBvfGZ6b KvsmAeMJtjSjNtBqeSsrjzJcV0a3ZRkQpEGM4CN5K606E0JsRjTFY+ZvZyfjxHq6Ayf1 WirVrXxfa91lF+t3+HjYiDSrjwOWPOx1CN9nByIn6oNzD1e7Om+ONkPa/o2p/GSD6QEj b4rCou0JcmSvLtfi1GLdPqb08g09xr2n+Gf/M1StqlKhg62rVYsUspESWJFDE0fTpPad d/Yg==
X-Gm-Message-State: AMCzsaU6ak+x/zkAz4LoyxA58fugEKDTAoWznoHhQLgKie9ckJVz7E0G m+Aj1YEw0YIaru5dgZYJ768ysQ==
X-Google-Smtp-Source: ABhQp+QkIHhPGN77Eh8kSFcgf/4923PrAW4nDS+gPqpVPokSWVlIQGLrMTP5alNF04QV/haPuDZmZA==
X-Received: by with SMTP id w4mr4746027pgs.335.1509651384200; Thu, 02 Nov 2017 12:36:24 -0700 (PDT)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by with ESMTPSA id b28sm8541449pfl.86.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 12:36:23 -0700 (PDT)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Tim Chown <>, Michael Richardson <>
Cc: 6man WG <>
References: <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 3 Nov 2017 08:36:27 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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: Thu, 02 Nov 2017 19:36:27 -0000

On 03/11/2017 00:23, Tim Chown wrote:
> Hi Michael,
>> On 1 Nov 2017, at 20:17, Michael Richardson <> wrote:
>> Mark Smith <> wrote:
>>> I think we need to be clear about what is "inserting" is. To me, the word
>>> "inserting" means inserting to into something that already exists and has
>>> previously been created - cut apart, insert, glue back together.
>> You can mince words here if you like, I don't mind.
>> If someone wants to add a packet by encapsulating with a new IP header, then
>> they have to pick a destination address for that header, and if they keep the
>> same destination as the inner one, then the end host has to process two headers.
>> So, if one wants to make the advice of 8200 useable in practice, then one
>> has to fix 6463.
>> If one argues that this will hard and shouldn't be done, then 8200 must be
>> wrong in some way.
> So the 6man chairs were quite keen that we try to push 6434-bis to a conclusion in Singapore, which is a goal the authors are very happy to share.
> Obviously, reopening this issue may prove to be contentious.  The simplest and easiest answer is to punt it to a separate draft, and wrap up 6434-bis. I *think* the only other contentious issue that’s still open for the -bis is what we choose to say, or not say, about RAs vs DHCPv6.  In my view, wherever possible we should be just including pointers to existing text in other RFCs, and minimising any additional interpretation.

Yes. I think it would be a misuse of a "node requirements" document to specify
something that isn't already well specified elsewhere.

> Having said that, why don’t you try to write some succinct text in advance of the Singapore 6man slot, post it, and see what the reaction is?  Worst case, you’ll then have the basis for a separate draft.

We need this. Michael is correct that it's a gap in the standards.


> Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------