Yo Dawg, I heard you want to run dual stack.

“Hey Grumps, it seems like most of your posts aren’t actually so much about networking as they are about tools, what’s the deal?”

First- Shut up, I don’t even like you.

Second- I think I have a tendancy to write about solving problems, and creative tool use/fabrication interests me more than ‘switchport trunk vlan add 666’ (<– although there are plenty of fun stories behind remembering to use this command correctly, amirite?)

Third- Fine, you wore me down, this one’s about networking.

Just the other day, in my lab, I was working on some cool IPv6 translation tools (DNS64/NAT64), and wanted to really see them start to work.  My home network has historically been all IPv4 with some IPv6 in the lab, so this obviously presented some interesting obstacles.  So to solve the short term need I spun up a dual stack apache/bind server and handled my tests that way.  However that gets pretty boring fast, and I wanted to test out DNS64 against something more real-life, like the internet.

My home firewall is an SRX100 which receives a DHCP address from Comcast (Relevant).  Currently it only does this with IPv4, so I figured, what the hell?  Let’s turn on the dhcp client for IPv6 on this bad boy- how hard can it be?

Hubris, Grumps, hubris…

The summarized version of the story is:

  1. Get the software
    1. JUNOS 11.whatever doesn’t support the IPv6 dhcp client
    2. Hey, JUNOS start providing support for that in 12.something lets upgrade!
    3. Commence upgrade
    4. Fail upgrade and make the box unbootable
    5. Shit.
    6. Find out that I ran out of memory on the device (this can be a problem on the smaller boxes, but seriously, WTF there’s no free space check?)
    7. Run a manual install from a USB
    8. Find out that config managed to be saved (not a big deal, I have backups, but nice nonetheless)
    9. Box now back and running
  2. Configure the software
    1. Well this should be easy, we’ll just turn the client on
    2. Realize, ‘hey IPv6 is a protocol for adults, its not just turn it on’
    3. Get the various configurations in place

    4. Try to commit
    5. Read commit errors about ‘dhcpv6-client configured not compatible’ (WTF?)
    6. Look at base minimum configuration from Juniper (here)
    7. Apply base minimum configuration
    8. Try to commit
    9. More goddamn commit errors
    10. Do more digging
    11. Find this gem (here) about the dhcpv6-client and dhcp server (which I’m running for the home network) being incompatible
    12. Migrate to new dhcp server config
    13. Delete old dhcp server config
    14. Commit
    15. Shit works (details summarized/anonymized)

  3. Okay, now I’ve got dual stack running on the firewall, now we just need to extend it to the lab
    1. Add an IPv6 address SRX facing my lab router
    2. Add an IPv6 address to my lab router that faces my SRX
    3. And on the other interface of the lab router that faces all of my vyos vRouters
    4. Set up BGP on the SRX to peer with the lab router over IPv6
    5. Set up BGP on the lab router to peer with the SRX over IPv6 (and while we’re at it, we’ll configure the lab router for peering with the vyos vRouter that sits in front of this particular lab
    6. Add an IPv6 address to the vyos vRouter
    7. Then configure the vyos vRouter to do BGP upstream over IPv6
    8. Commit and save your stuff
    9. If everything is working you should see something like this:
    10. To verify that is actually what we want, lets verify the AS path of the route
    11. Hot damn.
  4. Oh, you actually want IPv6 Internet?
    1. Since IA-PD doesn’t work correctly, and I’d prefer to keep my IPv6 labs static (since they’re using private addressing) we’re going to do something a little gross here, 6 to 6 NAT.  To accomplish this, we’ll simply create another rule for source NAT on the SRX (its not pretty, but it works and does what I need for now):
    2. Now enjoy all that is IPv6 Internet
    3. Just kidding.  After all this you still notice problems.  You need to enable IPv6 on all of your intermediary devices as it may not be enable by default
    4. On our SRX we need to do this:
    5. And on our Cisco device we need to do this:
    6. Now it works.  For realzies.

Its a good thing that I work at home most of the time, as the (not-so)little snafu with the SRX took down my home internet for most of the day.

I can also configure the SRX for prefix delegation, however the problem is that the SRX doesn’t have the ability (as of 12.X46-D40.2) to configure the length of the prefix you would like delegation for, so it grabs the /64 and starts handing out /80s which is pretty ghetto (and I know that Comcast will hand out a /48 for delegation if your client requests it).