Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday August 03 2015, @10:16AM   Printer-friendly
from the theory-meet-the-real-world dept.

Address exhaustion is finally about to make us all take IPv6 seriously.

I know the theory; heck, I've even taught the theory in networking courses. What I would like to find - and haven't - is a source of practical information for introducing IPv6 into a network. How should the firewall be set up? What does Apache need, to make a website IPv6 accessible? What about HTTPS? SSH? DNS? What are the security gotchas? Hands-on, practical stuff.

I've looked around for online courses - I've even completed one. Unfortunately, the information was pathetic; I'm not sure I actually learned anything useful. There must be good sources out there. Any Soylentils have recommendations?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by VLM on Monday August 03 2015, @11:54AM

    by VLM (445) Subscriber Badge on Monday August 03 2015, @11:54AM (#217356)

    Its VERY old technology, like 20 years old.

    This leads to some significant problems. Before the turn of the century I got a nice new book about the "new ipv6" and its full of now obsolete stuff like how to use and test A6 DNS records. Its unlikely you'll find a windows10 book almost 20 years out of date but it can happen for ipv6. I tried to find the book for laughs on amazon, unsuccessfully. It was published in the late 90s and had a mostly white with lines cover and was not an oreilly or ciscopress book and was not a certification mill book but more of a general topic book. The Ciscopress IOS ipv6 configuration book from '02 was pretty good for a device specific config book, although I'm sure out of date in 2015.

    More than a decade ago I did the hurricane electric "jump thru hoops" certification and back then the first few people thru got a nifty hurricane electric ipv6 tee shirt which I may or may not still have laying around at home. I don't know if they still give out tee shirts or if that was a "first 100" type of thing. It was after the first dotcom crash but more than a decade ago. Its pretty easy to put a ipv6 addrs on a box, but this makes you jump thru the hoops to prove you got everything working at least once on ipv6.

    https://ipv6.he.net/certification/ [he.net]

    For a long time I used HE for a static tunnel on a machine with a static ipv6 addrs and the Sixxs people for a tunnel. Things just work for years at a time with no effort. I assume they're still giving out /48 for free upon request. I'm only using one /64 of my /48. I see my tunnel has been up for 16 weeks, 3 days, and 1 hour.

    For the first time in some years, I checked and my cablemodem is handing out a /64 ipv6 link addrs to me. No ipv6 user space but I've got a link at least.

    For some entertainment you might want to compare the command line "style" "feel" of linux, freebsd, and believe it or not the zebra/quagga IOS like CLI. More than a decade ago I was a paid professional mostly-router guy so the IOS-like CLI of the quagga feels nice. I'm one of those guys with VLANs and OSPF at home, at least formerly, which probably isn't for everyone... "sh ipv6 route" instead of "/sbin/route -A inet6", eh, potato, potatoe, whatever.

    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by VLM on Monday August 03 2015, @12:01PM

    by VLM (445) Subscriber Badge on Monday August 03 2015, @12:01PM (#217359)

    I used HE for a static tunnel on a machine with a static ipv6 addrs

    Err the deal is HE offered very low threshold of effort to set up static ipv6 tunnels only if you had a static ipv4 addrs, so I had a HE tunnel on a server and sixxs was an unholy PITA to set up but works perfectly for dynamic ipv4 endpoint addrs so I had that at home on my screaming new 608K DSL line back in the very early 00s.

    I have no idea in 2015 if that is the ideal design, but back in the old days thats how it was.

    Over the last decade occasionally there have been routing spats or instability or other VERY short term issues between HE and sixxs so occasionally I'd have ssh/fetchmail issues accessing that server from home, have to force ipv4 temporarily or just deal with it.

    I would not be surprised if sixxs were less of a PITA or HE now has a dynamic endpoint ipv6 tunnel, or there are alternative providers. Some may be lucky enough to have an ISP that actually offers native ipv6 connectivity, so no tunnel providers needed!

  • (Score: 3, Interesting) by Hyperturtle on Monday August 03 2015, @12:18PM

    by Hyperturtle (2824) on Monday August 03 2015, @12:18PM (#217366)

    I like how the original IPV6 was designed for, what shall we call it... "security", and took consideration for issues still vexing modern communications (it was not a cure-all, of course -- but it did help get the hosts a few more defenses in how the protocol behaved).

    Probably around 2002 or 2003 I think, after the internet economy crashed at least, I couldn't help but notice the shift in direction the protocol was taking. Now, the importance is shifted towards how to best send multicast (or video, I guess) signals to anyone wanting to join a multicast group (change channel on TV) and get a feed.

    Well, it is not that horrendous. However, and I can't cite anything at the moment and the internet is big for me to remember sites that aren't up anymore and I am merely commenting on 12 or 13 years of observation... IPV6 is not the same protocol that it was 20 years ago. They used to state that IPV6 was designed for security from the ground up. No one says that anymore.

    It may be old, but someone had designs on the design process and gutted the end-to-end security capablility/the hooks to make it easier to use encryption.

    Those older books are worth reviewing, if only to learn what it could have been and how the world may be different if the goals were not changed.

    • (Score: 1) by pTamok on Monday August 03 2015, @12:51PM

      by pTamok (3042) on Monday August 03 2015, @12:51PM (#217376)

      They used to state that IPV6 was designed for security from the ground up. No one says that anymore.

      It may be old, but someone had designs on the design process and gutted the end-to-end security capablility/the hooks to make it easier to use encryption.

      I wonder who that might have been?

      But seriously, in the context of all the current brouhaha around security and intelligence services' ability to intercept communications, I would not be surprised if it turns out it was on their collective agendas to 'gut' the security capability of IPv6.

      • (Score: 3, Insightful) by VLM on Monday August 03 2015, @01:12PM

        by VLM (445) Subscriber Badge on Monday August 03 2015, @01:12PM (#217381)

        The history of ipsec in ipv6 mirrors the history of ipsec in general or in ipv4, in that I feel it was intentionally F-ed up and made into a hard to use mess of a technology which made ipsec useless in general. That has a side effect of making it completely uninteresting to the first two decades of ipv6 early adopters, but thats because ipsec with 40 bit des keys and all that BS is pretty much useless and a waste of time, in general, everywhere, not a conspiracy in ipv6 itself.

        Maybe by analogy W2K used to be a popular OS in the early days of ipv6, but no conspiracy was necessary to ditch W2K by 2015.

        There could be conspiratorial aspects of "here's a shitty VPN technology, the worst out there, so lets product tie it deeply into ipv6 as "the" security technology for ipv6, such that when the hivemind trashes IPSec in general, ipv6 will have no security theater at all, and better yet will not have a generic universal crypto layer that might have actually worked."

        I'm not sure encrypting the line really gives you anything now a days anyway. You can assume the endpoints are both owned by .com and .gov and .cn and .ru and probably others, so decrypting data off the line is a total waste of computational effort. Maybe not writing endpoint code full of exploits would have saved more traffic than inserting weak security theater. Meanwhile if you're actually doing something important you'd need a secure well written VPN system anyway instead of some PoS totally powned OS layer, or you implement it at the app level like websites over SSL aka https. I'm not convinced it belongs in the feature list at that layer, and the marketplace in general seems to agree.

        Putting ipsec in ipv6 20 years ago was just an architectural mistake. It doesn't belong at OSI layer 3 in OS driver code.

        • (Score: 2, Interesting) by pTamok on Monday August 03 2015, @01:33PM

          by pTamok (3042) on Monday August 03 2015, @01:33PM (#217390)

          The implementation may have been flawed, but I'm not convinced it is an architectural mistake to try and 'bake-in' security. It depends on what you are baking in, and how flexible it is e.g. with the ability to change to new encryption algorithms.

          I come from the school of 'the network should be dumb and the end-points intelligent', but I have considerably modified my position in the face of reality and realise it is a bit more complicated than that. Link-based encryption is only really as good as the management of the keys, but in general having something that discourages casual interception is not a bad idea. After all, we have gone from open WiFi to WEP to WPA: if encryption were purely an end-system requirement, none of that would have developed.

          • (Score: 3, Interesting) by VLM on Monday August 03 2015, @04:11PM

            by VLM (445) Subscriber Badge on Monday August 03 2015, @04:11PM (#217440)

            After all, we have gone from open WiFi to WEP to WPA: if encryption were purely an end-system requirement, none of that would have developed.

            That's primarily to stop people from freeloading on my wifi, using up my transfer cap, illegal downloads.

            If there were a simpler way to keep people off my wifi, then the complicated crypto stuff wouldn't get used.

  • (Score: 0) by Anonymous Coward on Monday August 03 2015, @09:14PM

    by Anonymous Coward on Monday August 03 2015, @09:14PM (#217590)

    I'll second the recommendation of https://ipv6.he.net/certification/ [he.net] I did it a couple years a go and, yes, they mailed me a t-shirt. :-) It is all _very_ basic stuff: configure a machine for ipv6, set up DNS, a web server and a mail server on that machine so they answer to outside ipv6 requests. Still a very useful first poke at v6 since it lets you play with the protocols in a connected way, not just in a lab environment.