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

Re: IPv6 broadband provisioning

Iljitsch,
I would strongly suggest alignment with the two existing DSL Forum TR-101 models ( the N:1 and 1:1 VLAN approach) and CableLabs DOCSIS. Let's reuse the same logical architectures so we don't have providers changing their aggregation network logical constructs to support IPv6. In the 1:1 VLAN model, each subscriber is uniquely identified by S/C- VLAN tags to the BNG. It is the N:1 VLAN model that needs an method to insert some "access node specific" information into the DHCPv6 exchange.
I'm not sure we need to use global-unicast addresses on the WAN CPE interface so I'd hazard to say that RA with PIO is not needed. Just do stateless autoconfig for link-local, then move to DHCPv6 for prefix delegation (ie, M-bit=0, O-bit=1 in the RA). This may cause interesting CPE implementation-specific issues when sourcing ICMPv6 packets out the WAN interface, but the flexibility is there to use the "best" address for the SRC IP. From a customer's perspective, is a global-unicast WAN address useful? From an ISP and vendor perspective it may add additional complexities. What do you think about such an approach? This would remove the need to add anything to RA between the ISP router and the CPE.
If we assume the reasons we established a L2 DHCPv6 relay agent are still valid in an IPv6-world, I'd suggest DHCPv6 Layer 2 Relay agents for the requirement you describe. What you have described is the very reason that the DSL Forum implemented L2 DHCP(v4) Relay Agents in TR-101. I'd propose extending something similar to DHCPv6 that would: - Allow a access node (such as a DSLAM) to intercept DHCPv6 messages, and - Insert DHCPv6 Interface-ID and Remote-ID to uniquely identify the IPv6 subscriber 
- Encapsulate these messages into a DHCPv6 Relay-Forward structure
- Forward towards the all_dhcp_relay_agents_and_servers address - with a Source IPv6 address of the requesting client inserted into the Relay- Forward
This last part removes the need for the DSLAM to implement a complete IPv6 stack that would require configuration and participation in ND, etc. I would like to explore this part with others as part of discussions within the DHC WG on this issue.
In the n:1 IPoE world we need to consider the layer 2 Ethernet network as much as IPv6, so some mechanisms you describe for DoS prevention need to be extended to MAC addresses. To this extent we would usually admit a single learnt MAC per DSL line (does this also imply a single link-local?? I guess EUI-64 may not be MAC derived?)
The nasty subject of ND and DAD comes up in the N:1 VLAN approach because a "split-horizon" forwarding model is in place. RFC 2460 defines a "link" as a medium over which nodes can communicate at a link-layer. The problem with the N:1 VLAN model is that nodes cannot communicate with one-another via the link-layer, only with the L3 router (BNG). This fundamental problem manifests itself during DAD - consider this: - When a node sends a DAD (for link-local addressing) it uses an unspecified source and the destination is set to the solicited-node MC address of the target - Because the network is running split-horizon, only the ISP router(s) will receive these DADs. - The routers cannot relay these messages back into the N:1 VLAN, because the node sending the DAD (still with a tentative address) will immediately stop address auto-configuration if it receives a DAD with the target-address equal to its tentative address. - If the router sends a Neighbour Solicitation message and does happen to receive a response what should it do? Should it send a Neighbour Advertisement (which would cause the node with a tentative address state to stop?) 


Regards,

-David


On 28/12/2007, at 11:58 PM, Iljitsch van Beijnum wrote:


Hi,
(I posted largely the same message to the internet area list yesterday because we had extensive discussions there about DSL Forum stuff.)
One of the things that we haven't quite figured out about IPv6 is how broadband deployment would work. I think it would be good if we can agree that customer routers can request an IPv6 prefix using DHCPv6 prefix delegation. Since there is really no other way to do this, I don't expect that to be too controversial.
The problem is how ISPs get to enforce restrictions on how packets flow from devices connected to the DSL or cable modem (or link, a user could buy their own modem which isn't controlled by the ISP). If there is a dedicated physical or virtual interface per customer, this is all simple enough. But I understand this isn't necessarily the case, and moving in that direction could be costly. So here's another approach. Please let me know what you think.
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.
For instance, if an IPv6 router sits on top of two layers of layer 2 aggregation devices, the IPv6 router sends out router advertisements with prefix 2001:db8:31::/64. The lowest layer of aggregation devices then insert a 16-bit customer or line ID in bits 48 - 63 so that customer 9 sees 2001:db8:31:9::/64 and customer 10 2001:db8:31:a::/64 and so on. (The router advertisements can also be generated by the layer 2 device itself, but there probably needs to be some centrally configured info in there, too.)
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. The layer 2 infrastructure can safely impose the restriction that all customer traffic goes to the IPv6 router and not to other customers, because customers don't know their neighbor's prefix is on-link so they'll send those packets to the router anyway. And the router doesn't need an address in all those prefixes, the users only need to know its link local address. (Of course add ingress filtering as required.) The router is simply told that all of 2001:db8:31::/48 is on-link so it will do ND for all customer machines, but it doesn't send redirects.
(I would probably implement a per-customer ND cache LRU algorithm to prevent one user from DoSing a whole town by generating large amounts of addresses that the router must do neighbor discovery for. There is no reason why a user wouldn't be able to connect a large number of machines using a switch but this may not be altogether desirable from the ISP's perspective.)