[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 broadband provisioning
On Fri, 28 Dec 2007 17:55:04 +0100
Gert Doering <gert@space.net> wrote:
> Hi,
>
> On Fri, Dec 28, 2007 at 01:58:27PM +0100, Iljitsch van Beijnum wrote:
> > The first device under the control of the ISP, or at least a device
> > very low in the aggregation hierarchy, to intercepts router
> > advertisements from the ISP's IPv6 router and slightly modifies them:
> > it basically injects some bits that are particular to the customer/
> > line, so that every customer sees RAs with a prefix unique to them.
>
> I see your proposal as a solution to the problem space "multiple customers
> share a single layer 3 segment".
>
> In our network, this is basically a non-problem - every customer has their
> own routed layer 3 segment, gets their own /48 (or /56), and the ingress
> router will do proper IPv6 uRPF (eventually).
>
> We are not a cable modem operator (where a large and shared broadcast domain
> is unavoidable), but as far as I understand, for those networks the cable
> modem is always provided and provisioned by the operator? If yes, they
> shouldn't have a problem here either.
>
> Another problem area might be large-scale DSL where customers are not
> terminated by PPPoE/L2TP, but sort of "all of them bridged together" - here
> your approach might make sense. But then - if you have a device that
> needs to understand enough IPv6 to modify RAs and filter incoming packets
> accordingly, why not move IPv6 routing functionality all the way to that
> device, and go back to the "one customer, one L3 segment" model?
>
I see some value in having the customer's routing CPE "all bridged
together". In my employer's DSL environment, our exchange located DSL
equiment is "bridged" together using ethernet switches, with a backhaul
layer 2 link to the offsite layer 3 infrastructure. It would be ideal
if inter-subscriber IPv6 traffic between subscribers attached to the same
exchange stayed in the exchange. In a routed IPv6 CPE environment, with
prefixes delegated to the CPE via DHCP-PD, that means that the ethernet
segment in the exchange mostly becomes a link interconnecting routers.
In the past, to get optimal routing, all the routers would participate
in an IGP. In this DSL subscriber environment that wouldn't be possible
because we couldn't trust the customers to not inject prefixes they
shouldn't (we don't manage the CPE).
An alternative I've been thinking about is ICMPv6 "network redirects".
The upstream DHCP-PD delegating router is aware of all the prefixes
that the downstream CPE routes for. The downstream CPE default to the
upstream DHCP-PD delegating router. When the upstream delegating router
knows that it's being asked to route between two downstream prefixes,
it sends a ICMPv6 "network redirect" for the target prefix to the
traffic source CPE. That causes the traffic source CPE to send the
traffic direct to it's CPE peer, rather than via the upstream and
offsite delegating default router. The ICMPv6 network redirect might
timeout after a period, or use something like dead gateway detection to
ensure this redirect information continues to be valid.
If a subscriber plugged a host directly into this subnet, learning it's
prefixes via RAs, I think that could also process these ICMPv6 network
redirects.
While certainly not as efficient as having the downstream CPE being
fully aware of the routing topology, this method would save having a
resonable amount of traffic double traverse the more expensive backhaul
links - traffic staying within an exchange is essentially free. There's
an ICMPv6 "network redirect" spoofing risk, however I think there are a
few ways that could be mitigated that are similar to methods used today
to mitigate ARP & DHCP spoofing on DSL bridged networks.
Regards,
Mark.