Subject: IPv6 broadband provisioning

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Dec 2007 13:58:27 +0100

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.)

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 28 Dec 2007 09:50:32 -0500

Hello Iljitsch, please see my comments inline below.

Regards,

John
--------------------------------------------------- 
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
---------------------------------------------------

-----Original Message-----
From: [email-masked] on behalf of Iljitsch van Beijnum
Sent: Fri 12/28/2007 7:58 AM
To: IPv6 Operations
Subject: IPv6 broadband provisioning
 
Hi,

[jjmb] This seems reasonable.

[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.

[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?  Also this does not address the scenario where the aggregation devices is also a router right?

[jjmb] Stateless auto-configuration is one alternative?  DHCPv6 could be used as well right?

---

From: Kevin Loch <[email-masked]>
Date: Fri, 28 Dec 2007 11:54:41 -0500

Iljitsch van Beijnum 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.

However, There is a way you could do both.  Have the CPE devices act
as routers instead of l2 bridges.  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.

This is an example of different environments where dhcpv6/vrrpv6
with RA turned off makes sense, and where fully featured
RA is best.

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.

- Kevin

---

From: Gert Doering <[email-masked]>
Date: Fri, 28 Dec 2007 17:55:04 +0100

Hi,

> line, so that every customer sees RAs with a prefix unique to them.

I see your proposal as a solution to the problem space "multiple customers
share a single layer 3 segment".

In our network, this is basically a non-problem - every customer has their
own routed layer 3 segment, gets their own /48 (or /56), and the ingress 
router will do proper IPv6 uRPF (eventually).

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.

Another problem area might be large-scale DSL where customers are not
terminated by PPPoE/L2TP, but sort of "all of them bridged together" - here
your approach might make sense.  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?

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Fri, 28 Dec 2007 18:22:38 +0100

Hi,

> sometimes complex setups where broadcast style configuration

In this absoluteness, this sentence is just plain untrue.

In our hosting environment, RAs work perfectly fine.  Every customer
has their own L3 network segment, and if they want to do autoconfiguration,
they can - and if they want to do static configuration, they can do as
well.  If the customer network has multiple L3 segments (with largish
customers not unusual), the devices in between are configured manually
anyway.

Rephrasing your sentence to "there are hosting setups where RA-based
autoconfiguration won't help anything due to the complexity, so static 
configuration is required" would be something I could agree to, though.

Gert Doering
        -- NetMaster

---

From: Kevin Loch <[email-masked]>
Date: Fri, 28 Dec 2007 13:23:37 -0500

> configuration is required" would be something I could agree to, though.

You are correct, I shouldn't have stated that in absolute terms.

- Kevin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Dec 2007 19:38:59 +0100

> [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.

>> so they know which packets come from which customer.

> 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:

>> 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.

> 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.

> 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

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.

> sometimes complex setups where broadcast style configuration

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.

> share a single layer 3 segment".

We are in agreement.  :-)

> 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

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.

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Dec 2007 08:44:54 +1030

On Fri, 28 Dec 2007 11:54:41 -0500

> then issues RA's on customer subnet(s) for convenience in the home

This is pretty much the model I've been assuming. Here in .au all CPE
that's been sold in the last 5 years or so has been configured and
operates as a router, performing NAT, when given to the customer.
That's one of the things that's going to cause us trouble deploying
IPv6, which is where solutions such as Teredo are options.

That being said, by accident I've recently found that the new CPE my
employer has started selling both bridges non-IPv4 frames and routes
IPv4 concurrently by default. I don't know if this brouter
functionality is common, or going to become common, although this CPE
is pretty typical OEM'd CPE in the asia pacific. I could fire up IPv6
on our DSL Internet PVC, and have devices receive RAs though the
hundreds of these things we've sold.

> sometimes complex setups where broadcast style configuration

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Dec 2007 09:17:45 +1030

On Fri, 28 Dec 2007 17:55:04 +0100

> device, and go back to the "one customer, one L3 segment" model?

I see some value in having the customer's routing CPE "all bridged
together". In my employer's DSL environment, our exchange located DSL
equiment is "bridged" together using ethernet switches, with a backhaul
layer 2 link to the offsite layer 3 infrastructure. It would be ideal
if inter-subscriber IPv6 traffic between subscribers attached to the same
exchange stayed in the exchange. In a routed IPv6 CPE environment, with
prefixes delegated to the CPE via DHCP-PD, that means that the ethernet
segment in the exchange mostly becomes a link interconnecting routers.

In the past, to get optimal routing, all the routers would participate
in an IGP. In this DSL subscriber environment that wouldn't be possible
because we couldn't trust the customers to not inject prefixes they
shouldn't (we don't manage the CPE).

An alternative I've been thinking about is ICMPv6 "network redirects".
The upstream DHCP-PD delegating router is aware of all the prefixes
that the downstream CPE routes for. The downstream CPE default to the
upstream DHCP-PD delegating router. When the upstream delegating router
knows that it's being asked to route between two downstream prefixes,
it sends a ICMPv6 "network redirect" for the target prefix to the
traffic source CPE. That causes the traffic source CPE to send the
traffic direct to it's CPE peer, rather than via the upstream and
offsite delegating default router. The ICMPv6 network redirect might
timeout after a period, or use something like dead gateway detection to
ensure this redirect information continues to be valid.

If a subscriber plugged a host directly into this subnet, learning it's
prefixes via RAs, I think that could also process these ICMPv6 network
redirects.

While certainly not as efficient as having the downstream CPE being
fully aware of the routing topology, this method would save having a
resonable amount of traffic double traverse the more expensive backhaul
links - traffic staying within an exchange is essentially free. There's
an ICMPv6 "network redirect" spoofing risk, however I think there are a
few ways that could be mitigated that are similar to methods used today
to mitigate ARP & DHCP spoofing on DSL bridged networks.

Regards,
Mark.

---

From: David Miles <[email-masked]>
Date: Sat, 29 Dec 2007 11:46:15 +1100

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.
>
> 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.
>
> 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.)
>
> 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  
> 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.
>
> 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.)
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Dec 2007 09:11:46 +1300

