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

Re: IPv6 broadband provisioning

On 29 dec 2007, at 1:46, David Miles wrote:
It is the N:1 VLAN model that needs an method to insert some "access node specific" information into the DHCPv6 exchange. 

Right, N:1.
However, you assume the presence of DHCPv6. I think it would be reasonable to assume that a CPE that can route IPv6 will use DHCPv6 prefix delegation to obtain an address block, but if the CPE bridges IPv6, then the question is whether the host(s) behind that CPE will support DHCPv6 address configuration. Since this is rare today that's a dangerous assumption.
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. 

You need this anyway if you want to support sites that don't do DHCPv6.
Also, if you give the CPE a global unicast address using RAs as per my original idea then you could do DHCPv6 with the unicast option so there's no need to implement DHCPv6 snooping. 


Just do stateless autoconfig for link-local


There is no stateless autoconfiguration for link locals.
then move to DHCPv6 for prefix delegation (ie, M-bit=0, O-bit=1 in the RA). 

Hm, is that the appropriate combination for DHCPv6 PD?
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.
Since that was the core of my idea your idea and mine seem complete opposites. :-)
I'm thinking implementing the RA handling in aggregation switches is easier than implementing DHCPv6 snooping, and with RAs you can support bridging CPEs with today's IPv6 implementations so deployment will be easier.
But I guess a lot depends on the way the DSL people end up doing authentication.
What you have described is the very reason that the DSL Forum implemented L2 DHCP(v4) Relay Agents in TR-101.
DHCP is the only reasonable way to autoconfigure addresses in IPv4. In IPv6, things are different.
This last part removes the need for the DSLAM to implement a complete IPv6 stack that would require configuration and participation in ND, etc.
That's not necessary in my model, the aggregation switch only needs to be able to send RAs that are always the same except for a few bits in the prefix option. (Probably in reply to router solicitations.) There is no need for a full or even a partial IPv6 implementation or much in the way of parsing incoming messages.
I would like to explore this part with others as part of discussions within the DHC WG on this issue. 

I don't think that makes sense, none of this requires changes to DHCPv6.
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?)
I gather that Windows Vista uses a non-MAC derived link local address. In any event, I don't think it's against the specs to do this so it must be accommodated.
I would prefer it if a subscriber could connect multiple IPv6 hosts to a bridging CPE, but if that leads to too many headaches, I guess it's acceptable to stick to the common IPv4 model where there is either a single host or a device with some routing functionality hooked up to a bridging CPE.
The issue that I see is that of duplicate MAC addresses. I don't see an easy way to protect against that. How does this work today in a N:1 model?
The nasty subject of ND and DAD comes up in the N:1 VLAN approach because a "split-horizon" forwarding model is in place.
Not sure what the issue is with neighbor discovery. As for DAD, for global unicast that's not an issue because different subscribers use different prefixes. So that leaves link locals. This can be solved by having the ISP router do proxy ND for this specific purpose to address the corner case where the link local address isn't MAC-derived. (The MAC address was unique, right...?)
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.
It's unclear what happens in the case where the original DAD message loops back to the sending host. Hopefully hosts are smart enough to detect and ignore this condition.
I think proxy ND will help here, at least in the case where the two hosts with the same link local address are both active enough for the router to have their info in the neighbor cache.