Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 7 Jan 2014 09:45:46 +0100 (CET)

On Fri, 20 Dec 2013, Mark ZZZ Smith wrote:

> Perhaps it might be better to treat the link as an NBMA subnet, and use 
> RFC2491 "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" to 
> eliminate all multicasts (including ND, MLD and application), except 
> perhaps RAs with a flag that indicate the link is operating in NBMA 
> mode (with RA timers larger than defaults - IIRC, the max router age 
> value is 90 minutes, so unsolicited RAs can be around 30 minutes apart)?

I have had similar thoughts.

I would like to have mode where no discovery is done at all anymore, and 
in order to support legacy hosts, one way of doing that would be:

Legacy hosts see RAs with M=1, and they are handed address using DHCPv6 
IA_NA if they ask for it. They will not see any on-link prefix, and will 
send all traffic through the router. The router will install ND entry 
based on lifetime of the DHCPv6 IA_NA.

EAH will be able to do autoconfig by means of seeing an on-link /64 that 
is in a RA option that differs in a way that legacy hosts won't use it 
(preferrably also just unicasted to EAH by the router in response to RS). 
EAH use ARO to register their address just as in the draft.

If the router gets a packet to an address it doesn't have in the ND table, 
it just drops the packet. All traffic on the LAN is routed through the 
router, and optionally it can choose to send unicast redirects if it feels 
traffic is to hosts in the same L2 network.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 7 Jan 2014 20:18:22 +0000

Hi Mikael and Mark:

Thanks for your comments and support on this draft.

The following in-line comments discusses your suggestions - the part that is covered already and the part that can be improved during the progress of the document. 

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, January 07, 2014 12:46 AM
To: Mark ZZZ Smith
Cc: Samita Chakrabarti; Ole Troan; 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

I have had similar thoughts.
[SC>] ----------------------------------------------------------

It is in fact treating somewhat similar to IPv6 over NBMA to eliminate multicast and keeping a database to register all the hosts its serving and advertising its capability of doing so in RA (E-bit).

But these networks are NOT "non-broadcast" network -- for example behavior of wireless network is shared, multi-accessed, sometimes battery powered etc.  Thus a registration is necessary to reliably handle the address resolution and duplicate address detection. Erik can provide more details on the background on the registration need by having designed both RFC4861 and the registration method mentioned in this document.

In mixed mode, the document does allow RA timers with large time-intervals. (section 12). If you prefer particular default interval [30min?], we can add a parameter in the constants section (section 20). The current text at the end of section 12 says:

"In mixed mode, the NEAR SHOULD have a configurable interval for
   periodic unsolicited router advertisements based on the media type."
[SC>] --------------------------------------------------------------------------------------------

I would like to have mode where no discovery is done at all anymore, and in order to support legacy hosts, one way of doing that would be:

Legacy hosts see RAs with M=1, and they are handed address using DHCPv6 IA_NA if they ask for it. They will not see any on-link prefix, and will send all traffic through the router. The router will install ND entry based on lifetime of the DHCPv6 IA_NA.
[SC>]----------------------------------------------------------------

The document , in mixed mode  is silent about off-link Neighbor discovery for legacy routers and enhanced mode only supports off-link ND -- thus in enhanced mode all packets are flowing through the NEAR. 
Section 12 [ mixed mode section]

"Both in mixed-mode and efficiency-aware mode, the NEAR
   sets E-bit flag in the RA and does not set 'L' on-link bit."

The document does not restrict mixed mode legacy nodes to be  off-link without understanding the full implications of the backward compatibility.

[SC>] We have a section on DHCP interaction.  Your proposal of using DHCPv6 IA_NA could apply there (section 17.3).  Let's discuss the details  off-line.

[SC>] ----------------------------------------------------
EAH will be able to do autoconfig by means of seeing an on-link /64 that is in a RA option that differs in a way that legacy hosts won't use it (preferrably also just unicasted to EAH by the router in response to RS). 
EAH use ARO to register their address just as in the draft.

If the router gets a packet to an address it doesn't have in the ND table, it just drops the packet. All traffic on the LAN is routed through the router, and optionally it can choose to send unicast redirects if it feels traffic is to hosts in the same L2 network.
[SC>] ----------------------------------------------------------------------------

Exactly. Though the document does not encourage "redirect"  messaging as it is a general support for all kinds of links from wired to lossy and non-transitive radio links, optionally one can configure to have redirect messaging if the deployment environment allows it. Here is an excerpt from the current text.

