Re: Review of draft-ietf-6man-rfc4291bis-06

Erik Kline <ek@google.com> Mon, 16 January 2017 09:58 UTC

Return-Path: <ek@google.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 A8A8D129455 for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 01:58:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level:
X-Spam-Status: No, score=-5.9 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_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fEs-oUKjfDZN for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 01:58:08 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 90342126FDC for <ipv6@ietf.org>; Mon, 16 Jan 2017 01:58:07 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id c85so151468870wmi.1 for <ipv6@ietf.org>; Mon, 16 Jan 2017 01:58:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8MqFnWUK1IkdesgUsx0Po1uXwUjfehBCgePIkYkFxDA=; b=YVN3tP1V1lDCdwYdJwpcJZ5rwr5FMGa07DR6PuUpQVNTQ+FJUsMrCOt6/m7lM94XNp vO/Y9jnhUEmHgIjVGANoCIERj4mLgDR/KDNwhBXVx3ZYs76e/uQWbh3k3rLBeGQFmCxj 8i7BWqAMn2WF8YZihlwhIZZBwK9qZR+XuysN30zX4FBCn/w9W92hGJP8GNNpK1pkaSpR ts7H0oDXo1Azho88Sv9SQIPBHNWXOWsp06f7kwPM8MOrlcYfaxK9nPOvBX5MSYgvkRcL 4XxuVs/vGamf4iIbuKE3ZQBXFVLhpLTZgFKBCTpWl8kty85GQRykBmK0tBP3qJBIwVdk gNbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8MqFnWUK1IkdesgUsx0Po1uXwUjfehBCgePIkYkFxDA=; b=WpBu8rkDnYsIMT/Tn+CHbRE0YLZJAB/Qa9Mhd5UepGf0ycKrSQyIaw/KQUeDqpfXhk eaVvSoLI3dsr1dn06nlTNvyBLRh/Kg/+SbApVAJY9A9oO9mvJ3vME98tytlG2Ol6heeG 7I4zQz1vAMGpLkIUdY6lUGMJsP3cJKZe189EYRTbkT79vmt8F7rC3TtlJqhB4FWfRAvy f+wBuPxee4MqYBVlB7B0pDqlBqViDRnwtxyNzUqbHaClYI1H1EowOkxq0CqL9eTbibBy x2AHvV+wLxaSifZHvZGsMmk5POI+TUe3pA9nbgWsyz22NGki1kxza5hCf9aCCYI/+2Qk CYmw==
X-Gm-Message-State: AIkVDXJazrxoEeVjdc+0JurfGWB2LWNTYwfU3iu22svKBtkKPt3OoNC0EgbgOVUxzVvRe3iGsSjVjgnRl9u63DbL
X-Received: by 10.223.128.202 with SMTP id 68mr22646843wrl.148.1484559903974; Mon, 16 Jan 2017 01:45:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.21.69 with HTTP; Mon, 16 Jan 2017 01:44:42 -0800 (PST)
In-Reply-To: <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <m2fukqbbwv.wl-randy@psg.com> <F6953234-3F85-4E28-9861-433ADD01A490@gmail.com> <m2wpdzhncn.wl-randy@psg.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <m2d1frhjfn.wl-randy@psg.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <CAKD1Yr1cvZ8Y3+bHeML=Xwqr+YgDspZGnZi=jqQj4qe2kMc4zw@mail.gmail.com> <m2lguffnco.wl-randy@psg.com> <CAKD1Yr1TrTiPRdyutobmb_77XJ7guNzLrg=H_p7qi4BfQ8V=GA@mail.gmail.com> <m2d1frfm6m.wl-randy@psg.com> <CAKD1Yr2Njjd8_Mr+6TRFF6C5pdcX4yFgpFVyEkykDuytu2B8mg@mail.gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <CAN-Dau06R3iYRpYLADhvHox4C9qdsJCuxFsJapRhOQcWT4qk_g@mail.gmail.com> <CAO42Z2weZcoHiBzN94QAQ9WGhWR16PmMMFNg=5YLmr_dhPjjpA@mail.gmail.com> <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com>
From: Erik Kline <ek@google.com>
Date: Mon, 16 Jan 2017 18:44:42 +0900
Message-ID: <CAAedzxqkAqyhru7B+pFEzMj2tGc1GnE8q=rT94LzJn=JgEUdNg@mail.gmail.com>
Subject: Re: Review of draft-ietf-6man-rfc4291bis-06
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c08225857e15305463338ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1HMRpRYRrsZC9YKdDTHS5aqSnqM>
Cc: 6man WG <ipv6@ietf.org>, IETF <ietf@ietf.org>, int-dir@ietf.org, Bob Hinden <bob.hinden@gmail.com>, Randy Bush <randy@psg.com>, draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin <john-ietf@jck.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 16 Jan 2017 09:58:09 -0000