On 2007-12-29 01:58, Iljitsch van Beijnum wrote:
...
> with prefix 2001:db8:31::/64. 

Why do you say /64? The model is supposed to be that SOHO subscribers
get at least a /56.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 29 Dec 2007 22:52:17 +0100

On 29 dec 2007, at 21:11, Brian E Carpenter wrote:

>> 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.

> Why do you say /64? The model is supposed to be that SOHO subscribers

This is when the user's machine(s) directly get RAs from the ISP. In  
that case it has to be /64 or stateless autoconfig won't work. If they  
want more than a /64 they'll need an IPv6 router and, presumably,  
DHCPv6 PD to request a prefix.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 29 Dec 2007 23:17:42 +0100

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.

> 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?

> 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:
> 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.
> 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.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 29 Dec 2007 23:29:57 +0100

On 29 dec 2007, at 23:17, Iljitsch van Beijnum wrote:

> 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  

The reason for that being that the global address is derived from the  
prefix particular to that subscriber so the ISP can correlate the  
delegated prefix with the subscriber that way.

---

From: David Miles <[email-masked]>
Date: Sun, 30 Dec 2007 11:21:27 +1100

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:

>> 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.
>
> 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?
> 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?

> 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".

> 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?

>> remove the need to add anything to RA between the ISP router and  
>> the CPE.
>

[DM] We're both trying to address the common problem statement - this  
way we can pick the good parts from everyone's ideas.
> easier than implementing DHCPv6 snooping, and with RAs you can  
> support bridging CPEs with today's IPv6 implementations so  
> deployment will be easier.
>
> 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.

> 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  

[DM] Sorry, I wasn't being very clear, I was referring to L2 DHCPv6  
Relay Agent.
>> 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.

> 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.

> 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.

> 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.
> hosts with the same link local address are both active enough for  
> the router to have their info in the neighbor cache.

---

From: Mark Smith <[email-masked]>
Date: Sun, 30 Dec 2007 21:03:00 +1030

On Sat, 29 Dec 2007 23:17:42 +0100

> > node specific" information into the DHCPv6 exchange.
<snip>
> an easy way to protect against that. How does this work today in a N:1  

The DSLAMs we use perform MAC address - wait for it - NAT, into
algorithmically calculated MAC addresses, in part based on line card
and node IDs. It's ugly thinking about all the FCSes that are being
recalculated all the time, however it does avoid MAC address
collisions, regardless of what the customer does on their side of the
DSLAM.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Dec 2007 16:47:05 +1300