Redirect Messages:      A router SHOULD NOT send a Redirect message
                           to a host since the link has non-transitive
                           reachability.  The host behavior is same as
                           described in section 8.3 of RFC 4861[ND],
                           i,e. a host MUST NOT send or accept redirect
                           messages when in efficiency-aware mode.
                           Same as in RFC 4861[ND]

[SC>] Thanks so much.
-Samita

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Jan 2014 19:49:05 +0900

On Tue, Nov 19, 2013 at 7:45 PM, Ole Troan <[email-masked]> wrote:

> Please provide a view with reasons as to whether the WG should adopt this
> or not.
>
> This message starts a one week 6MAN Working Group call on adopting:
>
>         Title           : Wired and Wireless IPv6 Neighbor Discovery
> Optimizations
>

I do not support adoption of this draft. I do see the problem, but I think
the proposed solution is the wrong trade-off.

Let's consider examine the benefit. In most networks, the problems cited
can be addressed using existing technology without requiring such a major
overhaul of a core IPv6 protocol. For example, to take the problem areas
mentioned in section 1.1:

   - It's true that periodic RA messages consume battery power, but this
   can be fixed by sending periodic RAs much less often and sending solicited
   RAs unicast, or by using DHCPv6 with long leases for address assignments.
   - It's true that NS/NA messages and RS do consume battery power, but
   unlike IPv4, ND cache entries don't time out, and thanks to the use of
   solicited-node multicast, NS messages are easy to filter either in the
   switches/APs or in the receiving devices' radio firmware. Also, the impact
   can be limited by using fewer nodes per link.
   - In many cases, it's possible to remove ND load entirely by setting the
   prefix to be off-link and having everything go through the first-hop
   router. In the case where the router is the same box as the AP, this has no
   scalability limitations at all.
   - It's true that on wifi, multicast/broadcast bandwidth is limited.
   However, this is not a problem in general-purpose networks. General-purpose
   networks typically run IPv4 as well, and IPv4 with ARP is way less
   efficient than standard ND.

I think it's fair to say that in most networks, these measures will be
sufficient to resolve most of the problems without having to alter the ND
protocol.

The cost of the proposed solution is significantly increasing the
complexity and statefulness of the ND protocol, which is implemented, often
in kernel space, in billions of general-purpose nodes. I think that's
something that requires much more compelling reasons than the ones provided
here. The concerns are not just implementation complexity, but also
operational complexity, flexibility, and reliability.  For example: part of
the promise of IPv6 is that it allows networks to be simpler and more
reliable. Putting more state in the network nullifies that promise.

Don't get me wrong - I agree that in some networks these issues are
critical, and something like this is needed. However, that's what 6lowpan
is for. I think a much better tradeoff is for power-constrained devices to
use their own ND protocol in their own low-power network (which connects to
the rest of the network via a gateway), and to leave the general purpose ND
protocol unchanged.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 8 Jan 2014 13:12:32 +0100 (CET)

On Wed, 8 Jan 2014, Lorenzo Colitti wrote:

> sufficient to resolve most of the problems without having to alter the 
> ND protocol.

For me, another important issue to solve is the ND exhaustion when there 
is scanning going on. So for me, the value of this document is if there is 
a "non-discovery mode" of ND implemented. It might be better to do this in 
a different document, I don't know.

So a mode where the clients use ARO to register their addresses, and 
legacy clients use DHCPv6 for IA_NA and the ND table is populated by these 
two mechanisms and packets destined for unknown IPv6 addresses are just 
dropped.

This would be a big win, especially if it could be done with minimal 
changes to the clients.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 10:53:02 +0900

> This would be a big win, especially if it could be done with minimal

You don't need to modify ND to do that, though. You can defend against that
sort of attack by having the ND implementation:

1. Prioritize preserving ND cache entries over making new address
resolution attempts.
2. Glean ND cache entries from DAD packets (and if need be, NS/NA packets),
and prioritize those gleaned entries over new address resolution attempts.

Some of these measures are documented in RFC 6583.

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 9 Jan 2014 02:57:12 +0000

Hi Lorenzo:

Mikael>  This would be a big win, especially if it could be done with minimal changes to the clients.

You don't need to modify ND to do that, though. You can defend against that sort of attack by having the ND implementation:

1. Prioritize preserving ND cache entries over making new address resolution attempts.
2. Glean ND cache entries from DAD packets (and if need be, NS/NA packets), and prioritize those gleaned entries over new address resolution attempts.

