Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Mikael Abrahamsson <swmike@swm.pp.se> Wed, 01 November 2017 10:46 UTC
Return-Path: <swmike@swm.pp.se>
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 0B21913F6DD for <ipv6@ietfa.amsl.com>; Wed, 1 Nov 2017 03:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 Hx48FKP8J1vA for <ipv6@ietfa.amsl.com>; Wed, 1 Nov 2017 03:46:28 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDA513B10E for <ipv6@ietf.org>; Wed, 1 Nov 2017 03:46:27 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id ABFADB5; Wed, 1 Nov 2017 11:46:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1509533185; bh=TK/co7yQ3n1L/CKKiXAkVQqIAlCkjV7IGcV3uS/JgX4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=g9Zi/794BIQHrROpxBDx3ZSCJhXYnaM35tvyjmYiDum/0rdtvE3oBFw/ZP0S8xvpG ZjHGKY2nQlEJvnkkVeZjxOcsQxV9/8/7zPy4P9ycSwAza7cu7xbzsDnpWpljbNjzK/ pfh3VnFt9h1PSZYtPldUKac267eJ3ve9uVkG1dpo=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A7169B3; Wed, 1 Nov 2017 11:46:25 +0100 (CET)
Date: Wed, 01 Nov 2017 11:46:25 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Michael Richardson <mcr+ietf@sandelman.ca>
cc: 6man WG <ipv6@ietf.org>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: <6286.1509408085@obiwan.sandelman.ca>
Message-ID: <alpine.DEB.2.20.1711011139390.16389@uplift.swm.pp.se>
References: <CAOSSMjUVCSBjbYu3bc7DU+edz2+0+RvU_AMi4FNn2n2075kk9g@mail.gmail.com> <6286.1509408085@obiwan.sandelman.ca>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qL4DElWZpTiziB5SUpWfjNMCZhY>
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: Wed, 01 Nov 2017 10:46:30 -0000
On Mon, 30 Oct 2017, Michael Richardson wrote: > And I think that most host stacks discard such things unless configured to > expect a tunnel from D. Agreed. > 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 discard) Ok. If it's configured to expect this kind of IPIP tunnel, agreed. Automatically, I don't think it should do this. It should not be default behaviour. Otoh I agree that ripping of a header isn't "forwarding" and shouldn't count as such. A 6to4 enabled host with forwarding disabled, receiving a 6to4 packet addressed to itself, should indeed take off the header and then process the inner packet. If the OS comes by default with 6to4 enabled, then I expect it to be able to handle 6to4 packets coming to it. I wouldn't expect it to behave this way if 6to4 is turned off, then it should just drop the packet. > 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. If the device isn't configured to do IPsec (even by default), then I don't think it should do what you describe. It just seems weird to have end nodes strip off headers to try to gain access to whatever might be in there, at all costs, because it might be relevant to it (or not). If it receives an MPLS labeled packet and the device understands MPLS, should it start ripping off labels even if MPLS has been turned off on the device? I believe users and admins would be very astonished if end systems started doing these things. -- Mikael Abrahamsson email: swmike@swm.pp.se
- Updates to RFC6434 Timothy Winters
- RE: Updates to RFC6434 Turner, Randy
- Re: Updates to RFC6434 Timothy Winters
- RE: Updates to RFC6434 Templin, Fred L
- Re: Updates to RFC6434 Timothy Winters
- RE: Updates to RFC6434 Templin, Fred L
- Re: Updates to RFC6434 Tim Chown
- RE: Updates to RFC6434 Templin, Fred L
- Re: Updates to RFC6434 Tim Chown
- RE: Updates to RFC6434 Templin, Fred L
- Updating to RFC6434 to deal with 8200-style heade… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Mark Smith
- Re: Updating to RFC6434 to deal with 8200-style h… Ole Troan
- Re: Updating to RFC6434 to deal with 8200-style h… Erik Kline
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Mark Smith
- Re: Updating to RFC6434 to deal with 8200-style h… Mikael Abrahamsson
- Re: Updating to RFC6434 to deal with 8200-style h… Ole Troan
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Mikael Abrahamsson
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard
- Re: Updating to RFC6434 to deal with 8200-style h… Mikael Abrahamsson
- Re: Updating to RFC6434 to deal with 8200-style h… Fred Baker
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… Ole Troan
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Tom Herbert
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- RE: Updating to RFC6434 to deal with 8200-style h… Manfredi, Albert E
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Tom Herbert
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Bob Hinden
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard