IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Sun, 16 July 2017 05:50 UTC

Return-Path: <otroan@employees.org>
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 C207012700F for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 22:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 zcI1Z56Q4Hl9 for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 22:50:03 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F061120726 for <ipv6@ietf.org>; Sat, 15 Jul 2017 22:50:03 -0700 (PDT)
Received: from [192.168.10.201] (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id AFE282D4F96; Sun, 16 Jul 2017 05:50:00 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (14G57)
In-Reply-To: <c6777f76-bb77-9610-4e9c-03a80cd693fa@gmail.com>
Date: Sun, 16 Jul 2017 07:49:55 +0200
Cc: David Farmer <farmer@umn.edu>, Nick Hilliard <nick@foobar.org>, ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <92A09555-5A34-406C-B5BB-D5C02D6AD431@employees.org>
References: <CAN-Dau2zgthR2w9e5ZVUdGc-vm+YvK2uTUJ8O=vrcv0jNc58RA@mail.gmail.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> <6a23ce43-89c3-0b37-a2da-70d40ba48b53@gmail.com> <AAA57E96-F827-4563-9950-285FBF1A603D@umn.edu> <c6777f76-bb77-9610-4e9c-03a80cd693fa@gmail.co m>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Pz1xkA7V-eNsNK5FBl6BmONjHCA>
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 05:50:05 -0000


> On 16 Jul 2017, at 01:59, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
>> On 16/07/2017 11:37, David Farmer wrote:
>> 
>>>> On Jul 15, 2017, at 17:41, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>> 
>>>>> On 16/07/2017 10:22, Nick Hilliard wrote:
>>>>> 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.    
>>> 
>>> I'm curious. If DAD has that problem, why doesn't Neighbor Discovery
>>> have an equally bad problem?
>>> 
>>> BTW, Ole is correct. While testing the GRASP prototype at the last IETF,
>>> we discovered a high loss rate for LL multicast on the network.
>>> However, it wasn't primarily due to WiFi. It was due to intentional
>>> multicast throttling in the switches:
>>> https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ
>> 
>> Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND proxy, and they convert the responses from the proxy to unicast at the 802.11 layer. Sometimes they even only do unicast at the 802.11 layer and replicate all multicast into 802.11 unicasts. Frequently this is more efficient than multicast because of the differences between the basic rate encoding used for multicast packets vs the usually much higher density encoding used for unicast packets.
>> 
>> That usually keeps things working well enough.
> 
> ND proxy shouldn't break DAD, as I understand RFC4389. So logically,
> DAD is just as reliable as basic ND, right?

Wrong. 
DAD is by default a single fire and forget packet. 
If you by basic ND mean address resolution, then that retries three times. And the consequences of failure are quite different. 

Ole

v2.23.0 | Report a Bug | By Email