On 07/27/10 10:09 AM, Dario Tedeschi wrote:
Hi Erik
Thanks for your comments. Please see my comments below.
Erik Nordmark wrote:
On 07/25/10 02:37 PM, Erik Nordmark wrote:
It has been suggested that the NA must be sent directly to the SLLA,
and
that most IPv6 layers allow for explicitly directing a packet to a
given
MAC address (even when an NCE for a packet's destination address is
pointing elsewhere). However, a couple of well-known stacks I've had a
look at don't seem to support this without a bit of hacking or
tricks in
the network-interface driver.
I don't see any other path forward than getting those IPv6 stacks
improved to allow for sending to a link-layer address.
Do you have a working alternative approach?
The above was answered in the WG meeting, which was to include the
EUI-64-based (link-local? or global?) in the ARO and use that for a
response.
It sounds like the source address is now being placed in the ARO. Is
this the case or is the new address (an address requiring
registration/DAD) being placed inside the ARO?
With my suggestion the "address to which you send errors" would be in
the ARO. The "registered address" would be in IPv6 source address field.
But I think we have a simpler way to handle the whole issue which is to
reintroduce the tentative Neighbor Cache entries we had in nd-10.
If we want to use the EUI-64 based link-local then we could
potentially hack things and just form that based on the EUI-64 in the
ARO (by prepending fe80:: to the EUI-64). But it might be cleaner to
expand the ARO to have an address instead of just the EUI-64.
AFAICT if we keep the IPv6 source in the NS as the one for which we
register we don't need any special handling for SeND. In essence the
above idea would add a "send ack/nack to this address".
I'm not very familiar with SeND, but having had a quick search for
"source address" and "duplicate" in RFC3971, I came across two
paragraphs for CGA
We are not using the DAD mechanism in 4861/62 hence the text about DAD
in 3971 doesn't apply either.
From Section 3:
o Duplicate Address Detection (DAD) is used for preventing address
collisions [5 <http://tools.ietf.org/html/rfc3971#ref-5>]: for
instance, during Address Autoconfiguration. A
node that intends to assign a new address to one of its interfaces
first runs the DAD procedure to verify that no other node is using
the same address. As the rules forbid the use of an address until
it has been found unique, no higher layer traffic is possible
until this procedure has been completed. Thus, preventing attacks
against DAD can help ensure the availability of communications for
the node in question.
From Section 5.1.1:
Neighbor Solicitation
The address MUST be the Target Address for solicitations sent for
Duplicate Address Detection; otherwise it MUST be the source
address of the message.
It seems the source address can't be an address that has not been
confirmed by DAD. In 6LoWPAN ND, DAD is achieved through the
registration process so I would expect that it should follow the same rules.
Why must we follow the rules associated with the 4861/62 DAD when we are
not using any of that?
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