Some of these measures are documented in RFC 6583.
[SC>]
[SC>] I understand that you have a view point.  But  there are  many folks/vendors who have expressed interest/supported this work, see a need to improve ND  as it has operational issues for IPv6 deployment on large scale, wireless switches, virtualized environments. RFC 6583 (mentioned above) discusses ND operational issues and tips for implementation. There are number of drafts, RFC and pieces discussing improvements on different ND usecases and scenarios. It does not help implementers to understand and deploy Ipv6 ND easily in many scenarios – including M2M, wireless phones, monitoring cameras and so on. A revised/improved ND is needed for IPv6.
We started on this draft  sometime ago, after an IOT IAB workshop where  people felt that clearly there is a need to clarify IPv6 ND behavior to 1) reduce multicast messages 2) allow removal of DAD in some situations 3) allow registration of nodes for reliable ND operation when multicast is reduced.
There are some real wireless and  wired  deployments which will benefit if the ND registration/optimization for IPv6 is specified in one document as a standard without affecting the legacy ND implementations or deployment. [ Check out the appendix section]

Our solution is looking into minimal changes to the clients and most of the changes are in the Router implementation and  some implementations already exist through RFC6775 – however that does not directly address IPv6 legacy networks. So the purpose is to provide options to a section of Ipv6 enabled devices/routers/servers that can optionally implement efficient-ND behavior to improve their Ipv6 networks (single hop LAN).

I know we can clarify these in the document and improve the text to be precise going forward.
-Samita

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 12:45:32 +0900

On Thu, Jan 9, 2014 at 11:57 AM, Samita Chakrabarti <
[email-masked]> wrote:

>  *A revised/improved ND is needed for IPv6.*
>
>  *We started on this draft  sometime ago, after an IOT IAB workshop where
>  people felt that clearly there is a need to clarify IPv6 ND behavior to 1)
> reduce multicast messages 2) allow removal of DAD in some situations 3)
> allow registration of nodes for reliable ND operation when multicast is
> reduced.*
>

Samita,

I think statements like "is needed" and "people felt" are not enough to
justify substantial changes to a core part of the protocol. The rationale
should be clearly stated in technical terms in the document, and should be
convincing on its own merits. For this sort of changes to core protocols,
the bar should be set very high.

>  *There are some real wireless and  wired  deployments which will benefit
> if the ND registration/optimization for IPv6 is specified in one document
> as a standard without affecting the legacy ND implementations or
> deployment. [ Check out the appendix section]*
>

Sorry, I didn't provide comments on the rationale in the appendix. Here are
some comments now:

1. Datacenter deployments. Really? A datacenter is a place where machines
have high-bandwidth interconnects and plentiful CPU because they are
engaged in production activities - otherwise you don't build a datacenter.
I cannot imagine that even if a datacenter at trough consumes 1/10 of the
compute power of one at peak, that the energy saved by efficient ND is even
a drop in the ocean of cooling, power conversion losses, energy used by
network equipment, etc.

If a machine in sleep mode cannot receive ND packets, then it cannot
receive unicast packets either and there's no point proxying ND requests
for it. Remember - ND is only performed *when someone wants to send you a
packet anyway*. If the machine *can* receive ND packets, then presumably
going into and out of sleep mode is fast, so to save energy it's enough to
ensure that ND is only triggered rarely - which there are ways to do as
listed in my previous email.

2. NUD scaling on the BNG. What's the use case here? Is it to reduce the NS
messages sent to the CPE to make it easier for the CPU? Is there any
evidence that the load is significant enough to care, and if it is, that
something like this can't just be done on the linecards? As for wired and
wireless devices, I think I addressed that point in my previous email.

3. M2M. Agreed, but that's what 6lowpan is for, right?

4. Wifi. I already addressed this, but let me address it again. a) Do you
run IPv4? If you run out of multicast bandwidth, IPv4 is broken. b) In
large wifi networks, which is the only place that this is really an issue
exists, the infrastructure is usually more than capable of converting
multicast to unicast. c) If the concern is power draw on devices, then the
wifi chipsets of those devices are are receiving packets all the time,
right? There are constant beacons, and so on. So it's just a matter of
telling the wifi chipsets to drop packets that aren't addressed to
multicast addresses that the device hasn't registered for. Wifi chipsets
already have RX filtering that can do this.

>  *Our solution is looking into minimal changes to the clients and most of
> the changes are in the Router implementation and  some implementations
> already exist through RFC6775 – however that does not directly address IPv6
> legacy networks.*
>

