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

From: Ole Troan <[email-masked]>
Date: Tue, 19 Nov 2013 11:45:41 +0100

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.

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
	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: Dan Luedtke <[email-masked]>
Date: Tue, 19 Nov 2013 14:50:17 +0100

Hi,

I know I am too late to make any significat contribution but I like to
express why I think this draft is only the second best solution to the
problem.

A switch should not send a solicited node multicast packet to all
connected devices but only to those which's hardware address matches
the last 24 bit. In case of non-EUI64 addresses (e.g. Privacy
Extensions), the node has previously joined the solicited node
multicast groups matching the last 24 bit of its addresses. A switch
should track the corresponding MLD messages and thus be able to
transmit the multicast message only to the affected ports. Not every
multicast message on network layer has to become a broadcast message
on link layer. In fact, most switches just flood out multicast packets
on all ports, but I see more of a switch issue here than a protocol
flaw in NDP.
IMHO this is a problem on the link layer and should not lead to quirks
or increase of complexity in network layer protocols.

On wireless links the situation is probably very different and the
wakeup of nodes heavily depends on how many multicast addresses the
hardware can listen to without waking up CPU and driver software. My
understanding is that there is some kind of hardware filtering before
the OS stack gets notified.

I also dislike the idea of centralizing the network management by
using a single instance (the router) for node registration. It's
probably more a personal thing but to me a network seems more reliable
if the nodes "defend" their addresses themselves via DAD.

Here are my comments:

Section 1.2:
> EUI-64 identifiers are recommended as unique Interface Identifiers,
> however if the network is isolated from the Internet, uniqueness of
> the identifiers may be obtained by other mechanisms such as a random
> number generator with lowest collision rate.
Does this collide with draft-gont-6man-deprecate-eui64-based-addresses-00?

Section 3.:
> An EUI-64 interface ID required for global
> communication.
See above.

Section 9:
> A legacy IPv6 Host compliant EAH SHOULD be able to fall
> back to RFC 4861 host behavior if there is no efficiency-aware router
> (NEAR) in the link.
I would like to see a MUST here instead of a SHOULD. The definition of
"legacy compliant" implies being able to fall back. Did I miss the
point here?

Section 10.2:
> The new default
> router then first sends a NS to its peers with a link scope multicast
> message to IPv6 address ff02::2 with the ARO option.
Just bikeshedding, sorry, but I would like to see "all link-local
routers multicast address" instead of the constant ff02::2.

Section 20:
> MIN_DELAY_BETWEEN_RAS(CHANGED)          1 second
Wow. I consider this a big change! What is the reason for chosing 1
second? We are not speaking of periodic RA, right? Then why wait a
second between two unicast RA, it does slow down things. For example
massive movement of mobile clients from one wifi to another. Happens
on conferences sometimes :)
Again, I might miss the point here since I had not the time to get to
know this draft earlier.

Some possible minor typos?!:
> intermediate devices include Wireless Controllers that terminate a
> overlay tunnel
typo: an overlay

> o  In a datacenter, where VM mobility and VM address reslution also
typo: resolution

Regards,

Dan

-- 
Dan Luedtke
http://www.danrl.de

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2013 10:59:46 -0800

[Sorry about responding to the wrong thread.]

Dan,

Thanks for your review comments.

If MLD-snooping was implemented in every L2 device (not just switches,
but also wireless access points, etc) then the impact of multicast NSs
sent for the purposes of address resolution would be reduced.

But the draft is also addressing the other cases of multicast:
  - periodic RAs
  - multicast NS/NA for the purposes of duplicate address detection
  - a host sending a multicast NS to its peer when the routers already
know the MAC address of the peer; redirect messages solve that without
any multicasts

All of those current uses of multicast are part of the motivation for
the draft. The other part of the motivation is to facilitate sleeping
hosts. If you follow the letter in RFC 4861/62 hosts have to be always
be awake to respond to any DAD probe that might arrive, or the hosts
have to redo multicast DAD each time they wake up. Finally having
registrations in the routers provides a standardized approach of
avoiding ND DoS attacks.

