[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 broadband provisioning
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
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.
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
[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
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
Since that was the core of my idea your idea and mine seem complete
[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
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
- 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
[DM] Sorry, I wasn't being very clear, I was referring to L2 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
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:
[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
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.