By definition, legacy networks can't use new technology. If what you mean
is "non-6LowPAN IPv6 networks", then the question is - do we really need
such a level of energy efficiency in these networks?

If those networks happen to run IPv4 - which basically *all* hosts on
broadcast networks do, then the answer is a clear no - because ARP is much
more wasteful than ND. When we move to IPv6-only, then we should definitely
reconsider this optimization, but until then, there will be no benefit.

Cheers,
Lorenzo

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 07:09:13 +0100 (CET)

> Some of these measures are documented in RFC 6583.

If I do that, can I instantly drop packets not in my ND table already? (or 
my table of 1 and 2 above)?

If not, I don't consider it a complete solution.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 15:22:18 +0900

> If not, I don't consider it a complete solution.

I'm afraid I don't understand the question. You can't "just drop packets
not in your ND table already" - otherwise you won't be able to talk to a
new host that just joined the link. What I believe you can do is, even when
you are under full-scale attack, allow the following to work:

1. Communications to and from devices in your table keep working.
2. New directly-connected devices can make it into your neighbour cache.

Is there something else would you want to do?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 08:05:34 +0100 (CET)

On Thu, 9 Jan 2014, Lorenzo Colitti wrote:

> new host that just joined the link. What I believe you can do is, even 
> when you are under full-scale attack, allow the following to work:

If you glean the DAD packet the host most likely will emit, then that 
works around the problem.

> Is there something else would you want to do?

No, that is exactly what I want to do, but I don't want to start doing 
discovery because I received a packet from an external source to an 
address on my LAN I don't currently have any decent knowledge of that it 
is in use.

That knowledge might come from seeing a DAD packet or some other 
mechanism.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 16:17:37 +0900

> works around the problem.

Or the RSes which it also most likely will emit (and, with
draft-6man-resilient-rs, which it will continue to emit until you send it
an RA), yes.

> No, that is exactly what I want to do,

So if that's what you want to do, then I think you can do it with the
current ND protocol, even if you are under full-scale attack, with the
implementation optimizations I described (gleaning and prioritization).

> but I don't want to start doing discovery because I received a packet from
> an external source to an address on my LAN I don't currently have any
> decent knowledge of that it is in use.
>

Why not? What's the downside of sending out an NS for an address that's not
there? You consume an ND cache slot for the incomplete entry, but if you
use the optimizations you'll always have enough space to avoid a DoS
scenario.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 08:57:28 +0100 (CET)

On Thu, 9 Jan 2014, Lorenzo Colitti wrote:

> Why not? What's the downside of sending out an NS for an address that's 
> not there? You consume an ND cache slot for the incomplete entry, but if 
> you use the optimizations you'll always have enough space to avoid a DoS 
> scenario.

Because potentially this would cause hundreds or thousands of NS multicast 
packets on the LAN per second in a ddos scenario?

If we can avoid the router having to learn anything by means of external 
packet triggers, I think it would be a big win.

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Jan 2014 10:38:16 +0100

On 09 Jan 2014, at 8:57 , Mikael Abrahamsson <[email-masked]> wrote:

>> Why not? What's the downside of sending out an NS for an address that's not there? You consume an ND cache slot for the incomplete entry, but if you use the optimizations you'll always have enough space to avoid a DoS scenario.
> 
> Because potentially this would cause hundreds or thousands of NS multicast packets on the LAN per second in a ddos scenario?
> 
> If we can avoid the router having to learn anything by means of external packet triggers, I think it would be a big win.

a game of whac-a-mole? ;-)
at least you have a new set of problems that needs to be solved.

- how is state maintained on the first-hop router(s)?
  how does the host detect that the first-hop router has lost state?
  how do you synchronize state between the set of routers on the link?
- while ND classic scales by the number of active addresses on the link,
  you'll now scale by the total number of addresses on the link
- how do routers garbage collect? i.e. how do routers detect that an address is no longer in use, 
  the node has left the link?

as Lorenzo stated I believe the external DOS attacks on the ND cache can be mostly mitigated
by a good implementation. prioritising the active speakers, rate-limiting the number of request per second,
use a circular buffer and so on. it wouldn't be completely unexpected if there was some level of
stateful or stateless filtering being done on the borders stopping these forms of attacks either.

that said, vendors do implement snooping solutions e.g. 
http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-3s/ip6f-xe-3s-book.pdf
(not touting cisco's solution here, I'm sure all the other vendors have similar, but it was the
first I found). 

that use ND and DHCP snooping to maintain a stateful table on the first-hop routers and switches.
address registration may make such solutions easier to implement.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 18:57:56 +0900