On 2007-12-30 10:52, Iljitsch van Beijnum wrote:
> want more than a /64 they'll need an IPv6 router and, presumably, DHCPv6 
> PD to request a prefix.

Yes. That's the model we should be defining as best practice.

    Brian

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 31 Dec 2007 08:22:57 +0100 (CET)

On Fri, 28 Dec 2007, Iljitsch van Beijnum wrote:

>> [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.

In my opinion if the ISP router send out RAs is easier to control - except 
no ipv6 transparency possible in the broadband network as described in "
ISP IPv6 Deployment Scenarios in Broadband Access Networks".
These models are already described in the RFC 4779. What is the goal of 
this discussion? It is clear that, The address alignments has to be 
defined. What else?

Sorry for jumping in late in the discussion....

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 31 Dec 2007 12:49:34 +0100

On 31 dec 2007, at 8:22, Mohacsi Janos wrote:

> In my opinion if the ISP router send out RAs is easier to control -  
> except no ipv6 transparency possible

What does "no IPv6 transparency possible" mean?

> These models are already described in the RFC 4779. What is the goal  
> of this discussion? It is clear that, The address alignments has to  
> be defined. What else?

The point is to show that it's doable to have stateless  
autoconfiguration for subscriber hosts connected to a bridged CPE.

> and node IDs.

Which of course creates all the usual problems that NAT always  
creates: what about protocols that embed the translated addresses? In  
this case, that would be neighbor discovery.

> It's ugly thinking about all the FCSes that are being
> recalculated all the time

That happens in the ethernet hardware, not an issue.

> there is no IPv6 router between subscriber node and the ISP network)

Hard to say, but unless you want to buy a somewhat expensive Cisco CPE  
that runs IOS (I gather that the "easy" configuration works much  
better these days but I wouldn't count on it too hard) a bridging CPE  
is the only way to easily provide native IPv6 connectivity today.

> nodes behind the bridged CPE

Maybe at some point in the future all IPv6 hosts will support DHCPv6  
address configuration, but there is no way that's going to happen any  
time soon. I believe people from Apple have said that they're not  
interested in supporting DHCPv6.

> don't we still need to address the issue of identifying the CPE  
> (hence the L2 DHCPv6 relay agent in the access node)

See my earlier message, if the DHCPv6 client uses a global address  
learned from subscriber-specific RAs then there is no need to mess  
with DHCPv6 in layer 2 devices.

> - DAD has issues in the N:1 VLAN approach

I think that can be solved unilaterally by the ISP infrastructure.

> what is the advantage of bridging?

Switches are cheap and simple.

> appended (as interface ID) to fe80::/64, and DAD is performed on  
> that address. RFC 2462 says "the autoconfiguration process includes  

Stateless address autoconfiguration = creating addresses based on  
router advertisements. That doesn't apply to link locals.

> 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?

With M=0 O=1 I'd think a client would initiate the stateless variation  
of DHCPv6. For prefix delegation you'd need the stateful version...

> 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  
> or a ::/64, etc?

Stateless autoconfig only works with /64...

> The problem I see with stateless autoconfig is that:
> - 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  

I don't see these as particularly problematic. It would of course be  
nice if the aggregation switches wouldn't have to do anything, but  
guess what, if you want to have per-subscriber settings you really  
need to do per-subscriber work SOMEWHERE.

> [DM] Sorry, I wasn't being very clear, I was referring to L2 DHCPv6  

Like I said, I'm pretty sure we can avoid doing stuff like that. (Also  
DHCP relaying is a layer 3 function, not a layer 2 function, inserting  
option 82 or some such is not relaying proper.)

>> 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.

Does that matter? The point is that the ISP router sends out a packet  
to make DAD fail if a host tries to configure an address that's  
already in use. Not sure though what the host holding that address  
previously will think about seeing that proxy ND packet...

>> 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.

> discussion) unless you are sure two devices with duplicate MACs  
> cannot exist on the same segment

With duplicate MAC addresses you're screwed anyway so trying to  
address that situation doesn't help. So I think it would very  
appropriate for hosts to check for their own link address in incoming  
ND packets when doing DAD.

But this isn't relevant to our discussion, because if there are two  
hosts with the same address on that N:1 network they won't know  
because they can't send packets to each other directly