[6lo] Link Local address and 6BBR

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 09 January 2019 17:48 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 94A3E130F5F; Wed, 9 Jan 2019 09:48:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 LtkuDSzl2HYs; Wed, 9 Jan 2019 09:48:07 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C83C130EEF; Wed, 9 Jan 2019 09:48:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10400; q=dns/txt; s=iport; t=1547056087; x=1548265687; h=from:to:subject:date:message-id:mime-version; bh=35DCmg+0ODGR7yMJ2XqA63GDUjaW2LNJ6Oixcr8xyko=; b=MQW5ukfWNPziyR5UskB4ZhePUenSL7kJy/TiCRcFqTOHeQXNHNbB0SWt Ovicz12uGIk/uws/2A4raTH5mQcvaYcjA+RHlONss9tF0lmp1ABql6U3X MZJVQDI//X8ciWcbnD3/GoQrlxBJxV8pWlFn4kPRSU+y/Ir8C1P9gXe4o A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAADdMjZc/49dJa1jGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBDXZmgQInCowQnRmCb4VjFIFnCwEBJYZoIjQJDQEDAQECAQECbRwMhX5eAYEAJgEEARqDG4EdZA+tFYovBYw/F4FAP4ERhjABAQIBgSaGGAKPV5IVCQKHF4UrhTEgkXeJbIUKizYCERSBJx84gVZwFYMoixyFP0ExAYk2gR8BAQ
X-IronPort-AV: E=Sophos;i="5.56,458,1539648000"; d="scan'208,217";a="223236871"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2019 17:48:05 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x09Hm5T2008121 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Jan 2019 17:48:05 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 9 Jan 2019 11:48:05 -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; Wed, 9 Jan 2019 11:48:05 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-backbone-router@ietf.org" <draft-ietf-6lo-backbone-router@ietf.org>
Thread-Topic: Link Local address and 6BBR
Thread-Index: AdSoQDCmyjIgCNWqRKiGHkbinABWAA==
Date: Wed, 09 Jan 2019 17:47:38 +0000
Deferred-Delivery: Wed, 9 Jan 2019 17:47:14 +0000
Message-ID: <f84956d783ed4a11b9c72057d38d622e@XCH-RCD-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.216.39]
Content-Type: multipart/alternative; boundary="_000_f84956d783ed4a11b9c72057d38d622eXCHRCD001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Rk7cg-Ge_UVVDFol4qKEb2WofDo>
Subject: [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: Wed, 09 Jan 2019 17:48:09 -0000

Dear all :

We are ready to publish draft 10 for the backbone router and ask for WGLC, but for one pending issue that was raised during the internal review between authors on the 6BBR draft.

The initial intention was not to cover Link Local addresses at all, since the multilink subnet is made of different links and the 6BBR is a L3 box that isolates them. This is true for a routing proxy, but not exactly right for a bridging proxy, which is really a layer-3 switch with MAC layer bridging continuity on the data path.

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.

Consider the flow in https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-09#section-3.1. The EDAR/EDAC exchange with the 6LBR would contain the Link Local address as opposed to a Global Address, but the EDAR/ EDAC does not give an indication of a link ID. If the 6LBR is on-link then that's not an issue but if we place it farther away, we could detect collision that would be a false positive for link local addresses used in different MLSNs served by a same 6LBR.

There are a number of possibilities to solve this:

  *   A new ND option in the DAR/DAC to indicate a Link ID (complex to specify, setup and deploy)
  *   Make the scope of uniqueness for a Link Local Address the collection of links covered by a 6LBR (easy, no change in the spec)
  *   Indicate the MLSN prefix (e.g., in the source address of the EDAR) and make that MLSN the scope of uniqueness for a Link Local Address (must force the 6BBR to source the DAR with an address in the subnet)

What do people think?

Pascal