IETF Logo Mail Archive

RE: [EXTERNAL] Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

Vasilenko Eduard <vasilenko.eduard@huawei.com> Fri, 06 November 2020 11:42 UTC

Return-Path: <vasilenko.eduard@huawei.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 ABF243A10DD for <ipv6@ietfa.amsl.com>; Fri, 6 Nov 2020 03:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 H-8OeapOe7UN for <ipv6@ietfa.amsl.com>; Fri, 6 Nov 2020 03:42:17 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB163A10DC for <ipv6@ietf.org>; Fri, 6 Nov 2020 03:42:17 -0800 (PST)
Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CSJNy3SDVz67JMr; Fri, 6 Nov 2020 19:40:50 +0800 (CST)
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 6 Nov 2020 12:42:14 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 6 Nov 2020 14:42:14 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 6 Nov 2020 14:42:14 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Fernando Gont <fgont@si6networks.com>, Fernando Gont <fernando@gont.com.ar>, IPv6 List <ipv6@ietf.org>
Subject: RE: [EXTERNAL] Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
Thread-Topic: [EXTERNAL] Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
Thread-Index: AQHWsWD+jaLPocGrmkKt7i0Js0+AUKm1zp+AgAGrwACAAHO+gIAAcwKAgAAbSwCAAQOfgIAALe6AgAAkIgCAAARigIAA/bKw///cjgCAADcFUP//08CAgABEsWA=
Date: Fri, 06 Nov 2020 11:42:14 +0000
Message-ID: <25af0e7be08d417582a6443fa42b0ba0@huawei.com>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CAKD1Yr0vvyQnTGRoSh4qa4He1gq5HXXRaKU3pVLtCtDUzcwL_w@mail.gmail.com> <CAD6AjGQPatbg5=OaMzxJXy5mGZai1bqLfg8f+9SUnfg=s1kADg@mail.gmail.com> <e55a9fbf-a93c-a96f-7991-f0c3aad8ce16@gmail.com> <CAD6AjGSTQjKQuY1+0DNm5NRgTRkWUQ=eRhnvyKCXvKc3Kvy9TQ@mail.gmail.com> <CAKD1Yr3h_Jypxx49-e-PUFvtX0y7DaXf-XvBgK4-oQAjEe8vvA@mail.gmail.com> <23631B74-1870-4F53-9CC1-F884505E61D8@gmail.com> <b9670467-b89b-27b4-4dbc-08c91fc7e74e@cea.fr> <2d4ceb2a759c49b6823e536b31d5e3e0@boeing.com> <4b7359b2ff2f48f79eef4c10c395c8e6@huawei.com> <f11ec469-42c3-b78c-d7f2-869645c5dc64@gont.com.ar> <be125a0f021b4310beb33e9d058f0b42@huawei.com> <88b4d394-4311-4a12-390c-fa4440d00301@si6networks.com>
In-Reply-To: <88b4d394-4311-4a12-390c-fa4440d00301@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.192.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yPrN-XGia5zv2Q0WM_GX8vYAU5A>
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, 06 Nov 2020 11:42:20 -0000

Address could not be flexible to infinity. It should have maximum. It is /64 now.
If it would become bigger - some protocols would have the challenge.
For example, temporary address generation (your rfc4941bis) would not have 64bits anymore for IID. We would need rfc4941_bis_bis
Ed/
> -----Original Message-----
> From: Fernando Gont [mailto:fgont@si6networks.com]
> Sent: 6 ноября 2020 г. 13:34
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Fernando Gont
> <fernando@gont.com.ar>; IPv6 List <ipv6@ietf.org>
> Subject: Re: [EXTERNAL] Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
> 
> On 6/11/20 07:18, Vasilenko Eduard wrote:
> > Hi Fernando,
> > I said that "address resolution is not needed". Some simplified protocol is
> needed anyway.
> > You have pointed to the manual address collision.
> 
> No. I pointed out that unless the IID is mandated to embed the underlying MAC
> address in all cases, you still need address resolution.
> 
> (and *that* has never been mandated).
> 
> 
> 
> > I could additionally say that the router should announce "seed" to obfuscate
> MAC addresses on this link (the same MAC should look different on different
> links).
> 
> Why should it?
> 
> 
> 
> > Additionally, RA is needed to centralized push of configuration information.
> > But it is not "neighbor discovery", it is "link configuration".
> > Well, it does not make sense to discuss - much smaller things has been
> rejected on 6man. It is really the revolution that I do believe make sense to push.
> >
> > But yes, such revolution would need to keep subnet boundary at the exact
> position (like /64).
> 
> Sorry, I'm lost here.
> 
> There's no *technical* reason for the subnet boundary to be required to be fixed
> at /64.
> 
> /64 was only needed if one wanted to support IID generation based on
> embedding MAC addresses on link-layers with 64-bit MACs.
> 
> Once we got rid of recommending that IIDs be generated by embeding the
> underlying mac address (think RFC8064), the only reason for mandating a fixed
> subnet boundary is electro-political, *not* technical.
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>

v2.23.0 | Report a Bug | By Email