Hi Pekka, I can give you one answer and recall the discussion very well in Cambridge MA well at an early interim IPng WG meeting (~1995) and this is where we agreed to solicited node mulitcast archictecture principle, as a note too.
For Neighbor Discovery (ND) RFC 2461: IPv4 and OSI too and many other previous implementations of a Internet like network paradigm relied on address resoluton and node discovery at the link layer of the network stack in conjunction with peeking at the link layer (e.g. ARP, ES-IS, Novell IPX). With IPv6 the ICMP Layer, Router Redirects, and ARP-Like funcitons were brought up to be part of the IP layer processing, which is one of the clear advantages of IPv6 IMO that we often don't tout (though steve brings this point out in his masters and other talks). There is an architecture and implementation reason. Architecturally this affords ND to be part of the IP(v6) layer and part of the extensibility of that architecture as required (e.g. new ICMP types, Routing Options, Destination Options). This can be seen from the DNS Discovery deliberation and suggestion to use new ICMP type for finding ones DNS server on a stateless network. It can be seen in Next Header chain. With ARP or ES-IS this was not possible. In those archictectures the address resolution and node discovery are disjoint from the actual "virtual" layer 3 processing. >From implementation perspective it supports the principle of cohesiveness when building the network subsystem. What this means is that the code points for IP processing are now integral to the ND methods and concepts like NUD and prefix assimilation from ND are now part of the IP stack code base. NUD and prefix assimilation (just two examples as a note) are part of ND architecture and support that principle. The "implementors" of IPv6 and SIP (initial predecessor to IPv6 and IPng choice) learned the implementation advantages of ND methods and its place in the IPv6 architecture over implementations they had done for ARP and ES-IS. So it was a win for the Architecture, Implemenation, and combined the best from multiple methods previously done for address resolution, node discovery, and router redirects. The last win was only possible by integrating into the the IP layer. IPv6 Stateless Autoconfiguration RFC 2462. This just adhered to the base packet types of ND and then added the processes. The reason the link layer addresses are options was to permit extensibility for ND and Autoconfig to be extensible to the win list above of which address resolution and node discovery were only part. Another reason is support future models for proxy and passing link-layer addresses to those node (e.g. Mobile IPv6 HA proxy). Another reason was to support the use of the Override bit which can be part of address resolution and node discovery during first phase when link-layer addresses are not shared or to inform implementation this is temporary do not update your NUD cache. The reason for not peeking at the link layer in ND or Autoconfig is separation of function within the IP architecture. There is no requirement for this in previous models like ARP and ES-IS. If you look at public domain network kernel implementations of BSD or Linux derivations you will see the Ether (*) routines exist and for multiple adapter types. Also you might want to look at the various IPv6 over Foo specs that deal with how to deal with different link layer types. The check with the link-layer is a link layer function not an IP layer issue. In fact it is done on most implementations before the packet comes off the interrupt queue to hit the IP layer. Lastly if there is a bug here it would be caught in the NUD state machine and time out. Regards, /jim >-----Original Message----- >From: Pekka Nikander [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, February 12, 2003 8:43 AM >To: IPV6 WG >Cc: SEND WG >Subject: Reason for the explicit link-layer address options in ND? > > >On the behalf of the SEND DT, I'd like to get >a clarification to the current ND design from >those who were around back when RFC2461 and >RFC2462 were written. > >Specifically, we'd like the know the exact >reasons why RFC2461 uses separate source/target link >layer address options instead of relying on the >actual source link layer addresses used in the >link layer frame? Furthermore, why are the actual >link layer addresses used in the link layer frame >completely ignored, and not checked to match with >the options? > >Is this just a layering question, an attempt to >avoid layer violations? Or were there behind >other goals, like allowing proxy ND? > >The reason why I am asking this is that the current >situation makes security design tricky. That is, >the Secure ND part of SEND (as opposed to Secure RD) >is all about creating a secure binding between an IP >address and a link layer address. > >The WG decided to pursue the idea of using public >key based AH to secure the NA (and NS) messages. >That requires that the hosts learn the public keys >of the other hosts on the local link. Basically, >there are two know methods for distributing the >public keys: Using certificates and relying on >a (local) CA, or using Cryptographically Generated >Addresses (CGA). > >Now, for zero-config operation, we would like to >use the CGA ideas. Furthermore, there is a possible >attack against link local addresses, and that attack >can be partially dwarfed if we bind both the link >layer address and the public key to the IP address >in CGA. > >Under the current design, the CGA processing at the >AH layer becomes very tricky, if we attempt to include >the link layer address into the CGA process. > >--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] >-------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
