Re: about violation of standards

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 23 April 2019 23:22 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 92F4D12068C for <ipv6@ietfa.amsl.com>; Tue, 23 Apr 2019 16:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 BLL92S_8tX0v for <ipv6@ietfa.amsl.com>; Tue, 23 Apr 2019 16:22:03 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 E832E120685 for <ipv6@ietf.org>; Tue, 23 Apr 2019 16:21:57 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id d9so2331511pls.8 for <ipv6@ietf.org>; Tue, 23 Apr 2019 16:21:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UepyTmzss8u2ycJzkZtXi4FhyFtqQbbb5Y9WFtRAyuw=; b=SE2An7xptD5MNm1Vyxj0khsv3HleqRKIHMlerQa6qgUHrAAMQjWzt8Ug/Id987tkhD nceG0PCFSfOIxTJA2cu8YzV2dWaRkFBIL9QA4yNiNrvRmYc9w1vboc/4wIXBqLPikSO7 zzQY+TdEUEWHXdtH8k0fn5JM/3M2XHd5El9TMZ1od6JwcZoHdFW0qR2OCuaVT1JxUgpY SzZSuhtSYbp7kl/ArCACLZI4Bgw/Dg1zZM5xbBt77Z8PW+xaaGUQEIb7eE0jNKhCyin0 otV9jlgOfaDSOVEOHaETMbg7BkXgiOWKPVfQXYNjsRIFU8Imwv70XrPzKP4lM5KWz6sI ozcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UepyTmzss8u2ycJzkZtXi4FhyFtqQbbb5Y9WFtRAyuw=; b=JuhTC1xcrcu81xP4whdKP1ozGQ2n6NFxcoCWFBxgS1r+UePzEBJJBtbf8R8FcEo4RG /6g0eFcTSAlXrQmdKqhRryHTtfPOnQhWI8/eaI6qAN7MR988VYa0Sw33NB9ZuQSow2LV G3TyFKIfWx/f6uUZD/s17xhyG4G0/FwjDsaK+0qRpUdByix2BRSw24OWA/Xhwzcn+/P9 CHZzh3cFhYwfcJYKdlUgi9CTgWPF5y5Al6MNfgGGCdjLE1pjLFcSuiCRtMWnUb3SbR7l ILYy89uXHXiMKR+cleLIx6/uYboOvjo1OoT8eWXLALeyzAcDCmWECSGkl3sHN0uPkHFL BbTw==
X-Gm-Message-State: APjAAAWFgGklLfwQu93V0Sftd4QVq8yUREXP2ob8jNwrm50lUK/ZWu3g 6D4f/GNEvY6aVGKpYcGHjCU=
X-Google-Smtp-Source: APXvYqx7vLTbLF0H+F2QBB6oFisNCdE0cMHCEEAnVxDKC2dUDxPaWeg+my1tvTFqp4U1+LiesrNEdw==
X-Received: by 2002:a17:902:362:: with SMTP id 89mr27839006pld.172.1556061717363; Tue, 23 Apr 2019 16:21:57 -0700 (PDT)
Received: from [130.216.36.68] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.68]) by smtp.gmail.com with ESMTPSA id y20sm23643084pfe.188.2019.04.23.16.21.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 16:21:56 -0700 (PDT)
Subject: Re: about violation of standards
To: Ole Troan <otroan@employees.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Fernando Gont <fgont@si6networks.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, 6man WG <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
References: <bb7f7606-2adf-e669-8bcd-e41f17800782@gmail.com> <CAJE_bqd9frqX5-yeVPj8MYXpZ4737HqK1gmfD9cQV3A-Ea5HrQ@mail.gmail.com> <6bd5db47-408a-727e-5c13-f34a3465f986@si6networks.com> <CAJE_bqfTLqRbLp4fLu2ASZuZ+4G5c2G+RXkO92kXfLgPTqBnng@mail.gmail.com> <EEF00EA7-2AAF-403F-99AD-1D53ED18E8B3@cisco.com> <47631828-121F-402D-8165-969684C1101B@employees.org> <MN2PR11MB35655B36540829AEE5275964D8230@MN2PR11MB3565.namprd11.prod.outlook.com> <1066F69A-824F-4D6D-B221-8EFBAD15E15A@employees.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <018c407a-b127-8724-d1ee-e19e3b084a60@gmail.com>
Date: Wed, 24 Apr 2019 11:21:51 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <1066F69A-824F-4D6D-B221-8EFBAD15E15A@employees.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/m3if579UV0lhdw92XHlkj28qyXQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Apr 2019 23:22:10 -0000

On 23-Apr-19 22:36, Ole Troan wrote:
> Pascal,
> 
> Sounds like what you want is to replace link-local addresses with ULAs.