More comments below.

On 11/19/13 5:50 AM, Dan Luedtke wrote:> Hi,
 > the OS stack gets notified.

A fair number of existing Ethernets are being turned into wireless by
adding wireless APs. Thus it would seem beneficial to have a common
approach to reducing multicasts and facilitating sleeping hosts.

 > if the nodes "defend" their addresses themselves via DAD.

As long as there is no packet loss and all the hosts are always awake
and reachable, then the current RFC 4862 DAD is perfect. However, to
make the current peer-to-peer DAD robust in the case of packet loss
would mean multicast more than one initial DAD; periodic DAD packets
would seem needed.

Note that it wouldn't be a single router but the set of routers attached
to the link. We have an outstanding question around VRRP routers - and
resolving that one should improve the distribution of the state across
the routers attached to the link.

 > Does this collide with
draft-gont-6man-deprecate-eui64-based-addresses-00?

Perhaps the draft needs to be more clear on this, but the use of the
EUI-64 (or some other long-term stable identifier) in the ARO is solely
local between the host and the 1st hop routers. (It is needed to tell
the difference between a re-registration by the same host and a
conflicting registration by some other host.)

That is orthogonal to any use of EUI-64 in IPv6 IIDs and IPv6 addresses
- they do not need to use EUI-64 to use ARO. Hence we can (and IMHO
should) deprecate the EUI-64-based addresses.

But we clearly need to state this in the document - it isn't the first
time the question has come up.

 > "legacy compliant" implies being able to fall back. Did I miss the

Perhaps the "legacy compliant" is unfortunate. If we remove those words
I think a "SHOULD" is the proper choice - perhaps with an additional
explanation that such fallback is needed in order to interoperate with
legacy routers. So we'll reword it.

 > routers multicast address" instead of the constant ff02::2.

Thanks - will fix.

 > Again, I might miss the point here since I had not the time to get to

MIN_DELAY_BETWEEN_RAS is only for multicast RAs (see RFC 4861).
Perhaps we should clarify this in the document.

 >> intermediate devices include Wireless Controllers that terminate a

OK

 >> o  In a datacenter, where VM mobility and VM address reslution also

Thanks,
    Erik

---

From: Erik Kline <[email-masked]>
Date: Tue, 19 Nov 2013 11:17:22 -0800

> Please provide a view with reasons as to whether the WG should adopt this or not.

I know I promised to give more detailed feedback, but time is not on
my side at the moment.  Still, I'd like to say why I'm not in favor of
this work.

Fundamentally, the main use case seems to be trying to merge two
different link types.  One link type for low power nodes, one for
"more traditional" nodes, if you will.

I think we have *routing* for this.  Merging what is really two
different L2 types so that they can try to be one seemless L2 domain
still doesn't feel right to me.

Just my top-level 2 cents.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2013 11:21:34 -0800

> "more traditional" nodes, if you will.

Erik,

I guess I don't understand the future tense you are using.
The deployed networks have already merged WiFi with Ethernet by having 
APs which make the whole thing look as one broadcast domain.

This draft is merely trying to cope better with that fact.

    Erik

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 19 Nov 2013 11:23:13 -0800 (PST)

----- Original Message -----
> From: Erik Nordmark <[email-masked]>
> To: Dan Luedtke <[email-masked]>; Ole Troan <[email-masked]>
> Cc: 6man Chairs <[email-masked]>; 6man WG <[email-masked]>
> Sent: Wednesday, 20 November 2013 5:59 AM
> Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04
> 

It is also a method of preventing source address spoofing towards off-link victims. The router could refuse to forward packets for which the source address isn't registered and therefore validated as present.

Regards,
Mark.

<snip>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Nov 2013 14:49:49 +0900

On Wed, Nov 20, 2013 at 4:23 AM, Mark ZZZ Smith
<[email-masked]>wrote:

> It is also a method of preventing source address spoofing towards off-link
> victims. The router could refuse to forward packets for which the source
> address isn't registered and therefore validated as present.
>

More in general, it's a way for the router to control what the host can do
on the link, and what addresses it can assume. We never had that in the
IPv6 architecture. Why do we need it?

And, yes, I am well aware that "we can already do this today stuff". The
problem is that that argument isn't really true. Sure, a wifi AP can
already decide to accept packets only if your IID is prime and the
 immediately-highest on-link is a perfect square. And sure, a wifi AP can
already deny the capability to use more than one address - hell, it can
simply dropping all the sent by all addresses except one. And sure, an
operator can already decide not to let you onto the network if you don't do
DHCPv6.

But we *don't do* this today. Why? Because it breaks compliant host
implementations, and when hosts break users complain, and when users
complain it creates pressure on the network operator and the network
designer to fix the problem.

For example: today, if you only accept packets from two IPv6 addresses per
MAC address, then implementations break. Privacy addresses don't work, the
host has no way of knowing that its packets are being dropped, and things
generally don't work that well. At best, HE implementations will use IPv4
and possibly cause scaling issues on NATs and latency issues for users.
This suboptimal operation causes operators to modify their configurations
in order to provide working service to clients. This is very different from
making registraion a supported mode of operation.

What this draft proposes is to place the control of what happens on link in
the hands of the registering router, and make this a *supported mode of
operation*. Yes, this is possible today, but *not without application
breakage*. There is a huge difference; in fact, it's quite a fundamental
change in the architecture to have a limited set of layer 3 devices be
gatekeepers for all on-link communication.

---

From: Dan Luedtke <[email-masked]>
Date: Wed, 20 Nov 2013 09:59:35 +0100

Hi,

> But the draft is also addressing the other cases of multicast:
An EAND host ignores RA multicast until its internal timer suggests to
request a new unicast RA. In the meantime an other router may have
become the default router or some options of the initial RA are
re-accounced with a zero lifetime. For example, a set of RDNSS and/or
one or more prefixes may have been added or removed (prefix lifetime
of zero removes the prefix from the link, right?). The only way to
remove a prefix from the link with EAND hosts present is to fade it
out by decreasing the lifetime over time. A sudden removal, which is
used in some fail-over scenarios, is not supported if I understand the
draft correctly. So a new unicast RA has to be send out to all EAND
hosts that may be affected by such a prefix removal by the router.
This implies keeping much more state information in the router than I
would like to see there. Especially on very populated links.

> - multicast NS/NA for the purposes of duplicate address detection
Which are addressed to the solicited node multicast address which is
distinguished by 2^24 bytes. Ideally this is a one node group in a
link with about 16 million nodes. In reality this is not the case but
these groups are _mostly_ populated by only one node. And ideally the
packets won't be flooded to nodes that are not member of the group.
Again we come to the point were we try to solve a link-layer problem
at the network layer. Don't get me wrong, I see the problem but I just
can't support a draft introducing more complexity at the wrong layer.

> know the MAC address of the peer; redirect messages solve that without
In some setups redirect messages are ignored (which is not always a
good idea, but these cases exist) by hosts. These hosts would have to
accept redirect messages. Replacing multicast with redirect messages,
and thus requiring a third party in the communication with a neighbor,
seems too complex to me. As a network engineer I would like to stick
with multicast and not having a router acting as message broker for
on-link communication.

Lorenzo Colitti wrote:
>There is a huge difference; in fact, it's quite a fundamental change in the architecture to have a limited set of layer 3 devices be gatekeepers for all on-link communication.
I would go one step further and say: If routers become gatekeepers for
the communication between hosts, then they could as well *route* the
traffic. The proposed solution is something between real on-link
communication and real routing.