> packets on the LAN per second in a ddos scenario?

They would be rate-limited, just like any other ND packets on any
implementation worth its salt. I think an NS is 72 bytes including ICMPv6
header; if so, then even if you send out 500 of them per second, that's 36
kB/s. What sort of link has a problem carrying 36 kB/s? How many NSes per
second can routers send out anyway?

> packet triggers, I think it would be a big win.

Maybe in terms of bandwidth, but that's not free - you're trading off
bandwidth with state. The state has to be maintained, recovered on reboot,
synchronized between multiple routers, etc. etc., and that is brittle.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 13:44:14 +0100 (CET)

On Thu, 9 Jan 2014, Lorenzo Colitti wrote:

> implementation worth its salt. I think an NS is 72 bytes including 
> ICMPv6 header; if so, then even if you send out 500 of them per second, 
> that's 36 kB/s. What sort of link has a problem carrying 36 kB/s? How 
> many NSes per second can routers send out anyway?

I don't know, people seem to indicate that there is a problem with 
multicast pps on wifi links. I haven't seen any hard data on this, it was 
just my interpretation that this was considered a problem.

> bandwidth with state. The state has to be maintained, recovered on 
> reboot, synchronized between multiple routers, etc. etc., and that is 
> brittle.

Yes, I agree.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 13:45:38 +0100 (CET)

> at least you have a new set of problems that needs to be solved.

Absolutely. My first thinking was to understand if this could be done with 
minimal changes to the clients.

> as Lorenzo stated I believe the external DOS attacks on the ND cache can 
> be mostly mitigated by a good implementation. prioritising the active 
> speakers, rate-limiting the number of request per second, use a circular 
> buffer and so on. it wouldn't be completely unexpected if there was some 
> level of stateful or stateless filtering being done on the borders 
> stopping these forms of attacks either.

Well, that's a different game of whack-a-mole that needs flow state to be 
kept in order to find attacks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 22:33:37 +0900

> just my interpretation that this was considered a problem.

Knowing nothing about this, I will cite
http://stackoverflow.com/a/4341485, hoping that the draft authors will
come along with more detailed data
(which hopefully they have already presented to justify their use case and
which I missed):

===
With unicast the access point tracks what data rate every particular
receiver can reliably receive at, and sends about that rate. With multicast
the access point does not know which receivers are interested in the data,
so simple access points send the data at the slowest possible rate (1Mb/s).
Better implemented access points may send the data at the rate that the
slowest connected client is using, and the best access points use IGMP
snooping to see who's receiving each IP multicast stream, and they will
choose the slowest rate out of the receivers for that stream.
===

Even 1Mbps is still a fair number of ND packets though.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 23:21:55 +0900

On Thu, Jan 9, 2014 at 10:33 PM, Lorenzo Colitti <[email-masked]> wrote:

> Knowing nothing about this, I will cite http://stackoverflow.com/a/4341485, hoping that the draft authors will come along with more detailed data

Ok, so in VERY unscientific testing, tcpdump says that in 1 second, my
phone was able to receive 2500-3000 72-byte IPv6 multicast packets sent by
my laptop. This is on a 5GHz network using a standard home router access
point (D-Link DIR-835). That doesn't seem all that slow.

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 09 Jan 2014 16:29:11 +0100 (CET)

> point (D-Link DIR-835). That doesn't seem all that slow.

A couple of questions worth pondering: how much of the channel
capacity is consumed by that traffic, and what was the limiting
factor in your experiment.

Regards,

- Håvard

---

From: Sander Steffann <[email-masked]>
Date: Thu, 9 Jan 2014 22:48:22 +0100

Hi,

Op 9 jan. 2014, om 14:33 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:

> They would be rate-limited, just like any other ND packets on any implementation worth its salt. I think an NS is 72 bytes including ICMPv6 header; if so, then even if you send out 500 of them per second, that's 36 kB/s. What sort of link has a problem carrying 36 kB/s? How many NSes per second can routers send out anyway?
> 
> I don't know, people seem to indicate that there is a problem with multicast pps on wifi links. I haven't seen any hard data on this, it was just my interpretation that this was considered a problem.
> 
> Knowing nothing about this, I will cite http://stackoverflow.com/a/4341485 , hoping that the draft authors will come along with more detailed data (which hopefully they have already presented to justify their use case and which I missed):
> 
> ===
> With unicast the access point tracks what data rate every particular receiver can reliably receive at, and sends about that rate. With multicast the access point does not know which receivers are interested in the data, so simple access points send the data at the slowest possible rate (1Mb/s). Better implemented access points may send the data at the rate that the slowest connected client is using, and the best access points use IGMP snooping to see who's receiving each IP multicast stream, and they will choose the slowest rate out of the receivers for that stream.
> ===
> 

