Hi Colin
I think that what you're getting at is that an external operation could
be used to determine whether an address is on-link. Once an address is
determined to be on-link, RFC 4861 allows to look it up, even if the PIO
indicates that the prefix is not known to be on-link ('L' bit is reset).
RFC 4861 :
'
Prefix Information options that have the "on-link" (L) flag set
indicate a prefix identifying a range of addresses that should be
considered on-link. Note, however, that a Prefix Information option
with the on-link flag set to zero conveys no information concerning
on-link determination and MUST NOT be interpreted to mean that
addresses covered by the prefix are off-link.
'
I'm still not in agreement with:
ND-15
'
A router MUST NOT set the 'L' (on-link) flag in the Prefix
Information options, since that might trigger hosts to send multicast
Neighbor Solicitations.
'
Which amongst other things indicates that multicast NS is always evil,
and thus seems to prohibit looking up an address that is determined to
be on link. When the link is 1 radio hop (route over), the operation is
not that evil, and is in fact a very good idea if there is an external
indication that the target is actually on-link.
Pascal
http://www.xtranormal.com/watch/7011357/
> -----Original Message-----
> From: Colin O'Flynn [mailto:[email protected]]
> Sent: Thursday, March 10, 2011 8:09 AM
> To: 'Stok, Peter van der'; Pascal Thubert (pthubert)
> Cc: '6lowpan 6lowpan'
> Subject: RE: [6lowpan] nd-15 for isolated network
>
> Just as another point: nothing stops another protocol (the mesh
protocol,
> etc) from either populating the neighbor table, or defining additional
address
> resolution strategies for 6LN.
>
> So I don't think 6lowpan-nd is broken. It just may not provide all the
features
> some are expecting, but doesn't stop a future extension or protocol
from
> providing those features.
>
> Regards,
>
> -Colin
>
> -----Original Message-----
> From: Stok, Peter van der [mailto:[email protected]]
> Sent: March 9, 2011 8:40 AM
> To: Colin O'Flynn; 'Pascal Thubert (pthubert)'
> Cc: '6lowpan 6lowpan'
> Subject: RE: [6lowpan] nd-15 for isolated network
>
> Thanks Colin for your reaction, given your summary I like to show my
> support.
>
> >>
> "It would be good to have some confirmation from the authors to ensure
I'm
> not just being stupid, something we can never rule out ;-)"
> --I feel exactly the same.
> <<
>
> >>
> "This is a limitation of the 6lowpan-nd draft, if I am reading this
correctly. I'm
> not trying to argue for or against such a limitation, just everyone
should be
> aware of it, and if this is not acceptable look for a solution."
> -- I would like to see a solution as it generates unwanted overhead <<
>
> peter
>
> -----Original Message-----
> From: Colin O'Flynn [mailto:[email protected]]
> Sent: Tuesday 8 March 2011 18:20
> To: 'Pascal Thubert (pthubert)'; Stok, Peter van der
> Cc: '6lowpan 6lowpan'
> Subject: RE: [6lowpan] nd-15 for isolated network
>
> Hello,
>
> <Pascal> I'm sure you mean addresses that are formed using a
link-layer
> address, not just Link Local. More in section 5.7 </Pascal>
>
> Yes of course! I guess though what I really meant is that according to
the
> draft, save for the 6LR(s) address(es), a link-local address based on
the
> EUI-64 is the only address a 6LN could send to directly.
>
> This is a limitation of the 6lowpan-nd draft, if I am reading this
correctly. I'm
> not trying to argue for or against such a limitation, just everyone
should be
> aware of it, and if this is not acceptable look for a solution.
>
> It would be good to have some confirmation from the authors to ensure
I'm
> not just being stupid, something we can never rule out ;-)
>
> Regards,
>
> -Colin O'Flynn
>
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email protected]]
> Sent: March 8, 2011 2:03 PM
> To: [email protected]; Stok, Peter van der
> Cc: 6lowpan 6lowpan
> Subject: RE: [6lowpan] nd-15 for isolated network
>
> Hi:
>
> <Colin>
> The link-local address based on EUI-64 can always be mapped directly
to a L2
> address. This is a special case, no other address can be mapped that
way
> according to the spec.
> </Colin>
>
>
> <Pascal> I'm sure you mean addresses that are formed using a
link-layer
> address, not just Link Local. More in section 5.7 </Pascal>
>
>
> <Peter> In the applications I am involved, the bulk (say >90%) will be
> messages > to one hop neighbors and possibly two-hop neighbors.
> Actually, I expect that the quality of the link between source and
destination
> can be better than the link quality between source and 6LBR.
> (people may argue that this is bad network engineering, but given
costs and
> knowledge today it looks a very probable situation) </Peter>
>
>
> <Pascal> What's more troubling for Peter's point about 1-hop
neighbors is in
> 6.1:
> "
> A router MUST NOT set the 'L' (on-link) flag in the Prefix
> Information options, since that might trigger hosts to send
multicast
> Neighbor Solicitations.
> "
> This text prevents a node from checking whether another node is
visible at
> L2. I think that this recent addition is a mistake. Though clearly
costly on a
> mesh under, this could be reasonable in some route over cases, as long
as
> the multicast is not forwarded.
>
> What this spec should mandate is whether and how to enforce the
> registration for a given prefix as opposed to classical ND. The 'L'
bit does not
> say that. We need a new bit.
> </Pascal>
>
> Cheers,
>
> Pascal
>
>
> The information contained in this message may be confidential and
legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
notified
> that any use, forwarding, dissemination, or reproduction of this
message is
> strictly prohibited and may be unlawful. If you are not the intended
recipient,
> please contact the sender by return e-mail and destroy all copies of
the
> original message.
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
