Jim,
The IKE UDP issue is only an implementation issue the spec works. We have known this about manual keying since the beginnning. IPsec will work and with IKE.
Yes, the manual keying issue is mostly implementation, or rather configuration.
But the IKE issue is more fundamental than just implementation. For one, Neighbor Discovery uses multicast extensively and IKE of course only handles unicast. So from the start we can't really use dynamic keying for all of ND. Furthermore, even if you would ignore multicast, some chicken-and-egg problems remain. For instance, assume that we need to talk to a peer, and do address resolution first. If all unicast traffic between the two peers is expected to be secured, this would imply that a solicited NA would have to be secured as well. But in order to secure the NA, we would need IKE to send IP packets to the peer, which in turn would require us to see the NA first, right? So it doesn't really work as of now.
Exactly, so that's why SEND is actually trying to use IPsec
and Pekka is asking clarifications on why certain things are like they are in ND. We are working on the problems mentioned above. Work still remains, as you can see one of the issues we are thinking about is the relevance of link layer addresses and what
checks are necessary or possible.
Clarification is good. Was the spec not clear?
I think we now have gotten more information on the role of the link-layer addresses in ND and why they are not checked. Thanks. I'm personally leaning towards leaving link-layer address checks away from SEND. Jari -------------------------------------------------------------------- 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] --------------------------------------------------------------------