I think the issue is that, while 1Mbps is enough for ND, it is lowering the speed for the whole channel. So in the time that the 72 byte packet is sent at 1Mbps there *could* have been 3888 bytes at 54Mbps. And I have no idea if the speed switch itself takes up any time.

I know that Andrew Yourtchenko has some real life experience with this stuff, so I'll put him in CC in case he has something to add.

Cheers,
Sander

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 10 Jan 2014 11:22:50 +0000

Ole

As you asked for a review... here is belated one... (bear in mind that I still have to read the whole thread... I do need an efficient email processing brain!)

First, centralization and the removal of mcast traffic has already an impact on security, security (and operation probably) people tend to prefer strong centralized architecture vs. decentralized ones because they are easier to control. Of course, the drawback is 'single point of failure'

Sometimes, the ID looks more like a marketing document "optimization will be highly effective" ;-) Also, too many sentences & concepts that are relevant in the past 6lowpan WG. Some acronyms are used (NCE) before being defined (if at all for neighbor cache entry)

Mandatory use of SLAAC and EUI-64. In the contex of privacy (and possible obsolete EUI-64 + stable privacy address), I wonder whether it is still useful to rely on EUI-64. I guess that changing to a stable but private IID would be enough. The text is not really clear whether this EUI-64 is only for LLA or for any global address.

In section 4, I failed to understand the link between ULA & EUI-64.

Section 7.1, it is also unclear for me when talking about a unique address per host, does this include LLA as well? Or ULA (cfr low end CPE) in combination with GUA? Most of the document seems to indicate only EUI-64 while this section seems more open (then I remove previous comments of course). If EUI-64 is 'just' used as a node identifier/unique-ID (and not linked to any IPv6 address) why not simply using DHCP DUID? Or even the layer-2 address (assuming that this one is unique & stable). Then, I strongly suggest removing all reference to EUI-64 and use 'opaque node unique ID'.

There is the mention of 'transaction' but to me it appears as a shoot a packet and hope that it is not lost and that the receiver gets it...

Be sure to mention unauthenticated WiFi DoS against the router table as a node could easily change of MAC address and fill the table. Bringing the whole network down (including intra-link traffic). 

Also, the behavior should be explained when the NEAR receives ARO with different lifetimes, which ones to keep? Suggestion: If the 'index' to the table is no more EUI-64 (which is guessable) but an opaque/random but stable identifier (such as DHCP DUID), then the NEAR could overwrite the existing entries only when NS/ARO has the right identifier/cookie?

11.1 another way to prevent NDP cache exhaustion is simply not doing NS/NA when NEAR receives a packet to an unknown destination.

Who announced mixed mode? Can this be downgraded by sending a fake RA without the E-bit? Hence, being no more efficient? No clue on how to fix it though ;-)

Not clear to me whether CGA is supported... I would guess not, then it should be stated somewhere

15. Again, I am not really a big fan on relying on EUI-64 addresses... see above. Then, DAD is more important. Later in the section, it is talked about 64-bit MAC addresses... which is unusual on legacy W/LAN ;-)

17.2 should really be closer to the section describing mixed-mode operation

19 it makes this I-D really close to 6lowpan and similar use cases while there are benefits of this I-D applicable outside of 6lowpan as explained in appendix A

Final recommendation: remove the use cases and create a problem statement I-D because, again, the problem is wider than NS/NA (too many mcast RS/RA and other protocols such as mDNS).

Hope this helps

-éric

> From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: mardi 19 novembre 2013 11:46
> To: 6man WG
> Cc: 6man Chairs
> Subject: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-
> nd-04
> 
> All,
> 
> There was moderate support to adopt this draft at the working group
> meeting in Vancouver.
> This is an adoption call to confirm the result of the hum at the meeting.
> 
> 	Author(s)    : S. Chakrabarti, E. Nordmark, P. Thubert, M. Wasserman
> 	Filename    : draft-chakrabarti-nordmark-6man-efficient-nd-04
> 	Pages        : 31
> 	Date          : 2013-10-22
> 
>   http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-
> 04
> 
> The call ends on November 26th, 2013.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Fri, 10 Jan 2014 23:57:59 +0000

Sander thanks!

all,