Although I find this draft interesting and would like to take the
challenge of implementing it in my existing software just to see how
different the outcome is in reality, I object this draft. It
concentrates too much power at too few devices thus changing the whole
way the on-link communication should work. Furthermore, as I
understand, EAND will be *added* to the current IPv6 stacks in nodes
leading to a more complex stack. It can not replace current code for
the sake of legacy compatibility which is needed in link-layers
without router (thinking of ad-hoc wifi for example). If EAND becomes
standard I will probably implement it, until then I have to object it
for the reasons I mentioned in this thread.

Best regards

Dan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Nov 2013 18:40:49 +0000

Hello Erik and Ole,

There are multiple possible deployments that require the registration mechanism. The case that you seem to refer to when "trying to merge two different link types" is probably that of  802.15.4 (aka LoWPAN), clearly a different family of MAC, 64bits address, etc.... You'll note that this is not the case that this draft addresses. Interestingly, we discussed that issue at IEEE last week, and concluded as you do here that if you connect a 802.15.4 network to a .1/.11 backbone, bridging is not the way to go between the 2 link types. So clearly, as we build a multilink subnet with 802.15.4 at the edge, we must place a router - called backbone router in ISA100.11a - between the .1 and the .15.4 links. You will note that even in that case, we need the registration mechanism to perform DAD - RFC 6775 was initially designed in that context -, and that proxy ND can be used at the backbone router, as discussed in the original ML subnet draft by Dave and Christian.

Now, WiFi does not qualify as 'a different link type' that would require routing to Ethernet; on a same AP, some clients may be low power and some will not, and we could bridge either way. The problem arises when the number of clients grow and intensifies when they move. We do not want to renumber each time a device re-associates to the next AP, so we care for a rather large subnet. And there, it is not just a problem of implementing multicast at layer 2 in a fashion  that serves solicited node mcast addresses, placing the burden on another layer that, as it goes, does not have the adapted support in place... There is also the need for much faster DAD (not based on timing out) and lookup operations that do not depend on a response from a sleeping device, a need for movement detection that does not consider that 2 advertisements from 2 places mean that there are 2 routes to the same address but can differentiate up to date from stale.

DAD, lookup, scalability, fast movement ... we can address these better in ND than in a routing protocol; imagine that we need some MANET properties, plus DAD features, and at a large scale, all in a single routing protocol. So the idea here is to divide and conquer; use routing inside the .1/.11 fabric to L2R (e.g. ISIS at L2) in a fashion that leaves the L2 topology mostly stable and acceptable in scale, and then handle the L3 issues at L3 so that support for movement does not require either broadcasts or constant reachability, and can be achieved in a split second. The question that the WiND draft addresses is such L3 operation on the backbone, whatever the client is, .11, .15.4 via a router, or even a VM. We'll note that on top of enabling unicast DAD and lookup, fast mobility, and sleeping devices, the draft also allows a degree of visibility and control on the network that matches an actual demand from operators. The difference is that today, this result is obtained by snooping the multicast protocols in SAVI implementations. 

Cheers,

Pascal

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Erik Kline
Sent: mardi 19 novembre 2013 20:17
To: Ole Troan
Cc: 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

> Please provide a view with reasons as to whether the WG should adopt this or not.

I know I promised to give more detailed feedback, but time is not on my side at the moment.  Still, I'd like to say why I'm not in favor of this work.

Fundamentally, the main use case seems to be trying to merge two different link types.  One link type for low power nodes, one for "more traditional" nodes, if you will.

I think we have *routing* for this.  Merging what is really two different L2 types so that they can try to be one seemless L2 domain still doesn't feel right to me.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Nov 2013 17:09:46 +0900

On Thu, Nov 21, 2013 at 3:40 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> So clearly, as we build a multilink subnet with 802.15.4 at the edge, we
> must place a router - called backbone router in ISA100.11a - between the .1
> and the .15.4 links. You will note that even in that case, we need the
> registration mechanism to perform DAD - RFC 6775 was initially designed in
> that context -, and that proxy ND can be used at the backbone router, as
> discussed in the original ML subnet draft by Dave and Christian.
>

