[calix-nsp] IPv6 status

[Frank Bulk - iName.com]

Dan:

Thanks for sharing all that.  

Calix hasn't proven themselves very strong at L3, so I don't think you're
the only one to keep Calix gear at L2 and let the routers do the work.

I see your point about handing out separate /64's per customer.  In your
customer per VLAN approach, I'm guessing you had create an "ipv6 prefix ..."
for each VLAN?

It's my understanding that if I use the VLAN per service approach, there's
no way hand out separate /64 prefixes to each customer router's WAN
interface.  Please correct me if I'm wrong -- I'd be ever grateful.  I *can*
delegate separate /56 prefixes out of a /48 to customer *routers* via
DHCP-PD.

Frank

-----Original Message-----
From: Dan White [mailto:dwhite at olp.net] 
Sent: Friday, August 06, 2010 10:29 PM
To: Frank Bulk
Cc: calix-nsp at puck.nether.net
Subject: Re: IPv6 status

On 06/08/10 21:16 -0500, Frank Bulk wrote:
>Would love to hear what others are doing in regards to rolling out IPv6
over
>their Calix networks (FTTH and xDSL).  
>
>We're doing VLAN per service for VDSL and FTTH and we'll likely turn up a
>/64 on that VLAN to hand out an IPv6 address in that /64 for their router
or
>singular PC, and then use DHCP-PD to hand out a /56 if their router
requests
>one.
>
>For DSL we'll likely do PPPoEv6.
>
>Frank

We're in the process of specing out a Redback replacement (probably Cisco)
that will give us IPv6 support, among other things.

We currently have a mix of C7 and E5 equipment. Our current deployment of
C7 gear primarily uses RFC1483 Bridging/LLC back to our Redback, which gets
Calix out of the way of doing any sort of Ethernet or IP processing on that
traffic, and should facilitate a transition to native/dual stack IPv6 quite
nicely, over an OC-3 to the router.

On our newest C7 ring, and our smallest one, we chose to roll out internet
service over Calix's GE2P card, rather than over an ATM OC-3, using a
bridged VB. It works fine, but is a fair amount more complex. I prefer
the OC-3 uplink approach due to its simplicity.

I've tested native IPv6 over both of these approaches successfully (router
advertisements and dhcpv6 prefix delegation), with the IPv6 traffic bridged
out from the Redback to a test Linux router.

On our E5 gear, we have deployed ADSL bonding and VDSL (no FTTP or Active
Ethernet subscribers). We are configuring VLAN per subscriber and
aggregating traffic on the Redback using dot1q encapsulated subscribers.

The E5-400 box passes IPv6 packets without a hitch. The E5-11x boxes did as
well, at one time. Not sure if the still do... our sales engineer said that
was an accident and that we shouldn't expect it to continue to work. I've
never successfully passed IPv6 packets on the E5-12x product.

I don't have a lot of confidence that the E5 product team is engineering a
solution for us. They appear to be focusing on doing even more layer-3
processing, which makes sense in a VLAN per service approach, rather than
getting out of the way and letting us handle it all at our router.

On all platforms, assuming we can get to the point that we want to be at,
we are considering assigning a /64 to each customer's service for a couple
of reasons:

1. We can generate router advertisements and allow customers to plug
directly into the service (assuming their modem is bridged) and
autoconfigure an address and get service.

2. We can use that /64 as a point to point link between our router(s) and
the customer's router(s) and then route a /48 subnet down the link via
static route, dhcpv6 prefix delegation, or routing protocol.

Advertising a shared /64 among several customers scares me quite a bit, and
would likely require a lot of layer 3 semantics in the access gear (Calix)
to work securely. I just don't have a great deal of confidence that Calix
can pull that off, particularly in a scenario where clients are auto
configuring addresses.

-- 
Dan White
BTC Broadband
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610            email: dwhite at olp.net
http://www.btcbroadband.com