RE: encoding Subnet ID in link-local addrs (Re: about violation of standards)

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Fri, 26 April 2019 17:56 UTC

Return-Path: <dmudric@avaya.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 DAAB21201B2 for <ipv6@ietfa.amsl.com>; Fri, 26 Apr 2019 10:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.12
X-Spam-Level:
X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=avaya365.onmicrosoft.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 4iSuzTj2nKIg for <ipv6@ietfa.amsl.com>; Fri, 26 Apr 2019 10:56:39 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A9412001B for <ipv6@ietf.org>; Fri, 26 Apr 2019 10:56:38 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2HqAACHRcNc/wUHmMZmHQEBBQEHBQGBUwYBCwGBPVADgT0gBDMKhAWDRwOPCoJXiTuPERSBEAMYPA8BLQKEPgIXhhwjNgcOAQMBAQEEAQEBAQICAmkcDINFOTIBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAjg4AQEBAQMSEREMAQE3AQsEAgEIDQQEAQEDAiYCAgIfERUICAIEAQ0FCBMHhGoDHAECAqMQAoEGL4hfcYEvGgKCXQEBBYUJDQuCDgkJAYEBJwGLSReBQT6BEUaCTD6CGoFuPhWCczGCJopsgkmYfzgJAoIIh0aHHYNmgguGLoNWA4kKjAeIB4w7AgICAgQFAg4BAQWBVgQugVZwFYMngg8MF4NMilNygSmSNAGBIAEB
X-IPAS-Result: A2HqAACHRcNc/wUHmMZmHQEBBQEHBQGBUwYBCwGBPVADgT0gBDMKhAWDRwOPCoJXiTuPERSBEAMYPA8BLQKEPgIXhhwjNgcOAQMBAQEEAQEBAQICAmkcDINFOTIBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAjg4AQEBAQMSEREMAQE3AQsEAgEIDQQEAQEDAiYCAgIfERUICAIEAQ0FCBMHhGoDHAECAqMQAoEGL4hfcYEvGgKCXQEBBYUJDQuCDgkJAYEBJwGLSReBQT6BEUaCTD6CGoFuPhWCczGCJopsgkmYfzgJAoIIh0aHHYNmgguGLoNWA4kKjAeIB4w7AgICAgQFAg4BAQWBVgQugVZwFYMngg8MF4NMilNygSmSNAGBIAEB
X-IronPort-AV: E=Sophos;i="5.60,398,1549947600"; d="scan'208";a="279788660"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Apr 2019 13:56:35 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2019 13:56:33 -0400
Received: from PW365VMAP01.avaya.com (135.11.29.21) by az-us1exhc02.global.avaya.com (135.11.85.13) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 26 Apr 2019 13:56:29 -0400
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (104.47.33.51) by PW365VMAP01.avaya.com (135.11.29.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Fri, 26 Apr 2019 12:56:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-avaya-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9nzUPxG7bbyFly8yl04+fpC5NkVYDlYA8fQImBgDkrw=; b=oBmhtUVnapr4dMGQuNRj+77XFq/5+oAueZ2b/j8c5N5mkgrD5L4qJrO8ZnsrgB4xKwSCrH26mFpi80bXKX0RdVxuZKDMPlgYjgY/cBrOBN0GdDFg4DWbEkins8dTmm03p+X/L1+G0XwC/51ZwRYWKmOdQo1JTSGA2zqzmnGUFuA=
Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB3145.namprd15.prod.outlook.com (20.179.17.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Fri, 26 Apr 2019 17:56:28 +0000
Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::f9bf:a95a:e7db:2480]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::f9bf:a95a:e7db:2480%5]) with mapi id 15.20.1835.010; Fri, 26 Apr 2019 17:56:28 +0000
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>, Ole Troan <otroan@employees.org>, "," <jinmei@wide.ad.jp>
CC: "Pascal Thubert (pthubert" <pthubert@cisco.com>
Subject: RE: encoding Subnet ID in link-local addrs (Re: about violation of standards)
Thread-Topic: encoding Subnet ID in link-local addrs (Re: about violation of standards)
Thread-Index: AQHU/A7HNVm8W1+e1UilnG8VUtmmS6ZOtn5Q
Date: Fri, 26 Apr 2019 17:56:28 +0000
Message-ID: <DM6PR15MB25063731096796F863842B8ABB3E0@DM6PR15MB2506.namprd15.prod.outlook.com>
References: <DM6PR15MB25060A2397F2949C08B4A896BB3D0@DM6PR15MB2506.namprd15.prod.outlook.com> <b9e5830f-93a8-bd76-b89f-a4c9d677bce0@gmail.com>
In-Reply-To: <b9e5830f-93a8-bd76-b89f-a4c9d677bce0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com;
x-originating-ip: [104.129.196.170]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 25523389-fac6-4468-b2ee-08d6ca708206
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM6PR15MB3145;
x-ms-traffictypediagnostic: DM6PR15MB3145:
x-microsoft-antispam-prvs: <DM6PR15MB3145AA14C2F556E1C1638557BB3E0@DM6PR15MB3145.namprd15.prod.outlook.com>
x-forefront-prvs: 001968DD50
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(376002)(39860400002)(136003)(13464003)(189003)(199004)(6436002)(81166006)(9686003)(8676002)(71200400001)(66446008)(81156014)(8936002)(33656002)(7736002)(53936002)(305945005)(74316002)(71190400001)(55016002)(256004)(3846002)(6116002)(2906002)(186003)(14454004)(11346002)(25786009)(97736004)(476003)(486006)(68736007)(2501003)(4326008)(55236004)(53546011)(6506007)(478600001)(446003)(76176011)(102836004)(64756008)(26005)(229853002)(99286004)(66556008)(52536014)(110136005)(76116006)(6246003)(73956011)(86362001)(66476007)(66574012)(66066001)(7696005)(316002)(66946007)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB3145; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 3X+DAvbzDh82ePe+pex1phkscT4WHOLypjSu17wru3+ijpTIXOpHyuH1eUvFCORopLks1IcduzGTNSeOkj6+p+0IxQz2jC4RMboPnX+nDtHjlc3ASDv4/YIWZWP49tLcz+YCoxfTqJOaCRiONF4LLyIDpKRXFBTJzGl8dnqygzHCpkc/RNXVR8+YGJiq7TYUGh5TxJeNcl7WXOfgj9rETzoWIEMTQAK5wpW+dFw9LnagBRw3njJ3H1ynuUZl+/k5xX7u0Oifiqo2HxY8qQ4bxECvs1bymdPvrPOY49AxfkSIIpxGYaYO552Pn/UGBoA1BkSUzdPUrq5XuCnzPonHZJlzQis7UqhG3V3rHfPnh9BWD4IaLyr1ZL9bpmDvJcoN0yf71K1QT7criOVYE8r0kPG0bhB3oBAb3qOk38bbSKg=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 25523389-fac6-4468-b2ee-08d6ca708206
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 17:56:28.4797 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3145
X-OriginatorOrg: avaya.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bJ8RiUeOk5KpUWT8CNuJtTxtkoY>
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: Fri, 26 Apr 2019 17:56:43 -0000


