[calix-nsp] IPv6 status

[Dan White]

On 07/08/10 00:06 -0500, Frank Bulk - iName.com wrote:
>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 still theoretical at this point, because we haven't actually deployed
IPv6 service, but I'm expecting it to look something like:

interface gigbitethernet1/0/1.20812
  encapsulation dot1q 2081 second-dot1q 2
  ip unnumbered loopback 2
  ip helper-address 67.217.151.130
  ip helper-address 67.217.151.131
  ipv6 enable
  ipv6 mtu 1280
  ipv6 address 2610:b8:2:3::/64
  no ipv6 nd supress-ra


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

That's right, unless your access gear can handle the per /64 subnet
advertisements in a vlan per service scenario. There are other approaches
that Calix may use to protect router advertisements in a shared network:

http://tools.ietf.org/html/draft-ietf-v6ops-rogue-ra-01

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