[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 broadband provisioning

On 28 dec 2007, at 15:50, Brzozowski, John 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.
[jjmb] If I understand this correctly there will be a unique RA sent for each subscriber? Assuming yes, I am not sure this is universally applicable to all access networks. Additionally, I think we would require some dynamic mechanism, perhaps via DHCPv6, to dynamically provide the data to the route to facilitate configuration otherwise this would be very complex from a management and operational point of view.
Yes, the subscibers all see different RAs. I see two ways to accomplish this: either have the ISP router send out RAs and have a downstream device intercept and modify them before the subscribers seee them, or have the device in question generate the RA in the first place. The latter has the advantage that this device can answer router solicitations so there is less RA traffic upstream. However, in that case the device in question would need to know all the information that goes into the RAs. This could of course be distributed through DHCPv6 but also through other mechanisms but that information may be sufficiently static that manual configuration isn't a problem.
[jjmb] Apologies if there is an obvious answer to this question, but how do the aggregation devices know what to do with the RAs? Is it assumed that they are simply receiving the same and have been pre- configured to manipulate the bits required for the respective subscribers?
For the purposes of my explanation, yes. Obviously that is something that needs to be worked out, but I would assume this is fairly straightforward because both ends in that communication are under the control of the ISP.
Also this does not address the scenario where the aggregation devices is also a router right?
It could if there's only one router interface. With a layer 3 interface per customer, obviously none of this applies. 


Customers without an IPv6 router do normal IPv6 stateless autoconfig
so the lower 64 bits of the addresses are random, but the ISP only
sees packets with the customer ID number somewhere in the higher bits
so they know which packets come from which customer.
[jjmb] Stateless auto-configuration is one alternative? DHCPv6 could be used as well right?
What I wrote about only addresses RAs. If you want to do address configuration from an ISP DHCPv6 server towards subscriber hosts, that would involve some additional work: the ISP DHCPv6 server would have to know which port the subscriber is sitting behind (= option 82). I don't think DHCPv6 currently supports this.
Don't forget that you need the RAs anyway, first of all for hosts that don't support DHCPv6 address configuration (which is most of them), second for the default gateway. I'm not entirely sure what happens when there is no prefix option in RAs for the prefix used by the DHCPv6 server because that way the host doesn't know which addresses are on-link. 

On 28 dec 2007, at 17:54, Kevin Loch 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. 


This seems a whole lot more convoluted and hackish than just giving
operators the option of running dhcpv6 and vrrpv6 with RA turned off.
See above. Also, DHCPv6 doesn't give you a default gateway so this can't work.
I disagree that it's convoluted or hackish. In my opinion, this RA mechanism is more elegant than intercepting DHCP traffic and adding options like what happens with IPv4. 


However, There is a way you could do both.  Have the CPE devices act
as routers instead of l2 bridges.
(I hate that for IPv4 because that means I have to live with the cheapest NAT the ISP could buy that month rather than bring my own which is much better. But for IPv6 it's just routing, which shouldn't have that issue.)
Note though that have CPEs route doesn't mean there is no problem, because you can't have CPEs inject trustworthy information into the configuration process. 


CPE devices request everything
including gateway via dhcpv6. They also get a customer subnet (/48 / 56 whatever) via dhcpv6 option or via their tftp'd config file. CPE 
then issues RA's on customer subnet(s) for convenience in the home
userspace.
The appropriate way to obtain a prefix would be with DHCPv6 prefix delegation. A default gateway can easily be configured with an RA that doesn't contain any prefix options. 


I've already mentioned that hosting environments absolutely
cannot run any kind of RA due to the strict controls and
sometimes complex setups where broadcast style configuration
won't work.
The above is intended for broadband provisioning (hence the subject line) but I think it could also work in hosting environments etc if the central management only needs to know which customer a packet belongs to, without having to know about individual hosts. 

On 28 dec 2007, at 17:55, Gert Doering wrote:
I see your proposal as a solution to the problem space "multiple customers 
share a single layer 3 segment".


We are in agreement.  :-)
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.
Until subscribers start exchanging modems (or hacking them) so you lose track of which address goes with which customer. 


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?


That's a question for the vendors.
But I'd say it's fairly easy to do some RA processing in the control plane and have some "if ethertype = ipv6 then x bytes at offset y in the packet must match the port ID" logic in the data plane. A full IPv6 router implementation is much more involved.