In nd-10 and nd-11 the multi-hop DAD functionality uses special forms of
NS/NA, and those special forms must not cause normal ND processing since
it is not subject to the ttl=255 verification (hence off-link senders
can inject spoofed multi-hop DAD messages.) Basically those messages
only interact with the DAD table in the 6LBR.
This means that it would be useful to be able to specify firewall rules
that can block the multi-hop DAD messages. However, the awkward way we
ended up specifying these messages makes this very hard. Basically a
multi-hop DAD message is defined as a NS or NA which contains an ARO
option of length=4, requiring to parse the options to see whether the
message has normal NS/NA semantics or the special multi-hop DAD semantics.
It would be a lot easier for a firewall to filter them out if we instead
use a separate ICMP type for these multi-hop DAD messages.
I think an implementation would be simpler in that case too, since it
allows the implementation to uniformly do the TTL check for all NS/ND
and doesn't need to track the "special" ones throughout the code.
If folks have specific implementation feedback on the multi-hop DAD in
nd-10 I'd be interested in finding out; either on the mailing list or in
person in Maastricht.
*If* we want to change this I think the changes are quite minor:
- We need a new ICMP type for the multi-hop DAD message.
- We can use the ICMP code field to specify request (code=0) and reply
(code=1) *or* have a separate ICMP type for the request and reply
- We no longer need the Registered Address field in the ARO option
since we instead can use the target address in the multi-hop DAD
message. This makes the multi-hop DAD messages 16 bytes smaller.
- Since the name of the address is now "target address" it probably
makes sense to use TLLAO instead of SLLAO i.e., a change in the
option type number we use with the multi-hop DAD messages.
---
Thus a multi-hop DAD message would look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD4 | Code = 0/1 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Followed by an ARO option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| EUI-64 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... and a TLLA option:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---
Comments?
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
