RE: about violation of standards
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 23 April 2019 10:20 UTC
Return-Path: <pthubert@cisco.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 1E37C12021F for <ipv6@ietfa.amsl.com>; Tue, 23 Apr 2019 03:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 header.b=VTIxwEJ1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mb7sL9d/
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 bqfAsIrCEv2U for <ipv6@ietfa.amsl.com>; Tue, 23 Apr 2019 03:19:58 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40AA12003F for <ipv6@ietf.org>; Tue, 23 Apr 2019 03:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4709; q=dns/txt; s=iport; t=1556014797; x=1557224397; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1X5OlsSlw3yC/L16l5yg9krKlkZRhkZB8M3FVc8uM+E=; b=VTIxwEJ1Ph8B5U4GFvqoVsVurMCnK0wqzned5i1uKy7LLKf1M49c/rgU VcpSm+4ePVdjD/6i780126S1pMhEd2ERs6t2xAvD1Co8mLcA3FBQNsvTA 6vJynruFtgXzWaeKXRps3+riWo60gFFss1jqPXE+ahMhNUycT1biM4WXP U=;
IronPort-PHdr: 9a23:t77mrBX6hCk22f/cdptu/UanqqXV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtankiAMRfXlJ/41mwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AkAACQ5r5c/4sNJK1mGwEBAQEDAQEBBwMBAQGBUgUBAQELAYE9JCwDaFUgBAsohA6DRwOPFIJXiTqNY4EugXsOAQEYCwqEQAKGJyM1CA4BAwEBBAEBAgECbRwMhUoBAQEDAQEBHwEeAQEsCwELBAIBCA4DBAEBAgMLGgMCIQYLHQgCBA4FCIMbgWkDDQ8BAgyMSpBeAooUbAGBM4J5AQEFhQANC4INAwaBCCoBi0kXgUA/gRFGgkw+ghpHAQGBY4MFNIIminsHmyA4CQKCCI5gg2WVFJQJjDYCBAIEBQIOAQEFgVABNoFWcBU7gmyCDgwXg0yFFIU/coEpjHcCJAEDgigBAQ
X-IronPort-AV: E=Sophos;i="5.60,385,1549929600"; d="scan'208";a="464765814"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Apr 2019 10:19:55 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x3NAJtID032725 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Apr 2019 10:19:55 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Apr 2019 05:19:55 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Apr 2019 05:19:54 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 23 Apr 2019 05:19:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1X5OlsSlw3yC/L16l5yg9krKlkZRhkZB8M3FVc8uM+E=; b=mb7sL9d/2ZClPRr70UvEe+KCgjmVFef0zThY3d2b4cYuQfJ0E3E0u7EXxQC6rajppu7tU5h5dOJlwlZf5YZqg9P/xCbln6uiUG2ClpIWkgLXvYvnOra/dCBVOeflrme+FIQf84QnKJ8kFfWdpy7RunzxT4ju58LAS8UkVrzO0EQ=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3870.namprd11.prod.outlook.com (10.255.180.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Tue, 23 Apr 2019 10:19:54 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::68f6:21c8:b681:c73]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::68f6:21c8:b681:c73%4]) with mapi id 15.20.1813.017; Tue, 23 Apr 2019 10:19:54 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Ole Troan <otroan@employees.org>
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
Thread-Topic: about violation of standards
Thread-Index: AQHU9hjz0VelQW2CM0S4qjQG7Nm8iaZCZ5mAgAAz6wCAAAwogIAAZyaogAZSawCAABw6IA==
Date: Tue, 23 Apr 2019 10:19:52 +0000
Deferred-Delivery: Tue, 23 Apr 2019 10:19:29 +0000
Message-ID: <MN2PR11MB35655B36540829AEE5275964D8230@MN2PR11MB3565.namprd11.prod.outlook.com>
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>
In-Reply-To: <47631828-121F-402D-8165-969684C1101B@employees.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be550818-61fe-4945-2b50-08d6c7d53a61
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3870;
x-ms-traffictypediagnostic: MN2PR11MB3870:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB3870A29523CB18AAE5937FD3D8230@MN2PR11MB3870.namprd11.prod.outlook.com>
x-forefront-prvs: 0016DEFF96
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(396003)(366004)(39860400002)(13464003)(189003)(199004)(54906003)(5660300002)(52536014)(229853002)(14444005)(256004)(316002)(66574012)(3480700005)(93886005)(71200400001)(71190400001)(99286004)(8936002)(81166006)(6116002)(6436002)(81156014)(8676002)(53936002)(446003)(9686003)(476003)(86362001)(53546011)(11346002)(6246003)(7736002)(305945005)(6506007)(102836004)(14454004)(74316002)(68736007)(486006)(4326008)(966005)(186003)(66446008)(66946007)(64756008)(66556008)(66476007)(33656002)(2906002)(97736004)(76116006)(55016002)(25786009)(46003)(478600001)(6306002)(76176011)(73956011)(6916009)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3870; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: lTuV3JWyFMC4ADuhN9CgcHsbJVak+Hn04bVAPwnnom5vY967dtV9abvZwbgWj0XbHtHtyaDzjeQ8mh4/i5oMUxvOXjyI2GJQ2OL8NP8FPytF+OtY/klnbq+f1nSJq8xtEK5frfm3XG6mk73l0PDlM3yeyRC+ZCmH4t+fO71ZG10LOtchpJnXHC3k/fJjhNjYVumPDn1mZijO/BOeApPy9WWbgQKAq6LbPLpVCZ3dudI3O3F8IUw8i+vguYy7ZFNh1YRCrwANLSmEoUccNxLc2ta1B64XYBcKy2cX8lYnKi0AxQxpqtsDIAc1x0U9tV8Gisr5oSSDkwlMH7SJir5/C4Jbw9mzN2oTKQqMHvGpXk/hwa4ZOgRfa9kxY9tv3euzemSkexgNT/v6n60V/5++mzdR7QQmRNCW/b1AQVIW61Y=
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: be550818-61fe-4945-2b50-08d6c7d53a61
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 10:19:53.9550 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3870
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4UmllI6gX-YNzzqUixKxZXcxj1o>
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 10:20:01 -0000
> > 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 > --------------------------------------------------------------------
- Re: about violation of standards Kerry Lynn
- about violation of standards Alexandre Petrescu
- Re: about violation of standards Suresh Krishnan
- Re: about violation of standards Kerry Lynn
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Kerry Lynn
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards 神明達哉
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Mark Smith
- Re: about violation of standards Fernando Gont
- Re: about violation of standards 神明達哉
- Re: about violation of standards Pascal Thubert (pthubert)
- encoding link ID in link-local addrs (Re: about v… 神明達哉
- Re: encoding link ID in link-local addrs (Re: abo… 神明達哉
- Re: encoding link ID in link-local addrs (Re: abo… Gyan Mishra
- Re: encoding link ID in link-local addrs (Re: abo… Gyan Mishra
- Re: about violation of standards Yucel Guven
- Re: about violation of standards 神明達哉
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Nick Hilliard
- Re: about violation of standards Gyan Mishra
- Re: about violation of standards Gyan Mishra
- Re: about violation of standards Gyan Mishra
- Re: about violation of standards Gyan Mishra
- Re: about violation of standards Ole Troan
- Globally Unique Link Local Addresses (Re: about v… Mark Smith
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- RE: about violation of standards Pascal Thubert (pthubert)
- Re: about violation of standards Ole Troan
- Re: Globally Unique Link Local Addresses (Re: abo… Philip Homburg
- Re: Globally Unique Link Local Addresses (Re: abo… Brian E Carpenter
- Re: about violation of standards Brian E Carpenter
- Re: about violation of standards Gyan Mishra
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: Globally Unique Link Local Addresses (Re: abo… Gyan Mishra
- Re: Globally Unique Link Local Addresses (Re: abo… 神明達哉
- Re: about violation of standards Mikael Abrahamsson
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Andrews
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: about violation of standards - security matte… Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: about violation of standards - fe80::1/128 Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: about violation of standards - fe80::1/128 神明達哉
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Ole Troan
- Re: about violation of standards Nick Hilliard
- Re: about violation of standards Yucel Guven
- Re: Globally Unique Link Local Addresses (Re: abo… 神明達哉
- Re: Globally Unique Link Local Addresses (Re: abo… Brian E Carpenter
- Re: encoding link ID in link-local addrs (Re: abo… 神明達哉
- Re: about violation of standards Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: Globally Unique Link Local Addresses (Re: abo… Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Philip Homburg
- Re: encoding link ID in link-local addrs (Re: abo… Ole Troan
- Re: encoding link ID in link-local addrs (Re: abo… Mudric, Dusan (Dusan)
- Re: about violation of standards Yucel Guven
- Re: encoding link ID in link-local addrs (Re: abo… 神明達哉
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Andrews
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: about violation of standards - fe80::1/128 Gyan Mishra
- Re: encoding link ID in link-local addrs (Re: abo… Brian E Carpenter
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: about violation of standards - fe80::1/128 Pascal Thubert (pthubert)
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Andrews
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: easy to remember addresses and /etc/hosts and… Alexandre Petrescu
- Re: encoding Subnet ID in link-local addrs - prob… Alexandre Petrescu
- Re: easy to remember addresses and /etc/hosts and… Mark Smith
- Re: easy to remember addresses and /etc/hosts and… Alexandre Petrescu
- Re: easy to remember addresses and /etc/hosts and… Mark Smith
- Re: easy to remember addresses and /etc/hosts and… Alexandre Petrescu
- Re: about violation of standards Yucel Guven
- Re: easy to remember addresses and /etc/hosts and… Kerry Lynn
- RE: encoding Subnet ID in link-local addrs (Re: a… Mudric, Dusan (Dusan)
- Re: about violation of standards Erik Kline
- RE: encoding Subnet ID in link-local addrs (Re: a… Manfredi (US), Albert E
- Re: Globally Unique Link Local Addresses (Re: abo… Gyan Mishra
- Reinventing Site-Locals (Re: easy to remember add… Mark Smith
- Re: Reinventing Site-Locals (Re: easy to remember… Mark Smith
- Re: Reinventing Site-Locals (Re: easy to remember… Brian E Carpenter
- Re: disagreement on which OS should change Gyan Mishra
- Re: about violation of standards Fernando Gont
- Re: disagreement on which OS should change Brian Carpenter
- Re: disagreement on which OS should change Ole Troan
- Re: disagreement on which OS should change Fernando Gont
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: easy to remember addresses and /etc/hosts and… Alexandre Petrescu
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- Re: disagreement on which OS should change Gyan Mishra
- Re: disagreement on which OS should change 神明達哉
- Re: disagreement on which OS should change Bob Hinden
- Re: disagreement on which OS should change Gyan Mishra
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- Re: disagreement on which OS should change Bob Hinden
- Re: Reinventing Site-Locals Alexandre Petrescu
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: disagreement on which OS should change Tim Chown
- Re: disagreement on which OS should change Bob Hinden
- Wireless ND was: about violation of standards Pascal Thubert (pthubert)
- Re: Wireless ND was: about violation of standards Philip Homburg
- Re: Wireless ND was: about violation of standards Ole Troan
- RE: Wireless ND was: about violation of standards Pascal Thubert (pthubert)
- RE: Wireless ND was: about violation of standards Pascal Thubert (pthubert)
- Re: Wireless ND was: about violation of standards Ole Troan
- RE: Wireless ND was: about violation of standards Pascal Thubert (pthubert)
- Re: Wireless ND was: about violation of standards Philip Homburg
- RE: encoding Subnet ID in link-local addrs (Re: a… Mudric, Dusan (Dusan)
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- RE: encoding Subnet ID in link-local addrs (Re: a… Mudric, Dusan (Dusan)
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- Re: about violation of standards Erik Kline
- Re: about violation of standards Erik Kline