On 08/31/10 02:10 AM, Robert Cragie wrote:
Would there be support for putting in 6lowpan-ND that you must send from
an address based on the EUI-64 instead of anticipated 16-bit address? I
think it is more consistent with what is already in 6lowpan-ND. Consider
the following:
What you are proposing is very different than how RFC 4861 and
6lowpan-nd works for NS and NA.
<RCC>NS and NA behave very differently for 6lowpan ND than RFC 4861 ND
with regard to address registration. I never really understood the
necessity to use NS for address registration; personally I preferred the
earlier NR/NC approach. NS/NA doesn't align with what's in RFC 4861
anyway. Whilst there isn't an equivalent of address registration, DAD
seems to be the closest function and this uses unspecified address as
the source address.</RCC>
If you'd like we can sit down and go over this in person at the next
IETF, or talk on the phone before then.
We don't currently have an address registration mechanism in an IETF
RFC. The closest there is would be the ISO ES-IS protocol, but that is
rather chatty (fixed period multicast packets sent by every host).
The DAD messages in 4861 are not a good fit either. Not only are they
multicast, and any response is multicast, but also there is no "ack"
message resulting in unreliable behavior if the medium has unknown
reliability. Thus 4861 DAD is fine for checking conflicting 64 bit IIDs
on reasonably reliable media, but when the probability of collisions
goes up and/or the packet loss probability goes up, then such an
approach isn't appropriate.
Currently NS and NA make a statement about the source address when
they include a SLLAO. But with your approach it is sometimes a
statement about the source address, and sometimes a statement about
the ARO registered address.
<RCC>Quite the contrary. The way it is written now the SLLAO makes a
statement about the registration address (which is also the unproven and
possibly duplicate source address) in the NS. In the proposal, the SLLAO
would always be consistent with the source address and not refer the ARO
registered address at all (if I understand the proposal correctly).</RCC>
There is no registered address field in the NS message with an ARO sent
by a host, thus in that case the SLLAO is about the IPv6 source address
of the NS. And the special NS messages sent from 6LR to 6LBR as part of
multihop DAD has an ARO which includes the registered address field, but
no SLLAO (section 8.2.3.).
I think this will lead to confusion, and result in corner cases that
are hard to handle.
<RCC>There is confusion currently amongst multiple vendors trying to do
interoperability testing with real products. I thought the IETF way was
to a) put out a specification, b) try it and c) change it if it doesn't
work. The process for (c) doesn't seem to be happening well for some
reason.</RCC>
My understanding of the IETF process is that your item c) is supposed to
read "improve the specification" instead of "change the specification" ;-)
And in fact you don't need any of that. All you seem to need to handle
your concerns is an "errors-to" MAC address, which the host might set
to its EUI-64 MAC address. (It could also be an "errors-to" IPv6
address like the LP64.) We can easily add such a field to the ARO.
<RCC>I disagree. Strictly speaking you should not be using that 16-bit
MAC address at all as a source or destination until you are convinced
that it is unique within the PAN. MAC association in 802.15.4 is built
around that principle. Perhaps we should be using that mechanism for
registration, although that would complicate matters by introducing
another management entity function when there seems to be a perfectly
acceptable alternative. On the other hand, if it were done using MAC
association, in 6lowpan (or indeed any network where the IP address is
autoconfigured from its IID (hence MAC address), the need for
independent address registration of IP addresses would probably go
away.</RCC>
I think I asked these question earlier, and saw no response.
What part of 802.15.4 breaks if we carry a 16-bit MAC address as an
SLLAO option in ND before it has been verified to be unique?
What part of 802.15.4 breaks if we use a 16-bit MAC address as a MAC
source address before it has been verified to be unique?
Note that in 6lowpan-nd-12 we only do the first of the two, and I can't
possibly see how the MAC layer can break as a result.
But having some packets, depending on option content, redefine the
IPv6 source address field as the "errors-to" field makes no sense to me.
Two examples of corner cases to worry about in the short term.
1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the
registered address is a GP16. In that case what should happen if
1a. There is no NCE for the LL64? (Should one be created?)
<RCC>I am assuming one isn't needed just as one isn't strictly needed
for RS/RA, which uses LL64. The LBR should not strictly have to maintain
state for the joining node for address registration purposes. The NCE
would be created when the successful NA comes back from the
authoritative 6LBR.</RCC>
Creating an NCE at that point in time has security issues, since we
don't have a hoplimit=255 check on the multihop DAD messages.
1b. There is an NCE for the LL64, but the stored mac address is
different than what is in the SLLAO. (Should it be updated?)
Those questions don't arise in 6lowpan-nd-12 because the NS only
applies to one address - the one in the IPv6 source field.
<RCC>There shouldn't be one. This would actually be end up being more
consistent as it means that NCEs only exist for the registered IPv6/MAC
address pair.</RCC>
In agree that in normal operation there shouldn't be one, but our goal
is presumably to create robust protocols that don't fall over and crash
just because something unusual happened.
2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In that
case, which addresses should be used for the SeND verification?
In 6lowpan-nd-12 the answer is simple since it is always the IPv6
source address.
<RCC>CGAs do not occur in 6lowpan (this is *6lowpan* ND we are talking
about here). If you really needed a CGA, you can add the option in for
the registered address.</RCC>
Thirty-odd years of experience with IP protocols has taught us that a
protocol is often applied outside of the context of the original design.
Thus I think our responsibility of designers is to have a slightly
longer time perspective than the products that people want to build this
year and next, and ensure that the architecture of the protocols allow
for future evolution.
I listed a few architectural disadvantages above. In addition this
causes more complexity in the implementation since an implementation
still has to handle NS and NA messages that do not contain an ARO, and
the rules for how such messages are processed will be different than
when the ARO is in place.
<RCC>In my opinion, it causes less complexity in that NCEs only exist
for addresses which will be used. The LL64 can be considered ephemeral
up to the point the registered address is acknowledged to be unique. As
for the other uses of NS in 6lowpan from RFC 4861, I think we need to
carefully go through them as it is not clear from the current draft
exactly when they would be used as 6lowpan ND is written as a kind of
'addendum' to RFC 4861.</RCC>
I don't think "complexity" and "memory consumption" is the same concept,
but ignoring that for the moment.
Can you explain to me how, in the "errors-to" proposal, there will be
NCEs for addresses which will not be used. The LP64 addresses will be
used for the RS/RA exchange will the 6LRs in both cases.
The ARO length is already overloaded to distinguish between multi-hop
DAD messages (which are disjoint for all other use of NS and NA) from
normal NS/NA.
Hence as 6lowpan-nd is currently written hosts can't send ARO with
length=4 since those have completely different semantics. That detail
could be fixed, but is an example of the confusion in this space.
<RCC>Multihop NS/NA will by necessity use IP addresses which have a
global/UL prefix. This distiguishes them.</RCC>
A host also sends NS to the 6LR for its global/UL prefixes, thus this
can't possibly be used to distinguish multihop DAD messages from the
normal AROs from the hosts.
What am I missing?
First of all, wouldn't you need the SRAM once the DAD has completed?
Second of all, I think the notion of a temporary NCE is needed to
avoid security issues (preventing an off-link attacker from creating
bogus NCEs - there is no ttl check on the multi-hop DAD messages to
protect against such attacks.)
<RCC>
Another kludge and why it is wrong to overload NS/NA in this way. There
are two solutions here:
1) Set ttl properly. This limits the attacker space to the same radius
as the 6LBR which in practice means inside the 6lowpan.
The security issue is with reception of packets sent by remote
attackers. I don't think we can assume that the attackers should set a
sufficiently small ttl so that there packets do not reach the 6lowpan ;-)
2) Create state for the NS/NA. This doesn't have to be a NCE, simply a
record of the corresponding NS. This would be a 'belt and braces'
approach on top of (1)
</RCC>
The amount of state you need to record is the same as the minimum amount
of state needed for an NCE.
So while I understand the problem you are trying to solve, the
proposed solution looks like it is making things a few orders of
magnitude worse than the problem you tried to solve.
<RCC>Like it or not, 6lowpan, 802.15.4 and the 'schizophrenic' MAC
address add complexity. The aim is surely to deal with these in L2/L3
management cleanly and not to violate the rules. L3 management has to
consider the properties of L2 addressing (if it is used); the use of
LLAOs throughout indicate the need to propagate L2 addresses into L3
managament. Quite simply, the use of a 16-bit MAC address before it has
been proven to the best of the network's ability to be unique should be
avoided, so deliberately specifying it like is done in nd-12 clearly
violates the requirement.</RCC>
See my questions about "use" above.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
