Re: [6lo] Link Local address and 6BBR

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 10 January 2019 06:51 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7973C130FDB; Wed, 9 Jan 2019 22:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.642
X-Spam-Level:
X-Spam-Status: No, score=-14.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 b1TZk0X_c2rl; Wed, 9 Jan 2019 22:51:44 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159EB131155; Wed, 9 Jan 2019 22:51:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3868; q=dns/txt; s=iport; t=1547103100; x=1548312700; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ck0f7V1og/TfABurirOxDSyeJGjjGg4MIqSUGV8nqAk=; b=Isv6SXcW/ZH+LoP3OQTxghafSB7CS/u/mdvqoJSULjjdqLCGM+C9/S55 /I1RZxGT4DTj+kBvoOr+l7zKcSLc3XgPFgvnp/504Q0OBYGpgo8WJzd8O fdEczKEWWCcLT9fLRWJ9g18r7fxTVcYebiIUS7NW8TUVMZZ/jXMbhIqzI w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAADs6jZc/4sNJK1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggOBaCeEAIgai2yCDZd3gXsLAQGBd4J1AheCCSI0CQ0BAwEBAgEBAm0ohUoBAQEBAgEjEUUFCwIBCBgCAiYCAgIwFRABAQQOBYMigXoIrDaBL4pCgQuLNBeBQD+BEScfgkyFAYMJMYImAolEmDAJApF7GJF5mjICERSBJx84gVZwFWUBgkGCJxeOHkExilABAQ
X-IronPort-AV: E=Sophos;i="5.56,460,1539648000"; d="scan'208";a="503912164"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2019 06:51:38 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x0A6pcQJ020072 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Jan 2019 06:51:38 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 10 Jan 2019 00:51:37 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Thu, 10 Jan 2019 00:51:38 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-backbone-router@ietf.org" <draft-ietf-6lo-backbone-router@ietf.org>
Thread-Topic: [6lo] Link Local address and 6BBR
Thread-Index: AdSoQDCmyjIgCNWqRKiGHkbinABWAAAQ2JIAAAqy3OYAAKQryQ==
Date: Thu, 10 Jan 2019 06:51:37 +0000
Message-ID: <DD023213-6199-4362-9266-A74EC5B178F7@cisco.com>
References: <f84956d783ed4a11b9c72057d38d622e@XCH-RCD-001.cisco.com>, <29429.1547062016@localhost>, <E83F387E-4746-4117-BCC0-E8458DB17CD1@cisco.com>
In-Reply-To: <E83F387E-4746-4117-BCC0-E8458DB17CD1@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/xEL15gPjA2f55LUXbuCjeKbX27s>
Subject: Re: [6lo] Link Local address and 6BBR
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2019 06:51:47 -0000

Hello Charlie 

When a node registers to multiple 6BBR the registered address is really like an anycast address on the backbone. Anycast handling is a bit under-specified in ND in general. And this is not the place to solve that problem, thus our current discussion.

Note that first registration as you proposed is a bit hard to achieve. A node may move and register to more than one 6BBR at roughly the same instant. The TID will be the same. A race condition where the NS(DAD) cross on the backbone is likely and creates an anycast situation anyway. 

When present the 6LBR on the backbone may sort it out but the protocol elements for that resolution are missing.

My suggestion is to mention that one can register to more than one 6BBR and that the address is to be treated as an anycast address on the backbone, the exact details out of scope - removing the concept of primary which would be a welcome simplification for the IESG review.

The caveat is that the NA(EARO) will have to carry the real information as opposed to being obfuscated, to the different 6LBRs can recognize parallel registrations and ignore the conflict.

Does that work for you ?

Pascal

> Le 10 janv. 2019 à 07:33, Pascal Thubert (pthubert) <pthubert@cisco.com> a écrit :
> 
> Hello Michael 
> 
> I agree with the simplest, and I’m happy with the resolution to say that link local can be proxied in bridging mode but the scope for uniqueness is the collection of links covered by the 6LBR. 
> 
> I also agree that it is not necessarily the most common configuration but it appears to be needed for some .11 configurations.
> 
> All the best!
> 
> Pascal
> 
>> Le 9 janv. 2019 à 20:27, Michael Richardson <mcr+ietf@sandelman.ca> a écrit :
>> 
>> 
>> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>>> But doing so, we bar Link Local traffic that could have happened
>>> between nodes attached to different 6BBRs, e.g., in a Wi-Fi environment
>>> where the 6BBRs can be collocated with APs and maybe operating as
>>> Bridging Proxies. The proposal on the table is thus to proxy ND for
>>> Link Local addresses in the case of a bridging proxy. The registration
>>> and proxy operation would be the same as for a Global Address, but
>>> there’s at least one caveat.
>> 
>> LL traffic is likely mDNS traffic and/or DNS-SD traffic.
>> I don't think it's useful to pretend it's a single subnet for the purposes
>> of making that work.
>> 
>>> * Make the scope of uniqueness for a Link Local Address the collection
>>> of links covered by a 6LBR (easy, no change in the spec)
>> 
>> seems simplest.
>> 
>>> What do people think?
>> 
>> I think it's too much thinking.
>> 
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-