It would definitely be very good to see specific text.

Since this is (IIRC) being done for Standards Track purposes, the
primary goal crudely phrased is to collapse the diffs between the base
document and all those that modify it.  Or so I have thought.

Text that illuminates surely seems fine, but text that alters stuff at
this stage doesn't seem like too good an idea to me.

On 15 January 2017 at 04:20, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> Mark,
>
> I think this thread has shown convincingly that there is a problem with
> the current wording of 4291bis about the 64 bit IID length.
>
> I suggest that we wordsmith it on the 6man list and come back to this
> broader CC list when we have a proposal.
>
> Regards
>    Brian
>
> On 14/01/2017 19:37, Mark Smith wrote:
>> On 14 Jan. 2017 15:36, "David Farmer" <farmer@umn.edu> wrote:
>>
>>
>>
>> On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter <
>> brian.e.carpenter@gmail.com> wrote:
>>
>>> ....
>>>
>>>
>>> Which is exactly why we have so far only delegated 1/8 of the
>>> IPv6 address space for global unicast allocation, leaving a *lot*
>>> of space for fixing our mistakes. Moving away from /64 as the
>>> recommended subnet size might, or might not, prove to be necessary in
>>> the long term future. That's why the point about routing being
>>> classless is fundamental. I do think we need to be a bit more
>>> precise on this point in 4291bis.
>>>
>>>     Brian
>>>
>>
>> Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and
>> I'm fine with that, but that's not what the following says.
>>
>>    For all unicast addresses, except those that start with the binary
>>    value 000, Interface IDs are required to be 64 bits long.  Background
>>    on the 64 bit boundary in IPv6 addresses can be found in [RFC7421
>> <https://tools.ietf.org/html/rfc7421>].
>>
>>
>> It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an
>> Imperative as discussed in section 6 of RFC2119.
>>
>> I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support
>> that and believe it to be the consensus of the IETF. Maybe even explicitly
>> noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support
>> by SLACC.  But it is not correct to say the /64 is REQUIRED.
>>
>>
>> I don't think /127s should really be recommended either.
>>
>> They don't guarantee that the ping pong problem is solved, because it
>> depends on both ends being configured with the /127 prefix length by the
>> operator or operators at each end if the link. There is no protocol
>> requirement that both ends of a link have the same prefix and prefix
>> length, nor is there any protocol checking of that condition.
>>
>> For example, if an ISP configures a /127 on their end of the customer's
>> link, but the customer just configures a default route on their end over
>> the link, it is a legitimate configuration by the protocols, Internet
>> access will work (so the customer might assume the link is configured
>> correctly), and yet the link is vulnerable to a ping pong attach despite it
>> "having" a /127 prefix.
>>
>> So it is a mitigation, however it relies on the operator or operators being
>> disciplined about the configuration, and comes at the cost of other things
>> that may be useful if a 64 bit IID was available e.g. protect against
>> discovery of link addresses via unsolicited inbound probing if the IIDs are
>> random (which may include static configuration of an offline generated
>> random 64 bit IID).
>>
>> Regards,
>> Mark.
>>
>>
>> I also believe RFC7608 supports this conclusion.
>>
>> Thanks.
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------