Subject: [Int-area] IPv6 provisioning on broadband

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Dec 2007 23:30:44 +0100

Hi,

After our nice DHCP auth discussions on the list I had occasion to  
discuss this issue and a few related ones in person with a few people  
in Vancouver. Obviously this involved the question of how to provision  
customers with their IPv6 addresses on broadband networks. I think I  
now have an idea for that that could work well. I'm interested in  
hearing your comments.

The (old) idea is that if customers deploy their own IPv6 routers,  
they get to request a prefix through DHCPv6 prefix delegation.  
(Whether the first router gets a prefix and internally redelegates if  
there are more routers or multiple routers can request prefixes is an  
open question.)

However, if the customer doesn't connect a router, it's good if they  
still receive IPv6 address configuration. (My apologies for my lack of  
knowledge of broadband lingo.) I think a good way to do that is for  
the first device under the control of the ISP, or at least a device  
very low in the aggregation hierarchy, to intercept router  
advertisements from the ISP's IPv6 router and slightly modify them:  
basically inject 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 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.)

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Mark Townsley <[email-masked]>
Date: Fri, 28 Dec 2007 10:39:03 -0600

> so that every customer sees RAs with a prefix unique to them.
The encoding is different (opt vs. prefix), but there is some similarity 
in this:

http://tools.ietf.org/html/draft-wen-ipv6-rsra-opt-pid-01

- Mark

---

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

On 28 dec 2007, at 17:39, Mark Townsley wrote:

> The encoding is different (opt vs. prefix), but there is some  
> similarity in this:

> http://tools.ietf.org/html/draft-wen-ipv6-rsra-opt-pid-01

Right, thanks for the link.

However, I think the mechanism in this draft is much more complex  
(especially to implement) without any additional benefits: the layer 2  
device is required to intercept router solicitations and add  
information to those so that router advertisements specific to the  
subscriber in question can be generated. However, I think it's  
possible (and easier) to skip the RS step and simply generate the  
appropriate RAs for each subscriber in the first place. This also  
avoids the issue of what to do with unsolicited RAs, which I think the  
draft doesn't address.