first off - apologies for the length of this mail, I tried to
structure it so that first I talk about what I think the
multicast-related issues are on the WiFi (what Sander asked), and then
add a few thoughts overall that I finally have managed to put on
paper. So feel free to doze off while reading, as you see fit :-)

There are two main issues related to "too much" multicast packets on WiFi:

1) Indeed the multicast frames are transmitted at a lower rate (and as
the SO entry tells, also the mileage varies)

That said, 1Mbps rate is becoming somewhat of a corner case - usually
those rates are disabled due to their general poor throughput and
realistically it will probably be 11Mbps rate, the highest for 802.11b
devices - or 12Mbps in case you do not support 802.11b-only clients
(most of the client gear today supports either 802.11g or 802.11n).

So this becomes somewhat less of a problem, though considering that
"WiFi guys" are generally reluctant to even advertise an extra SSID
with no clients (overhead being 10pps of broadcasted beacon frames at
low data rate), you will notice every PPS helps. Andrew von Nagy has a
great calculator telling exactly how much it helps, for the extra SSID
case, at [3]. But I think we can creatively equate it to each
additional 10pps of all-hosts multicast. As you see, it's noticeable.

2) The bigger problem - the battery life:

WiFi is a pretty expensive thing to do, power-wise. To help extend the
battery, the mobile devices try very hard to shut off the radio
whenever they can. The wireless station would go to sleep, and inform
the AP about this fact - so the AP can buffer the frames for it [1].
Further optimizations in this area were introduced by 802.11e (WMM-PS)
[2], where the frames destined to workstation could be transmitted
more efficiently and radio duty cycle is reduced.

Spontaneous all-hosts multicasts interfere with these mechanisms, thus
the battery drain on the devices is much higher - especially in a
typical network where the mobile devices move, and might trigger an
RS/RA on each L2 roam between BSSIDs.

So, if a host typically gets one packet burst per minute, and, say, it
decides to put the radio to sleep 15 seconds after no packets, it will
have 25% power consumption compared to the case where the same host
needs to process a 0.1pps (one packet in 10 seconds) of all-hosts
mcast.
So, that means if the gadget survives 8 hours in a quiet home network,
now it will die after 2 hours [4].

This issue especially manifesting itself in the high-density/event
wifi deployments, generally people are very upset when their gadgets
run out of juice.

All of the above said:

both of these issues are already somewhat taken care of by the tweaks
at the data-link layer: e.g. my employer's wifi gear will replicate
the RAs as unicast packets over the radio, and also if so configured,
it can both block the excessive multicast RA sent to all-hosts, as
well as track which clients were originating the RS, and prune the
unicast over-the-air delivery to only those hosts that have just sent
"unanswered" RS messages. (This is fixable much easier at the router
by sending solicited RAs unicast, but this is a different story).
Also, both ARP and ND are proxied to some extent, given that the
controller (a box that centrally handles the traffic from APs and
their configurations) has a very good awareness of the clients and can
judge about their addresses to some extent by their traffic.

For the roaming: any WiFi network with more than 1 access-points does
a lot of roaming stuff at L2 already, tries to do it as fast as
possible, and it's even standardized in 802.11r [6], so approaching it
with an L3-only hat on as if it is a brand new problem, is suboptimal
IMHO.

I hear someone saying: "Yes, but this is all about wireless, DC is all
different story - it's all switches, they don't hold the state!" - yes
and no. The hosts in the DC are increasingly VMs, which run on top of
the hypervisor - and is there something with *more* state related to
the host than the hypervisor running such a host ?

This is my concern with adding a relatively large chunk of a protocol
on top of the existing crutches: how much does it get us compared to
what we have already, and at what cost...

To summarize:

I do think the problems this draft talks about are real. But after a
*lot* of deliberation I think the solution should be more lightweight
and more incrementally implementable/deployable than what the draft
offers wholesale.

At a non-100% deployed rate the approach in the draft will add more
headaches to the administrators and users than help IMHO.

Now, while I have a mic, let me take my napkin with some sketches ... ;-)

Maybe worth to split the problem area into smaller subsets and see
whether a "cheaper" solutions are possible. Let's first take the
"multicast RAs" problem, and assume we do the below steps:

a) Allow the environments that wish to do so, to send solicited RAs
unicast. (standard already permits to do so).

b) Have the hosts restart the  Resilient RS [5] process at 1/2 or so
of router lifetime expiry: the router now can have the heuristic to
know which hosts are supporting the "unicast RA update" mechanism
*and* did not receive the periodic RA which would have been sent
usually at 1/3 the lifetime expiry (three RAs per lifetime rule of
thumb).

