RE: Reducing the battery impact of ND --> Problems with ND multicast

Samita Chakrabarti <samita.chakrabarti@ericsson.com> Thu, 06 February 2014 03:57 UTC

Return-Path: <samita.chakrabarti@ericsson.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25EB1A0365 for <ipv6@ietfa.amsl.com>; Wed, 5 Feb 2014 19:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 DO3tvrXAWOW9 for <ipv6@ietfa.amsl.com>; Wed, 5 Feb 2014 19:57:38 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 50B121A0363 for <ipv6@ietf.org>; Wed, 5 Feb 2014 19:57:38 -0800 (PST)
X-AuditID: c6180641-b7f2f8e000002cdc-7b-52f3082b1821
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 31.C8.11484.B2803F25; Thu, 6 Feb 2014 04:57:32 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 22:57:30 -0500
From: Samita Chakrabarti <samita.chakrabarti@ericsson.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Carsten Bormann <cabo@tzi.org>
Subject: RE: Reducing the battery impact of ND --> Problems with ND multicast
Thread-Topic: Reducing the battery impact of ND --> Problems with ND multicast
Thread-Index: Ac8i7uPla/9XE6YWQjay0j8vGecZpA==
Date: Thu, 06 Feb 2014 03:57:29 +0000
Message-ID: <ECA43DA70480A3498E43C3471FB2E1F01C15D6A7@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXRPrK4Ox+cgg1mdPBZHptxltXh59j2T xYwp7xgteu4tYXFg8ZjyeyOrx5IlP5k8FjyZy+YxbVFmAEsUl01Kak5mWWqRvl0CV8byWUkF vRYVT/pnsTcw3tbtYuTkkBAwkVixezcLhC0mceHeerYuRi4OIYEjjBIPXnWyQDjLGCV+bVvI DFLFJmAl0dG7hx3EFhEIk9hybTVYnFnAWeLa4XYwW1jAV2JdzxM2iJoAiS9Hp0LV60l8XtkF FmcRUJGYf6YDbDMvUP3JlxNYQWxGoCu+n1rDBDFTXOLWk/lMENcJSCzZc54ZwhaVePn4HyuE rSQxaek5Voh6PYkbU6ewQdjaEssWvmaGmC8ocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGLk KC1OLctNNzLcxAiMjWMSbI47GBd8sjzEKM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGxhV9c3/PWfx6c5+XH1eeX832M/fYfTc32n/trzoZLrLt4Yanoqee/RSNKWq5+IKd /V2pt0NT5IWdP/vqE1RCuNgZ8rnK74u55kxZ+TdN6nU667Rn/6dKz4yeepGtZaF3gOqDszt/ 2Ce5+7ku4bF3lVO82LjJWvdDtlfF/9fbLgR0aEe1Vv0OU2Ipzkg01GIuKk4EAPdoU81bAgAA
Cc: Thomas Watteyne <twatteyne@linear.com>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 06 Feb 2014 03:57:41 -0000

In order to provide more data on the problems with multicast on ND messages and hacks from vendors independently, the following information may be helpful. I am sure the internet is running and there are not many IPv6 implementations  out there, so it did not become a pain yet. 
The problems are two fold  1) vendor proprietary solutions/hacks 2) interoperability issues.  That is apparent in Wifi-controller and AP situation when the vendor specific hacks are only understood by the single vendor equipments.  

Here is an example of a problem case: 

Router--->Wifi-Cotnroller--->AP--->UE/Host

* Wifi-controller is sitting in a tree structure of AP and almost at the root of the tree.
* The ND multicast messages are replicated  via all physical and virtual ports. ARP and DHCPv4 broadcasts are also problematic.
* This Wifi-controller normally handles both fixed and mobile traffic as well. 
* One Wifi-Controller can have  up to a few  thousand AP
* Each AP can have up to several 100 Clients

Depending on the capacity of Wifi-controller, the number of physical ports and number of Aps could be large and they cannot tolerate periodic multicast or broadcast messages in order to maintain the delivery of user data. 

Solution: Hack  that works with one vendor's wifi-controller and APs.

M2M  nodes running IPv6:

