There is an explicit unjustified one-liner in 1812 (pg 34): A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address.
While it is clearly the intent of the security do-gooders to avoid arp cache pollution as a dos tool, there is a vast difference between 'SHOULD NOT do this without explicit intent', and 'MUST NOT do this'. As you point out there are cases where multicast over unicast makes sense, and there are cases where IP-anycast over multicast link layer make sense for load sharing. Unfortunately, the line above ends up as the basis for declarations that the types have to match. Tony > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Fred L. Templin > Sent: Wednesday, February 12, 2003 9:56 AM > To: Francis Dupont > Cc: Pekka Nikander; IPV6 WG; SEND WG > Subject: Re: Reason for the explicit link-layer address options in ND? > > > Francis Dupont wrote: > > 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. > > Can you point me to the text that forbids this? I was under > the impression that multicast emulation mechanisms (e.g. > MARS, etc.) use unicast link-layer destination addresses when > the IPv6 destination is multicast. The whole point of > multicast emulation is to propagate network-layer multicasts > over unicast-only link layers - not true? > > Thanks, > > Fred > [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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
