Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 15 February 2017 21:52 UTC

Return-Path: <brian.e.carpenter@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 10EB0129867; Wed, 15 Feb 2017 13:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 wmjJJXQs0jdH; Wed, 15 Feb 2017 13:52:24 -0800 (PST)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 4E3A3129876; Wed, 15 Feb 2017 13:52:16 -0800 (PST)
Received: by mail-pf0-x244.google.com with SMTP id o64so8578844pfb.1; Wed, 15 Feb 2017 13:52:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=AhFYVlQ4vP4FaIspOr1u2rjZdyjqUTYiD0elAtMGkpU=; b=j8eh2r/1vbM3Ya5xq+ZogJcghMWy1Y5HdG92eK7ghrZmpRTM5bLhNJsraD73wRXSN9 9k560bmjA+SPL0MgQhbsM1lL6np2JSXXCqcjR4cH9caxxuKGPGZqO9yC7UzKSd9l6H+I EQWsnS28NiQWFyDAvjUdSFhoHpj607n70TjVnsiokYNgfRUb81tuTM/Yk5BU55Kay/dl fFKjou9vaZbslS9yTOStfrpso53D7YyNkr0CaUtCzqJlep/ndDhPc1LKPXkfI+fWhl9K u/RhDR7iEpQcs7Sc1NdMb8MQQxe7yRi5IiKNF7evFcDNpJyKLCAlYRlo8kQOQzVX/6wz xFKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=AhFYVlQ4vP4FaIspOr1u2rjZdyjqUTYiD0elAtMGkpU=; b=YCqINKQq2Ubw2h/B40Rx3FOER62AJeXKj2PLACUREqKyxqqfck9wCmRn89vL4Ol/xr QU41F4eMvp8LNI9dpD/n1JPQ2JToX2ZCcpKqiIdD7IpLUkuS6hXfrc1UlPk/fAxUNg5w ViSvnP1a8toWmCLDFM3k/JT/jqi/ZugeyTTOgMRiCAbxp42G/d1hq7vQGhxoSx5O0J66 qwTDVrP0sqJBcjqbdKgOcTBjc6HldT9/Mo7Jap8orydvdzgEEpc1dOriSOmJKHvYKBE4 4IJ4Vc2PIcbG5Zd3FZ1GXZXpWtdhfhCTR24OpY7018/vcCkVEcEDmJc6TpTiwjFFIPSj NdIQ==
X-Gm-Message-State: AMke39kM9NWymd6t59eP411/TD5NIf7t2ghi5JM/Td7VGTmFNrg8cX+kCtXfwP+Phc6aUg==
X-Received: by 10.99.8.194 with SMTP id 185mr41956145pgi.76.1487195535826; Wed, 15 Feb 2017 13:52:15 -0800 (PST)
Received: from [192.168.178.21] ([118.148.112.221]) by smtp.gmail.com with ESMTPSA id h68sm9195588pfj.124.2017.02.15.13.52.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 13:52:15 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: otroan@employees.org
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <9bd5456f-d9e2-bedf-abe2-7ab14bdc44e7@gmail.com>
Date: Thu, 16 Feb 2017 10:52:16 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SQ5Zy-S08dDHjomqJjP2EYfOnwk>
Cc: 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@ietf.org
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: Wed, 15 Feb 2017 21:52:26 -0000

On 16/02/2017 10:34, otroan@employees.org wrote:
> Brian,
> 
>>>>>> Brian, changing the 64 bit boundary is such a big change that I would
>>>>>> claim it is far outside the scope of advancing 4291 to Internet standard.
>>>>>>
>>>>>
>>>>> Agreed.
>>>>
>>>> Of course. The point is only that it's a parameter in the design of SLAAC,
>>>> whose value is set by the address architecture.
>>>
>>> If your statement is that we only have the 64 bit boundary because of SLAAC I believe you are wrong.
>>> Can you provide any support for that view?
>>
>> No, that's not what I'm saying. I'm saying that SLAAC - by design - would work
>> with any reasonable IID length, but we've chosen to fix it at 64.
>>
>>> If I understand you correctly, your proposal is to change the fixed 64 bit Interface-ID length in IPv6 to a variable one, with an exception for links where SLAAC is used.
>>
>> No. At least not in the foreseeable future. But we should allow for the fact that if
>> prefixes between /64 and /127 are used, routing needs to just work. That's all.
>>
>>> How do you practically suggest to do this, given the issues raised in https://tools.ietf.org/html/rfc7421#section-4.1 ?
>>
>> I'm not suggesting any change to normal subnets, where all those issues apply.
>> I can't see how /64 can be changed for them, without changing a great many
>> things.
>>
>>> Do you think this change is appropriate in the context of advancing 4291?
>>
>> I don't think I have suggested text that would lead to a single instruction in
>> running code being changed.
> 
> CURRENT (RFC4291bis):
> 
>    IPv6 unicast routing is based on prefixes of any valid length up to
>    128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
>    on inter-router point-to-point links.  However, the Interface ID of
>    all unicast addresses, except those that start with the binary value
>    000, is required to be 64 bits long.  The rationale for the 64 bit
>    boundary in IPv6 addresses can be found in [RFC7421]
> 
> PROPOSED:
> 
>     IPv6 unicast routing is based on prefixes of any valid length up to
>    128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
>    on inter-router point-to-point links.  However, the Interface ID of unicast
>    addresses used for Stateless Address Autoconfiguration [RFC4862] is required
>    to be 64 bits long. The rationale for the 64 bit
>    boundary in IPv6 addresses can be found in [RFC7421]
> 
> 
> My reading of the proposed text, which certainly may be wrong, given that English is not my first language, is that it leaves the Interface-ID length of links _not_ using SLAAC undefined, i.e. not fixed at 64. Is there any other way to interpret this sentence?
> 
> The proposed text appears to make the Interface-ID length an operational choice.

Ah, yes, there is a slight loophole there (but I think that somewhere else we
require all nodes to implement SLAAC, so maybe there isn't a real loophole.)
I would certainly agree to wording that closes that loophole. But the anomalies
people noted around the '000' subset need to fixed.

    Brian

> How is that _not_ changing the 64 bit boundary?
> 
> Best regards,
> Ole
>