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

Re: IPv6 broadband provisioning

Comments below,

The core questions that need discussion are:
- How likely bridged CPE is for IPv6 broadband deployments? (Where there is no IPv6 router between subscriber node and the ISP network) - Whether stateful DHCPv6 or stateless autoconfig is supported for nodes behind the bridged CPE - If we have agreed that DHCPv6 PD is the way to go for routed CPE, don't we still need to address the issue of identifying the CPE (hence the L2 DHCPv6 relay agent in the access node) 
- DAD has issues in the N:1 VLAN approach

Regards,

-d


On 30/12/2007, at 9:17 AM, Iljitsch van Beijnum wrote:


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.
[DM] I wasn't going so far as to consider the bridged CPE model, only the routed CPE model. The alternative of bridging the CPE in an Ethernet network is that BNG will now need to populate forwarding tables with multiple Ethernet MAC addresses (ie, an entry in the neighbour table for every host rather than every prefix!), and an Ethernet-based aggregation network may learn these addresses. With a finite limit of entries in the neighbour table, and the BNG being a concentrator for many subscribers what is the advantage of bridging?
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.
[DM] Right, the bridged CPE method. I think this needs to be debated. To be fair environments like DOCSIS have had a bridged CPE for a long while - is it unreasonable for DOCSIS 3.0 MULPI (Appendix VII) to "specify DHCPv6 as the method of choice to provision IPv6 addresses for CM and bridge devices"?
I'm not trying to suggest a "one-size-fits-all", but let's be sure to address the immediate needs of service providers (for the most likely scenarios) rather than get bogged down in a plethora of options?
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.
[DM] Are we talking semantics here? On an Ethernet link, EUI-64 is appended (as interface ID) to fe80::/64, and DAD is performed on that address. RFC 2462 says "the autoconfiguration process includes creating a link-local address".
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?
[DM] If I'm interpreting RFC 2462 correctly and do not want the interface address to be assigned by DHCPv6, then there is no need to set M=1. RFC 3633 does seem to separate address assignment from prefix delegation (section 7). Perhaps worth clarifying whether M-bit must be set for 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. :-)
[DM] We're both trying to address the common problem statement - this way we can pick the good parts from everyone's ideas.
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.
[DM] Okay, so we need to consider the case when there isn't a IPv6 router in the CPE (ie, the CPE is bridging). I must admit I was putting more emphasis on the routed components of your discussion.
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.
[DM] Appreciate that today the DSLAM insert an opaque value into the DHCP Option-82 field. If we start modifying the PIO in the RA with per- subscriber info then the DSLAM/access switch will need to have information about IPv6 prefixes? Ie, does this customer get a ::/56, or a ::/64, etc? Also, we would need a method to reconcile between access switch and the service provider's IPv6 router. The problem I see with stateless autoconfig is that: 
- It requires every RA to be unique to each subscriber
- In an N:1 network, only the access node/DSLAM can create per- subscriber unique RA - RA are sent regularly (at least ever 30 min, default 10 min) as a MC, so the access node must intercept, and create several hundred "modified" RA - Instead of the line-Id being an opaque value that a DHCP(v6) server uses to determine appropriate prefix, the line-id now forms a fundamental part of the IPv6 address prefix.
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.
[DM] Sorry, I wasn't being very clear, I was referring to L2 DHCPv6 Relay Agent.
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.
[DM] In this instance it may be worth consulting with those providers that do bridge to understand this a little better. I am bias towards a routed CPE given that is the model that has best suited our DSL environments, but it may not always hold true.
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? 

[DM] Up to each vendor. Options include:
- MAC "pinning" - once a MAC is learnt in cannot be re-learnt (or traffic forwarded) on any other bridge interface until it is aged out. - 802.1x-coupling - on successful authentication, use the MAC address of the EAP supplicant and install as a MAC-based filter.
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...?)
[DM] Proxy ND was really made for relaying ND between different links. In this case we have two nodes on the same "link". Again, definition of link is the problem, from the ISP router, there is one link with many subs. From the subs perspective there is a point-to-point link (of sorts) between them and the router.
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.
[DM] Paraphrasing RFC 2462 5.4.3: If the source address of the ND is unspecified (per DAD) and the solicitation is from another node, then the address is duplicate. Appendix A describes the problem (two nodes with same identifier and link-layer address) and explains that if the number of Neighbour Solicitations exceed the number expected based on loopback semantics, the tentative address is duplicate. This is the problem I'm trying to describe - hosts are not smart enough to "detect" this condition because there is no way they can determine whether the Neighbour Solicitation was from them or from someone else. Checking link-layer isn't really valid (per Appendix A discussion) unless you are sure two devices with duplicate MACs cannot exist on the same segment by implementing either MAC-pinning or 802.1x- coupling, and even then the client autoconfiguration code may need changing. DADs do not have source link-layer address options in the Neighbour Solicitation.
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.