Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6

Fernando Gont <fgont@si6networks.com> Tue, 18 April 2017 14:39 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EE5131883; Tue, 18 Apr 2017 07:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 xS2ToyMvilZO; Tue, 18 Apr 2017 07:39:21 -0700 (PDT)
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 ABA881317D0; Tue, 18 Apr 2017 07:39:21 -0700 (PDT)
Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 3EF9C80890; Tue, 18 Apr 2017 16:39:19 +0200 (CEST)
To: otroan@employees.org
References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <BBE95D76-13FF-4FAA-A3FA-AA1E4923EB91@employees.org> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> <D0E3AF6B-D2C1-45E9-95C5-AB216DDD4D66@employees.org>
Cc: Gunter Van De Velde <guntervandeveldecc@icloud.com>, opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" <v6ops@ietf.org>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <c260f415-ca53-69f1-e363-7e27d2580c67@si6networks.com>
Date: Tue, 18 Apr 2017 15:15:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <D0E3AF6B-D2C1-45E9-95C5-AB216DDD4D66@employees.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/08Xe2tDCsV4ltnoZedfYFvHCjKA>
Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2017 14:39:23 -0000

On 04/18/2017 02:31 PM, otroan@employees.org wrote:
>>>
>>> Yes, you are missing something. RFC4443 specifies what behaviour
>>> should be if a router receives a packet on a point to point link that
>>> would end up being forwarded back out the same link. The specified
>>> behaviour is drop and send destination unreachable. That solves the
>>> problem for any packet obviously. And any prefix length assigned to
>>> the link.
>>
>> How could RFC4443 possibly address this for all packets without formally
>> updating RFC2460?
>>
>> P.S.: For a specification pov, this shouldn't be buried in RFC4443, and,
>> as noted, no matter where this "patch" is specified, such doc should
>> certainly update RFC2460.
> 
> You will probably save everyone a lot of energy if you just admit you had missed it, and moved on.

Huh?

I obviously missed it. But this should still be in RFC2460 (or
rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding
for IPv6 packets.

Having important requirements spread into a number of documents where
they don't belong doesn't help, and in the long run takes more energy
(and creates more problems) than spending the energy in doing what is right.

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