No, because ULAs have a different constraint: they are valid within a specific domain, which we assume to be relatively stable, so that its border routers can filter the ULA prefix. What Pascal describes is a much more fluid situation, where link-local domains are forming and dissolving all the time and unpredictably. (Exactly the OCB situation in heavy traffic, in fact.)

> I’m quite convinced that the complexity tradeoff of that scheme is much worse than having to deal with scoped addressed. ;-)

It is. Mesh networks are not easy, especially with other SDOs trying to solve mesh network problems at layer 2. This discussion is at layer 2.5. But I think Pascal is correct to say "nodes may need to form new LLAs to talk to one another and the scope where LLA uniqueness can be dynamically checked is really that pair of nodes." How can GUA routing be stable in such a network?

    Brian

   Brian

> Cheers,
> Ole
> 
>> On 23 Apr 2019, at 12:19, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>>
>>
>>>> Some functions in the router are complex to implement because same value
>>> for a link local address appears on multiple interfaces.
>>>
>>> Like what?
>>
>> Like structuring the tables where you maintain the address binding.
>>
>> Because a link local is only unique within the link / broadcast domain where DAD occurs, you have to add the sense of that link / broadcast domain as an additional key to your binding table, whereas for the GUA the prefix gives you that from within the address, and the address is sufficient as a key.
>>
>> Turns out nothing is too particularly neat for the role. On Ethernet, a VLAN does not guarantee a unique global value though at least it is a local sense of the broadcast domain and you can use it as a node-local key. But you cannot get a global sense of where the link local address is in your network by just looking at it. 
>>
>> If there was an encoding of that global sense of the broadcast domain in the link local address, one could log in or even send a message to any router in that domain and ask if the link local is live by making it ping or what. And one could generate that request using the link local address only, as opposed to encoding a address%interface that is locally significant to the particular router or host that I'd use to ping the link local address, always a hassle.
>>
>> This would extend the value of the link local without changing its scope, and enable common APIs, tables and GUIs, understanding that what we'd encode represents a physical domain that is not necessarily mapped to a logical subnet. 
>>
>>
>>>> It would be useful to be able to encode an abstract interface ID somewhere
>>> in the /64. Legacy 00 would mean unspecified...
>>>
>>> Sounds like you need subnet-id election?
>>
>> Not of a subnet, rather an ID for a link or a broadcast domain, a bit like what DNA was after. On an Ethernet domain it is easy to confuse those things because the shared wiring defines at the same time the physical link, the broadcast domain and the subnet that we map over it. But the difference shows on legacy NBMA like ATM or FR, on shared links and on newer types of NBMA such as radio and composite radio-wires networks. 
>>
>> In radios, the broadcast domain is defined differently by each transmitter as opposed to defined commonly by a shared wire. 
>> In mesh-under (e.g., a Wi-Fi mesh or IEEE 802.15.10) the link extends beyond the broadcast domain. In route-over (e.g., 6TiSCH with RPL), the subnet extends beyond the link.
>> Note that a Wi-Fi BSS is an exception whereby the broadcast domain of the AP emulates the common wire, but that takes a particular L2 emulation that is not present in other types of WPAN/WLAN/LPWAN radio links.
>>
>> On radios without a BSS, links between peers come and go as their individual broadcast domains meet physically. The ND DAD operation cannot provide once and for all guarantees on the broadcast domain defined by one radio transmitter if that transmitter keeps meeting new peers on the go. The nodes may need to form new LLAs to talk to one another and the scope where LLA uniqueness can be dynamically checked is really that pair of nodes. As long as there's no conflict a node may use the same LLA with multiple peers but it has to revalidate DAD very time. So it's like if each pair of nodes defines a temporary P2P link, like a sub-interface of the radio interface. In that case, we could encode something about that P2P link in the LLA, like something derived from MAC addresses, while keeping the same IID. 
>>
>> All the best,
>>
>> Pascal
>>
>>> -----Original Message-----
>>> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ole Troan
>>> Sent: mardi 23 avril 2019 09:33
>>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
>>> Cc: Fernando Gont <fgont@si6networks.com>; Alexandre Petrescu
>>> <alexandre.petrescu@gmail.com>; 6man WG <ipv6@ietf.org>; 神明達哉
>>> <jinmei@wide.ad.jp>
>>> Subject: Re: about violation of standards
>>>
>>>> Some functions in the router are complex to implement because same value
>>> for a link local address appears on multiple interfaces.
>>>
>>> Like what?
>>>
>>>> It would be useful to be able to encode an abstract interface ID somewhere
>>> in the /64. Legacy 00 would mean unspecified...
>>>
>>> Sounds like you need subnet-id election?
>>>
>>> Ole
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>