If you're routing, why do you need proxy ND? Just give the 802.15.4 network
a separate /64 and run 6LoWPAN ND inside it.

I think that's when Erik says "merging two link types is not the solution",
that's what he means. I think he's just suggesting that you use existing
standard ND in the high-powered network and existing 6LowPAN ND in the
low-power network, and just route between them. That way you don't have to
define a new ND protocol.

> Now, WiFi does not qualify as 'a different link type' that would require
> routing to Ethernet; on a same AP, some clients may be low power

Well, but isn't wifi fundamentally unsuited for low-power networks anyway?
It's got beacons going all the time, it has multicast, etc.

> We do not want to renumber each time a device re-associates to the next
> AP, so we care for a rather large subnet. And there, it is not just a
> problem of implementing multicast at layer 2 in a fashion  that serves
> solicited node mcast addresses, placing the burden on another layer that,
> as it goes, does not have the adapted support in place...

You don't have to change ND to do that. All you need to do is either use
solicited-multicast node addresses over the multicast channel or, if the
subnet is SO large that ND requests are overwhelming (but that seems like a
LOT of ND traffic - how many clients do you need before this starts
happening?), use MLDv2 snooping and send the NS packets L2 unicast to their
destination.

> There is also the need for much faster DAD (not based on timing out)

What's the use case for faster DAD if you have optimistic DAD?

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Thu, 21 Nov 2013 09:20:10 +0000

Hi,
I support this draft: besides the operational value already mentioned, I
can see all the cool things we would be able to do, to scale up the number
of node on the link.
 
Broadcasting on the link is quite fine when you have a limited number of
addresses to deal with, and the dynamic is low. But we plan for layer-2
networks much bigger and much more dynamic (industrial, datacenter, very
large campus) and broadcasting + caching is creating a bottleneck.
 
I imagine we could also do routing with a cache instead of a table, and
broadcast queries to find the destination prefix. Everybody would agree it
does not scale. It's not just the
numbers; it's also the dynamic.
 
I ran a simple math: 100,000 nodes, 3 addresses each, 10% of nodes moving
every minute (moves can be physical or virtual), 3 multicast messages sent
per move (DAD, NA, MLD), message size could go from 100B to 1KB (when
using CGA for instance), that would range from 1 Mbit to 8 Mbit/sec.
Definitely an issue for the wireless links, but not only.
Last but not least, there is quite a bit of latency involved when looking
for a target that is not in cache.

