IETF Logo Mail Archive

Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Sun, 16 July 2017 06:58 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 501161270A0 for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 23:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 QsyVS1EeSL3J for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 23:58:58 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF8E120454 for <ipv6@ietf.org>; Sat, 15 Jul 2017 23:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5840; q=dns/txt; s=iport; t=1500188337; x=1501397937; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=la1HiYnEF+/DppdknqlmXrpceW5HcKpEzeJfvCW1V3c=; b=BdYz5RNpZ+KgE3VTipKTonBXndlRl/54yHLUEC4rPu4GPB+rhOOXzBgE QYPSDFwtCe2IkSZ0xwiLOck4s2BDddK7/SDvVTEINUmzlrcyugjyRf2Hj g0fsMJscqyVyeZcsYVg8aWmA9LIgklqbrhwl1o9lM0bj5OIFFPaWYrfzZ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A5AQBADmtZ/49dJa1CGhoBAQEBAgEBAQEIAQEBAYNaZIEUjguRPZB6hSyCESEBDoUXAoNxPxgBAgEBAQEBAQFrKIUZAgEDAQFsCxACAQg/BycLFBECBA4FG4kwZBAysAGLEwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiDTYIMC4JugyaFB4IxBYlcjWaHcgKHSIxMki+VVgEfOIEKdRUfKhIBhTWBTnYBAYhUAQEB
X-IronPort-AV: E=Sophos;i="5.40,367,1496102400"; d="scan'208,217";a="454440557"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 06:58:48 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6G6wm1A011897 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 06:58:48 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 16 Jul 2017 01:58:47 -0500
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.1210.000; Sun, 16 Jul 2017 01:58:48 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Nick Hilliard <nick@foobar.org>
CC: Ole Troan <otroan@employees.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
Thread-Index: AQHS/a2ZuieUK0MP90SlnyedjyZgWqJVuZOAgAADEwCAAAKKgIAACwyAgAA8W14=
Date: Sun, 16 Jul 2017 06:58:48 +0000
Message-ID: <5C6E9C30-0217-4EEC-8A8D-F204002BE095@cisco.com>
References: <CAN-Dau2zgthR2w9e5ZVUdGc-vm+YvK2uTUJ8O=vrcv0jNc58RA@mail.gmail.com> <CAN-Dau1bxm5y0v_6kUBc_ym39bSSxepjdwrzcS7YHWD=CV9-bw@mail.gmail.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2x+282VK7nMFHjcCz9tBmJ_=d4OhkiRZFZDLcZhakGB1Q@mail.gmail.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2x7ER2fUietjT3Ns-jpCqscCmVDVubiM0Dgw1_L0bkw=A@mail.gmail.com> <c7b140bf69104cd3877a7da03fbf17e7@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <m1dVbRc-0000GQC@stereo.hq.phicoh.net> <b6da9e67-1f4e-8900-5a3b-575d0c6fd2fd@gmail.com> <m1dWNIL-0000FpC@stereo.hq.phicoh.net> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <BBC09C3B-BBA7-4B40-A44C-D6D7FB306314@employees.org> <596A8A5 2.9030108@foobar.org> <FCEE7BF1-A276-4243-B9CC-FE2BDE25183C@employees.org>, <596A95B7.6000408@foobar.org>
In-Reply-To: <596A95B7.6000408@foobar.org>
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: multipart/alternative; boundary="_000_5C6E9C3002174EEC8A8DF204002BE095ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RYuTeeMvqVOHEoxjy9hlTrSvWig>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 16 Jul 2017 06:58:59 -0000

I respectfully disagree.

There are a number of cases where an SDO designs on false assumptions of what the other is doing.

IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups which enables DAD and discovery to be perfectly fine. ND also expects that the core service that 802.1 provides on Ethernet (reliable broadcast) extends to the whole ESS so we have our problems solved. Sadly, no such thing.

The same exists in the other direction as well. IEEE expects that the AP will implement a magical ND proxy and that solves the problem. Again, the IETF has no such thing, at least for ND. Some people at IEEE think that bridging 48bits address to 64bits addresses will enable bridging with all it's nice properties on 802.15.4 links. Good thing this illusion is dissolving rapidly.

The solution is probably to stop throwing our problems over the fence (thanks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,_do_it_yourself<https://fr.m.wiktionary.org/w/index.php?title=if_you_want_a_thing_done_well,_do_it_yourself&action=edit&redlink=1>

The solution is probably to understand the IEEE design of an ESS for L2 operations and emulate it at L3. A step towards reconciliation of the designs may be to effectively provide the proxy that the IEEE expects to see at the boundary of the mediums.

All the best,

Pascal

Le 16 juil. 2017 ? 00:23, Nick Hilliard <nick@foobar.org<mailto:nick@foobar.org>> a ?crit :

Ole Troan wrote:
This a protocol problem. DAD is built with the assumption that
physical links are reliable. 20% packet loss for multicast is common
on wifi...

most protocols will croak at 20% packet loss.  If wifi cannot support
multicast properly, then this is an 802.11 problem rather than a problem
with DAD or any of the many other bits of ipv6 that depend on moderately
reliable multicast.

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email