Hi Fernando,
On Fri, 24 Jun 2011 00:17:01 -0300 Fernando Gont <ferna...@gont.com.ar> wrote: > On 06/22/2011 08:34 AM, Mark Smith wrote: > > >> I think it is a bit ironic that if a L2 device has to parse all extension > >> headers, that then L2 switching of IPv6 packets will be more expensive that > >> L3 routing them. > > > > It may be getting to the point where it'd probably be easier > > to address these issues by taking away hosts' ability to multicast to > > other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke > > mode of LAN operation, allowing the designated routers to also act as > > traffic sanitisers for on-link inter-host traffic. > > Two comments: > > * Hosts would still need to multicast RSs Yes, but the layer 2 device only delivers those multicast RSes to ports that it has been told are attached to authorised routers. > * This does nto prevent attackers from sending ND packets *unicast* to > their victims. > Actually it can. Have a look at the following - http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01 The layer 3 hub-and-spoke forwarding topology described can also be and is likely to also be enforced at layer 2, by preventing layer 2 forwarding of traffic between designated host ports, limiting it to host port to router port, or router port to host port. It's interesting to look back on where we've come from. On simple 10BASE2 and earlier Ethernet, broadcast/multicast was cheap, because it was the inherent nature of it's bus topology. After we moved to bridges/switches with individual devices attached to each port, this broadcast/multicast capability had to be actively emulated, because a star topology does not have a natural broadcast/multicast capability. Implementing hub-and-spoke forwarding paths in a bridge/switch is not much more than reducing the requirement to emulate something that fundamentally wasn't natural in the first place. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