c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to
their maximum theoretically possible values (spec says the hosts
should already be able to handle those, I did not test though) - this
would allow to further reduce the periodic RA frequency, from 2.5
hours today to ~18.2 hours, or, if we feel adventurous, put all-ones
to be a "solicited-only RAs by default" - thus, unless another router
sends an RA with different lifetime, refreshing the router info
becomes host-driven, with an option for a router to override at any
time.

These steps take care of the "multicast RA" problem. But again, also,
each of them by itself brings incremental usefulness, and is doable on
a single device => no "chicken and egg", they gradually shrink the
issue - and are compatible with the existing tweaks that solve the
same problem (in a more layer-violating way).

Now let's think of updating the various caches while roaming:

d) we could make a tweak to allow the solicited unicast RA from (a) to
contain an arbitrary blob created by the router, and require that the
"router refresh" (b) RSes from the host to contain this blob from the
router that they are currently using as the default router.

e) Request the host to send this "refresh" RS ahead of time if they
get a notification from a data-link layer that a link has changed.
AFAIK this is something that already happens today, at least for some
hosts.

f) Define the magic pixel dust that is put into a blob by a router,
such that the receiving router could un-dust this blob in the
subsequent "refresh" RS and do the necessary notifications/updates
(this protocol would be entirely at router-switch side and would not
need any more mods by hosts).

These three would help with quicker refresh of L3/L2 data while
roaming, and also each of them brings some incremental benefits of
various sorts, is doable on a single device, and can make use of the
lower-layer optimizations if necessary.

NB: the above does not take care of the "defending the host's address
on behalf of the sleeping node" problem. I think there is a good use
in splitting it as a separate function, because "sleeping node" can be
rather a "node on the very expensive bandwidth" - so something
developed here could also apply to e.g. 3G/LTE devices, instead of
today's diode firewalls - and would not necessarily be limited to
current segment, nor hard-coupled with the router function. But the
magic pixel dust from (f) above could supposedly be a building block
for such a protocol of for a part thereof.

NB2: the above is nothing more than a napkin-sketch of what I think
may work, I have not thought about the corner cases of it, etc. If the
community thinks it would be interesting to transfer the above from a
napkin onto a draft or drafts, I could do it.

If you made it to here - thanks for reading ! :-)

[1] http://en.wikipedia.org/wiki/Delivery_traffic_indication_message

[2] http://en.wikipedia.org/wiki/IEEE_802.11e-2005#APSD

[3] https://www.dropbox.com/s/imjrugrpyyscd7/Wi-Fi%20SSID%20Overhead%20Calculator.xlsx

[4] this is a SWAG. I do not have hard data, just the theoretical
knowledge of what is at play, and the empirical observations from
various networks. The activity to measure it is on my todo list.

[5] http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-02

[6] http://www.cwnp.com/cmsAdmin/uploads/802-11_rsn_ft.pdf

--a

On 1/9/14, Sander Steffann <[email-masked]> wrote:
>> Knowing nothing about this, I will cite http://stackoverflow.com/a/4341485
>> , hoping that the draft authors will come along with more detailed data
>> receiver can reliably receive at, and sends about that rate. With
>> multicast the access point does not know which receivers are interested in
>> the data, so simple access points send the data at the slowest possible
>> rate (1Mb/s). Better implemented access points may send the data at the
>> rate that the slowest connected client is using, and the best access
>> points use IGMP snooping to see who's receiving each IP multicast stream,
>> and they will choose the slowest rate out of the receivers for that
>> stream.
>> ===
>>
> I think the issue is that, while 1Mbps is enough for ND, it is lowering the
> speed for the whole channel. So in the time that the 72 byte packet is sent
> at 1Mbps there *could* have been 3888 bytes at 54Mbps. And I have no idea if
> the speed switch itself takes up any time.
>
> I know that Andrew Yourtchenko has some real life experience with this
> stuff, so I'll put him in CC in case he has something to add.
>
> Cheers,
> Sander
>
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 11 Jan 2014 02:57:12 +0000

Hello Eric and Andrew:

Thank you both very much for providing the detail comments, helpful suggestions  and helping with clarifying the existing issues in IPv6 ND with more data.

We, the co-authors are going to work with the WG chairs in light of the comments we gathered so far in the list and submit improved versions in next few weeks.

Thanks to all who provided comments/insights, pointed out  the weaknesses, and to those who supported the document to be adopted.

-Samita