Let's assume that in 3GPP there was some information IETF guidance to stop periodic RA, but if those devices move and go into a Wifi zone and are served by the wifi-Controller - the same wifi-controller and AP point problem arise. Of course vendors and operators are making things work with number of hacks and perhaps that provide advantage of vendor locking or making differentiation in one's portfolio.

M2M devices are large in number  for one wifi-controller's domain. [ several 100s to 1000s ]

The registration method helps keeping track of the node at the router/switch level for providing services, security and perhaps that can be somehow useful for tying up with other kind of intelligent decisions in SDN environment. 

If IETF promotes interoperability and promotes improvement of the decades-old protocol to work with needs for different usages of IPv6, I think efficient-nd offers solution for that. It may not be perfect today, but the question is to adopt  the document and allow improvements. 

To be honest, these problems are real and going through processes of writing up several documents before trying to solve a solution that has been implemented and proven in wireless networks will only make things worse. 

-Samita





-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Saturday, February 01, 2014 3:03 AM
To: Carsten Bormann
Cc: Thomas Watteyne; 6man WG
Subject: Re: Reducing the battery impact of ND

+1, Direct from an implementor of the hackery in question in widely distributed switches and wireless controllers.

Our first generation was really about protecting against rogues (SAVI, RA GUARD).

Interestingly, our second generation was focussed on multicast control to protect the wireless medium (ND Suppression including RA throttling and ND proxy) to address customers and product management requests for the wifi market.

Based on that support, I have developped a prototype backbone router that learns southwards from 6LoWPAN ND registration and proxies northwards classical ND.

6TiSCH has planned a plugfest during the IETF and I hope we´ll be able to demo this fonctionality at that time with real ipv6 motes.

Cheers,

Pascal

> Le 1 févr. 2014 à 11:05, "Carsten Bormann" <cabo@tzi.org> a écrit :
> 
> On 01 Feb 2014, at 08:49, Erik Nordmark <nordmark@acm.org> wrote:
> 
>>> ... and can someone please remind me what exactly was wrong with ARP? Other than the fact that v4 uses it?!
> 
> What Erik said, plus maybe this reminder:
> 
> When ARP was invented more than 30 years ago, Ethernet networks were run on the assumption that everyone on them could be trusted, both from a security and from an implementation bugs perspective.
> (Those yellow-cable networks were so fragile... Let's not digress.)
> 
> To make ARP actually work in less peaceful environments, there is usually significant hackery deployed at layer 2 (in Ethernet switches and WiFi base stations/controllers).  With all that hackery in place, it may *seem* as if ARP works, but it is really the combination of the ARP implementation in the IP nodes and the magic in the switches that makes this so.
> 
> ND inherited most of this situation, except that the hackery wasn't deployed yet.  That's why you hear so much about ND being "insecure", "not deployable" - ND really is much better than ARP, it just had to wait for the hacks to catch up.  The directed multicast of ND (as opposed to ARP's broadcast) only makes a difference where L2 actually implements that directionality; more hackery.  (The irony is that MLD now becomes an address registration protocol that is needed to make the illusion of "no registration" work at the ND level, but I digress again.)
> 
> So the reality today is that we have this fragile combination of the documented protocols and the switch vendor magic that makes it all work.  Of course, the switch vendors don't complain; it creates an opportunity for market differentiation.
> 
> Now, for 6LoWPAN, we had to build something that relies much less on multicast.  That became 6LoWPAN-ND, RFC 6775.  Having built this fine hammer, of course other nails sprang to mind.  The above situation looks like a fine nail to me (except that legacy compatibility makes things so much more complex).  That's maybe the explanation why this discussion didn't start with documenting the well-known problems, but with looking at one specific solution, and how it could be made to work with legacy.  But I agree documenting the problem would be a worthwhile exercise, if it is not used as an excuse to stop looking for solutions.
> 
> Clearly, efficient-ND will work best if it doesn't require a new layer of L2 hackery, and if it cooperates reasonable with (or works around) the existing, deployed hackery.  This is more work to make sure given that this hackery is only partially documented.  So that is maybe another reason to work on documenting ARP/ND's problems and the existing magic.
> 
> Grüße, Carsten
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------