Subject: [OPS-AREA] FW: [Int-area] IPv6 provisioning on broadband

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 30 Dec 2007 10:13:37 +0100

This is a discussion folks in opsarea may be interested about. 

Dan

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Friday, December 28, 2007 12:31 AM
To: Internet Area
Subject: [Int-area] IPv6 provisioning on broadband

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

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area