In your previous mail you wrote: Is this just a layering question, an attempt to avoid layer violations? Or were there behind other goals, like allowing proxy ND? => both reasons. In the same kind of design ideas, it is forbidden to mix unicast and multicast between layers, i.e., if the IPv6 destination is unicast, the link-layer destination MUST be unicast, and same with multicast in place of unicast.
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. => this problem is the same than creating a secure binding between a DNS name and an IP address (i.e., the DNSSEC one). 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). => I stronly disagree: CGAs are very different: they don't provide authentication, only ownership. And there is a third way, Key-Based Addresses (KBA), i.e., the opposite of CGAs. 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. => I don't understand your problem: with public keys you can sign NAs so secure the IPv6 to link-layer address binding. To secure the reverse binding we can reuse inverse ND (RFC 3122). So the only issue (:-) is the public key distribution... Regards [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] --------------------------------------------------------------------
