Dave Thaler writes: 
The biggest problem with this document is that the coexistence mechanism
appears to be fundamentally flawed (see comments on section 10).

11) Section 10:
   > operate as two separate logical links, and packets between a secure
   > and insecure node always go through the router.

This is actually false (at least as currently specified), and I'm
worried that this whole section (and perhaps others) may be completely
broken as a result.  Specifically, multicast packets sent from a node
will not go through the router.  The model is especially broken when
there are applications/protocols using link-scoped groups (e.g.,
LLMNR).  Nodes may exchange link-local addresses which then cannot be
used in unicast communication.  Put another way, nodes can send
packets which appear to leave the scope of the unicast address, since
a packet received can have a link-local source address from a separate
logical link.  This violates the Addressing Architecture RFC.

If there is some way of fixing this, ensuring that even link-scoped
multicast groups are disjoint, then I believe the reason to have a
separate solicited-node range completely goes away, and the protocol
becomes much simpler.

12) Section 10.1:
   > One effect of this is that secure hosts can not communicate with
   > insecure hosts using link-local addresses, and vice versa.

Another false statement (as currently specified).  See above.

   > The above rules require secure nodes to ignore all insecure Neighbor
   > and Router Discovery messages, and all insecure nodes to ignore all

This statement contradicts section 10.1 that describes how to respond
to (not ignore) insecure solicitations.

--------------

Jari Arkko responds to Dave Thaler:

>    can have a link-local source address from a separate logical link.
>    This violates the Addressing Architecture RFC.

I think I see the problem. Yes, this is serious for the
co-existence functionality. Thanks for noting this.

>    If there is some way of fixing this, ensuring that even link-scoped
>    multicast groups are disjoint, then I believe the reason to have
>    a separate solicited-node range completely goes away, and the protocol
>    becomes much simpler.

Hmm... to me, it seems rather hard to invent a way to have disjoint
multicast groups. Sending to a multicast destination does not appear
to require any ND operations, so its hard to see how SEND could intervene
and assign different addresses. But I'm not a multicast expert, so
perhaps you have some ideas? Maybe a new link-local multicast address
range? But what would be the impacts of that.

In any case, if you look at draft-arkko-send-ndopt-00.txt (to appear, see
http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.txt)
there's a very different co-existence mode. Basically, I gave up with
the two-logical link approach and simply added application-level policies
for deciding when SEND-nodes can accept plain ND, and plain ND nodes
always accept all SEND messages. I think this would solve your
problem as well.

--------------

--------------