On 08/31/10 01:21 AM, Colin O'Flynn wrote:
Hi Erik,
Thanks for looking through my proposal& commenting. I think a lot of the
problems come from my original e-mail/proposal not being clear enough, or
mixing possible implementation-specific optimizations with what the general
case I saw was. Let me try to clarify some of those:
Sorry for the delay - too many things going on.
. 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.
Not sure I understand that one. If the SLLAO is included, the LLAO has the
address associated with the IPv6 source address is all I assume. The ARO
registered address is ALWAYS the address which you wish the 6lowpan-ND
action on (register, re-register, etc).
So in your proposal the IPv6 source address in the packet should be
completely ignored (when there is an ARO) except for the case when an
error needs to be sent back?
That would be a fairly radical change to 4861.
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?)
6lowpan-nd-12 already has this if I'm reading your e-mail correctly. Section
5.2 Interface Initialization says that:
A link-local address is formed based on
the EUI-64 assigned to the interface, and then the host sends Router
Solicitation messages as described in [RFC4861] Section 6.3.7.
Hence the router may have already created a NC entry if it is using standard
ND. In my suggestion it's up to implementers HOW the deal with routing the
NA response back. They may use a normal NC, they may use a special NC that
only stores entries from NS, or they may fake it out by sending to the
EUI-64 of the ARO if their specific network design allows such faking.
6lowpan-nd-12 doesn't have the issue I tried to point out. For
6lowpan-nd-12 the NCE associated with the sender of a NS (and hence the
SLLAO) is always looked up based on IPv6 source field. No exceptions.
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?)
My understanding is standard ND processing would deal with this. When the NS
(or anything else) was sent from the LL64, the SLLAO would always point to
the correct mac address to use. Which will for efficiency reasons always be
the EUI-64 in 6LoWPAN networks.
Question is really to what degree you envisioned changing 4861. Omitting
looking for an NCE based on the IPv6 source field would be a radical
change. Looking for an NCE based on the IPv6 source field, and then
separately looking for an NCE based on the registered address would at
least be inefficient, and seems a bit complex.
2. Apply ARO to CGA addresses and Secure Neighbor Discovery.
Not sure on this one. I've never implemented SeND so don't know about
resource requirements, is it something which could be implemented on the
type of nodes we are looking to run 6lowpan-ND on?
The decades of history we have for IETF protocols indicates that the
hardware capabilities evolve a lot faster than the protocols, and that
successful protocols often get applied outside of their initial indented
domain.
Thus I wouldn't be surprised if the optimizations provided by 6lowpan-nd
would be applied in contexts where people would also like to use SeND.
But I don't have a good response to that concern, AFAIK my proposal isn't
cleanly compatible with SeND.
. 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
Huh? How is this different from 6lowpan-ND currently? In fact I thought it
even easier, as the processing only needs to check the EUI-64, and generally
keeps processing of messages more streamlined.
The difference is that currently the processing of an ARO is localized.
The base NS/NA header is processed, and then each option is processed
independently.
With your proposal it seems like the processing of the base NS/NA header
needs to be different whether or not an ARO is present, which would be a
departure from how we currently try to manage complexity in RFC 4861.
These observations are at least based on how I've implemented 6lowpan-ND.
Perhaps I'm missing very obvious optimizations in ND-12, but from my
perspective of someone who has written a 6lowpan-ND implementation, the
proposed changes would be considerably easier.
While that might be the case for a minimal implementation, I don't think
that is true as you look at all of ND. If we think that ND will continue
to be carefully extended, then SeND becomes merely one example of where
redefining the semantics of the IPv6 source address for NS/NA will cause
issues.
The ARO length is already overloaded to distinguish between multi-hop
DAD messages
My proposal moves to distinguishing based on the src/dest IP addresses.
Multi-hop uses global IP addresses, everything else uses link-local.
Since I missed that, I suspect it would be far too subtle.
In any case, the currently length distinction is a source of continued
confusion and complexity. I think we actually need to split out the
multihop DAD messages as I indicated in an email a few weeks back.
First of all, wouldn't you need the SRAM once the DAD has completed?
It was more that you could get away without a NC at all in the intermediate
6LR. Again this isn't required in the general case, but if using for example
RPL on top you could get away without a NC on the 6LRs.
I don't understand unless you have RPL and no hosts.
The 1st hop router needs to track the (successfully) registered hosts,
which means an NCE for each of them.
Intermediate 6LRs don't necessarily need to track them. But this has
nothing to do with what happens when there is a duplicate AFICT.
Second of all, I think the notion of a temporary NCE is needed to avoid
security issues
Hmm good point. That would require changes to my proposal, either:
-Include the temporary NCE again
-On receiving a NA, check if the IPv6 address you will send to based on the
EUI-64 is already in your NC. It should be in the NC as you received a NS
from it. This basically uses the LL64 as the temporary NCE.
I think that still allows a remote attacker to create bogus
registrations by sending the multihop NAs; the attacker just need to
know the EUI-64.
-Include something like a nonce in the reserved space of the ARO. This is
less in line with current 6lowpan-ND so probably not worth the hassle.
To check the nonce you'd need to remember which one you used. Hence you
need state. And since you probably don't want the nonce to be easy to
guess it makes sense having a difference nonce per IP address; thus it
ends up looking like a temporary NCE.
How
does it relate to the overall goal of making 6lowpan compact, simple,
and sufficient to handle 6lowpans.
It would cleanly allow extensions to 6lowpan-ND that could do the following
(if someone later wanted to):
* Have the 6LBR tell you a better short address to use instead of the one
you picked. If the network is packed, maybe it's better than the guess&
check method.
If that flexibility is needed, then I suggest that DHCPv6 is the best
approach.
* Would let the 6LBR tell a node which is re-registering what his old short
address was.
Why would the node forget the old short address?
And again, sounds like DHCPv6.
I don't mean we will add them to 6lowpan-ND immediately. But these are
things I could see being useful, and having the protocol designed such that
the EUI-64 and NOT the registered address is used to uniquely identify the
NS sender makes sense to me.
Thus for robustness all messages that contain the ARO must be able to
function whether or not the 6LR has an NCE
My message probably wasn't clear, as I didn't mean in the general case you
can remove the SLLAO. Just that in specific implementations, it would give
them the flexibility to remove the SLLAO as they KNOW the same information
is carried in e.g. the EUI-64. But I probably shouldn't have mixed
implementation-specific optimizations and the general case.
Introducing an "errors-to" field in the ARO (either as a MAC address or
an IP address) solves the problem
One of the problems I was looking to solve is with people using "standard"
stacks. Such stacks had trouble sending a packet to a destination IPv6
address that was in the neighbor cache, BUT the mac address was something
different. Thus it should be an IP address that the "error-to" is.
I don't see a problem with it being an IPv6 address. It makes the
formatting of the option simpler, even if it becomes a bit larger.
To save space though it would be better if the error-to was just a MAC
address& you auto-configure the IPv6 address based on this. Or if the
error-to is the LL64. After all the RS should have come from the LL64, so
presumably you have an entry in your NC for the LL64 of that node.
If we want the semantics of it being an IPv6 address, then anything that
is more compressed is in essence a form of header compression. I don't
think it makes too much sense to think of header compression one field
at a time; if we need it shouldn't we look more generally at all the
NS/NA content?
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