A cache is a good response to these problems, as long as the dynamic is
low. But it's just a cache: when numbers grow, it can't keep up.  And it¹s
not designed to be distributed.
Registration and dissemination (this draft, and sail-draft) propose a
shift to a more pro-active approach, "a la" routing. Any node looking for
an address on-link will either have it in its table (not cache) or will
know who have it (that's the distribution part).
The critical piece is not just registration; it's also distribution so
that the information is available quickly where it's needed, along the
forwarding path.  

There is a lot to clarify though: co-existence with the legacy model,
distribution scheme (hierarchical, hash-based, Š), nature of the
registrars (Routers? Switches? DHCP servers? Š).

Eric

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 21 Nov 2013 14:56:03 +0000

I support the adoption of this draft.

Thanks
Suresh

----- Original Message -----
From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
To: Ole Troan <[email-masked]>, 6man WG <[email-masked]>
Cc: 6man Chairs <[email-masked]>
Sent: 11/21/2013 3:20 AM
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

Hi,

Eric

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 25 Nov 2013 10:41:17 +0000

I also do support the adoption of the draft
Maria Rita

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Thursday, November 21, 2013 3:56 PM
To: Eric Levy- Abegnoli (elevyabe)
Cc: 6man Chairs; 6man WG
Subject: RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

Thanks
Suresh

----- Original Message -----
From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
To: Ole Troan <[email-masked]>, 6man WG <[email-masked]>
Cc: 6man Chairs <[email-masked]>
Sent: 11/21/2013 3:20 AM
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

Hi,
I support this draft: besides the operational value already mentioned, I can see all the cool things we would be able to do, to scale up the number of node on the link.

Broadcasting on the link is quite fine when you have a limited number of addresses to deal with, and the dynamic is low. But we plan for layer-2 networks much bigger and much more dynamic (industrial, datacenter, very large campus) and broadcasting + caching is creating a bottleneck.

I imagine we could also do routing with a cache instead of a table, and broadcast queries to find the destination prefix. Everybody would agree it does not scale. It's not just the numbers; it's also the dynamic.

I ran a simple math: 100,000 nodes, 3 addresses each, 10% of nodes moving every minute (moves can be physical or virtual), 3 multicast messages sent per move (DAD, NA, MLD), message size could go from 100B to 1KB (when using CGA for instance), that would range from 1 Mbit to 8 Mbit/sec.
Definitely an issue for the wireless links, but not only.
Last but not least, there is quite a bit of latency involved when looking for a target that is not in cache.

A cache is a good response to these problems, as long as the dynamic is low. But it's just a cache: when numbers grow, it can't keep up.  And it¹s not designed to be distributed.
Registration and dissemination (this draft, and sail-draft) propose a shift to a more pro-active approach, "a la" routing. Any node looking for an address on-link will either have it in its table (not cache) or will know who have it (that's the distribution part).
The critical piece is not just registration; it's also distribution so that the information is available quickly where it's needed, along the forwarding path.

There is a lot to clarify though: co-existence with the legacy model, distribution scheme (hierarchical, hash-based, Š), nature of the registrars (Routers? Switches? DHCP servers? Š).

Eric

---

From: Anders Brandt <[email-masked]>
Date: Mon, 25 Nov 2013 13:32:20 +0000

Thanks,
  Anders
 
> From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Tuesday, November 19, 2013 2:46 AM
> To: 6man WG
> Cc: 6man Chairs
> Subject: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04
> 
> All,
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 27 Nov 2013 14:20:50 +0000

Hello Lorenzo:

Multiple subjects : )

Let me break that down in threads.

Cheers,

Pascal

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: jeudi 21 novembre 2013 09:10
To: Pascal Thubert (pthubert)
Cc: Erik Kline; Ole Troan; 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

On Thu, Nov 21, 2013 at 3:40 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
So clearly, as we build a multilink subnet with 802.15.4 at the edge, we must place a router - called backbone router in ISA100.11a - between the .1 and the .15.4 links. You will note that even in that case, we need the registration mechanism to perform DAD - RFC 6775 was initially designed in that context -, and that proxy ND can be used at the backbone router, as discussed in the original ML subnet draft by Dave and Christian.

If you're routing, why do you need proxy ND? Just give the 802.15.4 network a separate /64 and run 6LoWPAN ND inside it.

I think that's when Erik says "merging two link types is not the solution", that's what he means. I think he's just suggesting that you use existing standard ND in the high-powered network and existing 6LowPAN ND in the low-power network, and just route between them. That way you don't have to define a new ND protocol.

Now, WiFi does not qualify as 'a different link type' that would require routing to Ethernet; on a same AP, some clients may be low power

Well, but isn't wifi fundamentally unsuited for low-power networks anyway? It's got beacons going all the time, it has multicast, etc.

We do not want to renumber each time a device re-associates to the next AP, so we care for a rather large subnet. And there, it is not just a problem of implementing multicast at layer 2 in a fashion  that serves solicited node mcast addresses, placing the burden on another layer that, as it goes, does not have the adapted support in place...

You don't have to change ND to do that. All you need to do is either use solicited-multicast node addresses over the multicast channel or, if the subnet is SO large that ND requests are overwhelming (but that seems like a LOT of ND traffic - how many clients do you need before this starts happening?), use MLDv2 snooping and send the NS packets L2 unicast to their destination.