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

Bob Hinden <bob.hinden@gmail.com> Sun, 12 November 2017 02:50 UTC

Return-Path: <bob.hinden@gmail.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 97500127337 for <ipv6@ietfa.amsl.com>; Sat, 11 Nov 2017 18:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QzEMer_QrkmI for <ipv6@ietfa.amsl.com>; Sat, 11 Nov 2017 18:50:11 -0800 (PST)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9680124BFA for <ipv6@ietf.org>; Sat, 11 Nov 2017 18:50:10 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id j28so7102779pfk.8 for <ipv6@ietf.org>; Sat, 11 Nov 2017 18:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Lw9dzp+AfyDDNFESpve0fO6dxpyRoB7uAZI9gV0DLps=; b=pRXAsI5yFmcw2dgb1sCCswFChjvSjGjquHuVIa1uXKfkH2filnfbNv3Twt5n0IJd8q n6Miqn+wCp3VhaRwIi2urvVIm9X/HYiJ6VAOZt9ac++qi9ZymCTVGkmRA6x6jqpoDaia j8ydOIPQn/cpJmOeKOsQaBsTcQWqOjlqHXb9ED4URBUjCMIILW1bwOtVu3uhkzRPNoEf e8etNgmNer7ucZECiNBByX+bNM4UJoVzWpZAv2P49Au/AX+MU9f51ezJBhT2nA9vUE7d Ow2CHJIGLDuhdAjf3QK2ow3ev5Cr1KIaglunAWyqfUSQDdz3qxhoV5V/F5tV2XMvXTd0 0fYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Lw9dzp+AfyDDNFESpve0fO6dxpyRoB7uAZI9gV0DLps=; b=J8OaVnd5iSjQkWEbKPyfPIu+IdYe9bL+kiyp7rY197JmTL2YdobsUNEKU3Bf+PTUlH zStWyOu2gVHtfAPUZmrk92eMRqmfgmUWgKAKamEf+JSr4gZxXT4QXrvEimvqSwjK0+XM EqBvioWgWGXufe9JQ+Ry7l1/TtckqM3SWIJOcFh+m7SPTY6IwXLcYFE/vOTywnds7PDK g6wp1xJgdDERZWfJeT2DMGLIETC9/7KKfSIKDjXbL61bYXejvHS1wsZzSb58aqL+sLl2 bnlbHBYyT9xEeRlXzqkDW9YnFVQ1mNj21fa/kcJ6v9wQ8sP7mvXJ5LDDPqeDQdbyX8Z7 SBSQ==
X-Gm-Message-State: AJaThX7U0fCLRzvciYBA4/6WrE4fz67y8yHvoC5oxUSdzwhdUsDeksrr mw3dDG6rPWp5awd4uX7mvbcB7kMU
X-Google-Smtp-Source: AGs4zMYs2vIHyadL2v2y77Ra054aMpmWgVTd8aR10v0Jq5pUrctA41KiHVal+lCLIU9zNUQbTvM9GA==
X-Received: by 10.159.204.139 with SMTP id t11mr5145020plo.121.1510455010174; Sat, 11 Nov 2017 18:50:10 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:ddbc:f5b0:f56b:1c6? ([2001:67c:370:128:ddbc:f5b0:f56b:1c6]) by smtp.gmail.com with ESMTPSA id s6sm21444988pgq.57.2017.11.11.18.50.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 18:50:09 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <C62FA0EB-A212-47D0-B527-CB53946E127F@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_DB607A69-74B7-40BA-99FA-CCA7779EA72B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Date: Sun, 12 Nov 2017 10:50:07 +0800
In-Reply-To: <c104cb05-ee8f-7958-338b-1e30aa7942d1@gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "C. M. Heard" <heard@pobox.com>, Fernando Gont <fernando@gont.com.ar>, Brian Carpenter <brian.e.carpenter@gmail.com>
To: IPv6 List <ipv6@ietf.org>
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>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/C6hn985opneEs7FHDXWJHPOgw48>
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 02:50:13 -0000

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.

Bob


> On Nov 9, 2017, at 3:15 AM, Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
> 
> On 09/11/2017 04:10, Michael Richardson wrote:
>> 
>> Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
>>>   Note that it is impossible for a node to distinguish between an
>>> unrecognized extension header and an unrecognized upper layer
>> 
>> Does "unrecognized" mean unknown to the writer of the code at the time of
>> writing, or does it mean a header which the node has no support for?
> 
> I think it means unrecognized at run time, regardless of whether it was
> known or unknown when the code was written, or configured on or off when
> the node was instantiated, or even configured off one microsecond before
> the packet arrived. So TBD would be return_icmp(1) in your case.
> 
> IMHO.
> 
>     Brian
> 
>> 
>> Or to put it in C, what goes into TBD?
>> 
>> retry:
>>  switch(proto) {
>>  case IPPROTO_UDP:
>>       udp_rcv();
>>       break;
>>  case IPPROTO_TCP:
>>       tcp_rcv();
>>       break;
>>  case IPPROTO_AH:
>>       if(ipsec_enabled) ipsec_rcv();
>>       else TBD;
>>  case IPPROTO_HOPOPT:
>>       process_hopopt();
>>       goto retry;
>>  case IPPROTO_MOBILITY_HEADER:
>>       skip_hopopt();
>>       goto retry;
>>  default:
>>       return_icmp(1);
>>  }
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------