> -----Original Message-----
> From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> Sent: Friday, April 26, 2019 5:02 AM
> To: Mudric, Dusan (Dusan) <dmudric@avaya.com>; ipv6@ietf.org; Ole Troan
> <otroan@employees.org>; , <jinmei@wide.ad.jp>
> Cc: Pascal Thubert (pthubert <pthubert@cisco.com>
> Subject: Re: encoding Subnet ID in link-local addrs (Re: about violation of
> standards)
> 
> 
> 
> Le 25/04/2019 à 16:32, Mudric, Dusan (Dusan) a écrit :
> >
> >> 2 IPv6 link-local addresses are typically self-configured according
> >> to 4 RFCs and relying on the fe80::/10 IANA allocation, RFC 54 0
> >> bits, and RFC MAC-based 64bit Interface IDs.  In some cases, it is
> >> advantageous to manually configure link-local addresses.  This is
> >> useful for easy remembering by humans, and for parameter resilience
> >> during network interface replacement.
> >>
> >> Manual configuration of an LL may use short IID and Subnet ID The
> >> Subnet ID presence in the link-local address is useful in some
> >> wireless settings where the subnet structure parameters depend on the
> >> link locality.  Other settings may also benefit.
> >>
> >> When manually setting the link-local address it is necessary to know
> >> the length of the prefix of the subnet on which this link-local
> >> address is present.  This length is necessary for on-link
> >> determination.
> >>
> > [Dusan] Is the Subnet ID unique per host?
> 
> In  my setting, the Subnet ID in the LL address is unique per subnet, not per
> host.  There is a subnet formed by the front bumper interface in the follower
> car and the rear bumper interface of the lead car.
> 
> The Subnet ID in an LL address would be unique per a set of hosts in that
> subnet.
> 
> > Is it possible that all hosts on the link share the same Subnet ID?
> 
> Yes, they should.
> 
> > Can somebody provide more details about the problem and how this
> > solution will solve the problem?
> 
> More details about the problem: RFC4291 54 0 bits would refuse to change to
> accomodate this solution's Subnet ID in an LL address; another detail is that
> one particular OS would not allow the manual configuration of an LL address
> setting some of these 54 0 bits.
> 
> Alex
> 
> >
[Dusan] These are RFC4291 and OS limitations, if you would define Subnet ID in LL address. Based on the comment above, I gather you are talking about vehicle-
   to-vehicle (V2V) communication. Looks like there are several cars talking to each other on the local link. They form a subnet. Somehow, somewhere, there is a master device that knows this is a subnet. May be that device's link is on the subnet. ...

- Can you please provide more details about the topology first,
- then, details about the restrictions with the current LL definition in that topology,
- then, details about the expected improvements if LL has the Subnet ID?

Once we understand these three categories, we will be able to talk about solutions. May be the solution will be generic enough to help other mobile hosts too, not just V2V.