Thanks, Jim and Francis, for your timely answers to my
question. Yes, like Jari pointed out, we are working
on using IPsec for SEND, and we need to understand ND
better to make it *right*. However, that discussion
belongs to the very silent SEND mailing list, and should
be continued only there, IMHO. (I've inserted Reply-To:
headers to facilitate that...)
Now, the ND specs as such are clear. No problem with
that. It is just that the design rationale behind the
specs in not written anywhere (as usual), and that was
the reason for asking my question. We are not attempting
to redefine or even revise the ND architecture, we are
attempting to understand it fully so that we can design
proper security for it.
Now, if I read correctly what you Jim and Francis are saying,
there seems to be a number of reasons for the design.
Please correct me if I get this wrong; I am rewriting what
I read to see if I understand it correctly.
1. Architecture
It was deemed architecturally good to place ND
at the IP/ICMP layer rather than below it. The
main benefits from this are the following:
- allows extension headers to be used
- allows IPsec protection for ND
- allows using routing and destination options
2. Implementation
Early implementation experience showed that as
a consequence of the design, implementation becomes
simpler. In particular, NUD and prefix assimilation
become part of the IP layer.
I have one further question about that: what do
you mean with prefix assimilation? I didn't find
the term in RFC2461 or RFC2462.
The reasons for the link layer address options were
the following:
3. Extensibility (with extension headers etc).
This seems to be a direct consequence of the
architectural design decision.
4. Support for future functionality like proxy ND
Again, this seems to follow the architectural
principle layed out above.
5. Better support for the Override bit
Now, I have a question about the Override bit.
I didn't quite understand how it could be used
for "node discovery during first phase when
link-layer addresses are not shared".
What did you mean with that, Jim?
Finally, the reasons for not peeking at the actual
link layer addresses used in the link layer frame can
be summarized as follows:
6. Separation of function
This again follows the architectural principle.
Especially, it was viewed that checking the
link-layer addresses is a link layer function,
and it should be separate from the IP layer.
Is that all or am I missing something? Or is there
something above that doesn't belong there?
Now, if you want to discuss how security fits in this
all, may I suggest that we do it on the SEND list?
(Personally I have trouble in keeping track with
the IPv6 list volume, as I have also other things
to do but participate to the IETF work.)
--Pekka Nikander
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
