On Thu, 26 Aug 2010 09:20:45 -0400 Thomas Narten <nar...@us.ibm.com> wrote:
> Suresh, > > Suresh Krishnan <suresh.krish...@ericsson.com> writes: > > > The nodes attached to different subscriber lines cannot directly send > > packets to each other. They need to talk through the edge router. > > How is this enforced? If I happen to know the mac address of my > neighbor's router (or host), can't I just send stuff directly? > > If I happen to send bogus NAs to my neighbor, does the architecture > prevent this? > > > All traffic needs to go through the edge router. There is no direct > > host-to-host communication allowed between different subscriber > > lines. > > Will edge routers send redirects when "neighbors" are sending traffic > to each other? Or will the Edge Router become a performance bottleneck > when lots of traffic going through it is sent right back out on its > incoming interface? > The only reason to hair pin traffic through the edge router is so that the edge router can act as a policy enforcement point or billing point. While a lot of SPs would want that, others may not - with one reason being that if the edge router is geographically remote (as is commonly the case here in .au), then backhaul bandwidth between the ANs and the Edge Router has to be provisioned for this inter-customer traffic. SPs may consider this traffic trivial enough that it only wants to bill for traffic entering or leaving the aggregation network via the edge router, ignoring traffic that stays within it. I think this scenario also creates a need for a prefix-redirect, where the edge-router, fully aware of the prefixes residing behind the customer's Residential Gateways, can send a prefix redirect directing one RG that it is a link layer peer of the RG that the prefix covering the destination it is trying to reach, and therefore it can send traffic directly to the RG. There'd be some security issues to address, however ANs are already performing a lot of "layer violation" traffic inspection and policy enforcement, so I think it's unlikely that these additional mechanisms would be much of a burden. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------