Its not DHCPv6, as last time I looked (which admittedly was a while ago) there were still a lot of OS's/devices lacking (decent) DHCPv6 support, but heres a working SLAAC config that I use on my SRX100 at home (10.4R4.5) hanging off a HE.net tunnel:
interfaces { ip-0/0/0 { unit 0 { tunnel { source me.me.me.me; destination 216.66.80.26; } family inet6 { address 2001:470:1f08:me::2/64; } } } pp0 { unit 0 { family inet { filter { input FIX-V6V4-TUNNEL; } } } } vlan { unit 10 { family inet { address 172.25.144.65/26; } family inet6 { address 2001:470:me:1::/64 { eui-64; } } } } } routing-options { rib inet6.0 { static { route ::/0 next-hop 2001:470:1f08:me::1; } } } protocols { router-advertisement { interface vlan.10 { prefix 2001:470:me:1::/64 { on-link; autonomous; } } } } firewall { family inet { filter FIX-V6V4-TUNNEL { term OUTPUT { from { destination-address { 216.66.80.26/32; } protocol 41; } then packet-mode; } term INPUT { from { source-address { 216.66.80.26/32; } protocol 41; } then packet-mode; } term OTHERWISE { then accept; } } } } IPv6 has some issues on the SRX series still, meant to be fixed in 11.4 IIRC, so theres a simple fix required to make it work in the mean time with the firewall rule. Someone may find this useful. :-) On 10 October 2011 16:26, Mark Tinka <mti...@globaltransit.net> wrote: > On Saturday, October 08, 2011 02:54:40 AM Paul Stewart > wrote: > > > Thank you Amos, Robert, Jared, and Scott for the on-list > > and off-list replies. > > > Got it up and running – appreciate the responses… > > You also want to look out for rogue RA's on the network, > typical of conference or enterprise setups where v6 is > involved. > > Common cases have been Windows Vista hosts making themselves > routers and spewing 6-to-4 on the network. Suffice it to > say, DRP implementation in routers (sort of meant to thwart > this) on the subnet is pretty useless. > > As you likely know, Rogue RA support is lacking today > (although specs. are already out), as is DHCPv6 Snooping. > Our only solution was to filter at the MAC layer. Hectic, > but luckily, we used few switches and were able to deploy > filters quite rapidly. > > Mark. > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp