Re: [6lowpan] #87: GP16 as source address in initial NS

[Dario Tedeschi]

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? 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 >From Section 3: o Duplicate Address Detection (DAD) is used for preventing address collisions [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. Also important is the section on "CGA Generation" (section 4 in RFC3972). Particularly the text for step 8. As for an alternative approach, I was thinking that the ARO would contain the address being registered and the source address would be one already confirmed and assigned to the interface. Yes, this means that the source address would probably be the EUI-64 based link-local address (at least for the first address registration). I'm no cryptographic expert, but having read a bit on the CGA process, it does seem possible that this approach would still work in SeND. The difference being that for 6LoWPAN, the new address would go in the ARO instead of the target-address field of the NS. From what I understand from SeND (correct me if I wrong), the CGA option is there to authenticate the source address not to authenticate an address going through the DAD process. Regards Dario

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan