[HN Gopher] IPv6-only Network based on Jool
___________________________________________________________________
IPv6-only Network based on Jool
Author : unclet
Score : 67 points
Date : 2025-01-06 05:24 UTC (17 hours ago)
(HTM) web link (taoshu.in)
(TXT) w3m dump (taoshu.in)
| NewJazz wrote:
| Doesn't openbsd do this without out of tree kernel modules? I'm
| kind of allergic to dkms and friends.
| j16sdiz wrote:
| OpenBSD do stateless NAT64. You can do the same on linux using
| Tundra in userspace.
| zorked wrote:
| Why do I need to even think about entering a contractual
| relationship with "13 TCF vendor(s) and 64 ad partners" before
| reading a blog post? The subject sounded interesting but the lack
| of respect for me is enormous.
| rnhmjoj wrote:
| Just read the Jool documentation which is vastly superior: http
| s://nicmx.github.io/Jool/en/documentation.html#introduct....
| gertrunde wrote:
| Not sure I entirely agree with :
|
| _" Here is the classical topology of home network." ... "And all
| the LAN hosts have one /64 IPv6 prefix."_
|
| Are people really deploying IPv6 like this? Rather than a /64 to
| a vlan?
|
| (Personally, in the home, I'm just using DHCPv6-PD to delegate a
| different /64 to each VLAN).
| rfoo wrote:
| Or maybe a "classical" (I assume author meant "typical"?) home
| network does not have multiple VLANs.
| gertrunde wrote:
| Agreed.
|
| But the topology given in the article shows three separate,
| non-overlapping /64s, one for each host/router. (Although one
| would assume that the router at least must have an interface
| in each subnet, even if that's not what the diagram shows).
|
| One might hope these would be on separate VLANs, as
| overlaying multiple subnets on one VLAN would be a bit iffy.
| I've not spotted anything in the article other than the
| diagram to detail interface configs.
| tsimionescu wrote:
| Who has multiple VLANs in a home network??
| tikkabhuna wrote:
| Definitely the realm of homelabbers, but I do. Mainly to
| segregate IoT devices, users, lab servers.
|
| That is only because I want to though, I agree that the
| average home network will not have VLANs.
| sgjohnson wrote:
| I don't think an average home user even knows what a VLAN is.
|
| This, on the other hand, is Hacker News.
| ta1243 wrote:
| HN has a surprisingly low level of network knowledge
| compared to sites a generation ago (slashdot etc)
| stephen_g wrote:
| I have my main VLAN, a guest VLAN, and one for any
| 'smart'/IoT devices that need to connect to cloud services.
| Each is firewalled from each other and each has its own
| separate WiFi SSID.
|
| Not just because the IoT devices are prone to attack because
| they may not get many updates, but also because they often
| need 2.4 GHz or may only support WPA 2. So my main network
| can be WPA3 only and 5 GHz only but the other networks are
| more lenient.
| jeroenhd wrote:
| My router configures a VLAN for guest network access, and
| that's a normal consumer Fritz!Box. I think other brands do
| the same.
|
| People may not know they're running a VLAN, but VLANs aren't
| uncommon either.
| simoncion wrote:
| I have multiple VLANs on my home LAN. It's just so much
| easier to provide no-Internet or isolated-from-all-other-non-
| guest-hosts service if you set that up via VLANs. I _might_
| be mistaken, but it 's my pretty strong understanding that
| with everything on the same VLAN, you have to deal with hosts
| using MAC and/or IP address spoofing to evade your router
| firewall rules. [0]
|
| [0] Because what else would you use to decide how to block or
| permit traffic if you can't distinguish by the interface that
| the traffic came in on?
| sgjohnson wrote:
| NAT64 covers most of the cases. However, in my homelab
| experiements I very quickly found out that IPv4 literal addresses
| are a bit problematic for me.
|
| There are ways to fix that with 464XLAT/CLAT, but I never got
| around to deploying it.
|
| These days I'm just running dual-stack, with no NAT64. I hate NAT
| with a burning passion, so adding another layer of stateful NAT
| is a bit of a net negative in my eyes.
|
| Someday I'll go full IPv6 on my home network with 464XLAT. And
| then I'll realize that some stupid IoT device or something is not
| CLAT aware. Obviously there are solutions around that too, but
| they require an intermediate device.
| ay wrote:
| If you have NAT64, DNS64 and use "IPv6-mostly" option 108 on
| DHCP, then CLAT will be activated on supporting devices
| automatically - and then you can turn the dhcpv4 off when you
| see no leases on it :-)
|
| By now there is a fair amount of material, eg:
|
| https://indico.cern.ch/event/1274792/contributions/5444353/a...
| eqvinox wrote:
| Nit: you still need DHCPv4 to send 108 ;)
|
| But also CLAT should turn on if a PREF64 is known and no IPv4
| is available, regardless of 108.
| idatum wrote:
| I resigned myself to the fact that IoT crappy devices will
| always exist and I isolated these to their own VLAN with
| IPv4-only (maybe I'll go dual-stack at some point).
|
| Yes, VLANs add complexity -- even the obligatory IoT VLAN --
| but I generally want to keep these IoT devices isolated anyway.
| throw0101a wrote:
| The UK IPv6 Council has a bunch of videos on running
| IPv6-mostly/only networks:
|
| * https://www.youtube.com/@ukipv6council468/videos
|
| This includes at academic institutions where it's basically all
| BYOD so they have to deal with a more 'random' assortment of
| systems:
|
| * https://www.youtube.com/watch?v=2B-liebzcOM
|
| And enterprise networks, like Jen Linkova at Google:
|
| * https://www.youtube.com/watch?v=hb98hAb5_W8
|
| Jen also had a presentation recently (2024-11) at RIPE87,
| "Mission Possible: How Google Plans to Turn Off IPv4!", where
| they've managed to reclaim 300K IPv4 addresses:
|
| * https://www.youtube.com/watch?v=UTRsi6mbAWM
|
| She's currently co-chair of the IETF IPv6 Maintenance (6man)
| working group.
| throw0101d wrote:
| See also perhaps "IPv6-mostly on OpenWRT" from RIPE 87:
|
| * https://www.youtube.com/watch?v=GZ6pxh6ukCg
|
| * https://ripe87.ripe.net/archives/video/1136/
|
| * https://ripe87.ripe.net/wp-content/uploads/presentations/8-I...
|
| Ansible roles:
|
| * https://github.com/oskar456/ansible-openwrt-ipv6-mostly
| fulafel wrote:
| It's not immediately clear from the page but this is a NAT style
| hack for people who don't have normal IPv6 connectivity, and
| NAT'ed connectivity is inferior to native.
| eqvinox wrote:
| You either mistyped IPv4 as IPv6 or misunderstood the setup.
| There is native ("normal") IPv6, but no IPv4 except on the
| NAT64 host. Since IPv4 is almost always NATed for end hosts,
| it's not inferior in any way.
| fulafel wrote:
| So it seems, I stand corrected.
| eqvinox wrote:
| It should be noted in-network DNS64 is a fallback for situations
| where end devices don't have native support for NAT64 (either
| with a CLAT or with local DNS64). (Network side DNS64 breaks
| DNSsec)
|
| RedHat is working to get CLAT on regular Linux hosts, where it
| has been direly missing.
| elnappo wrote:
| Would love to enable NAT64 on my OpenWRT router, sadly setting up
| Jool on OpenWRT feels to hacky to me. Based on option 2 described
| here: https://openwrt.org/docs/guide-user/network/ipv6/nat64
| evanjrowley wrote:
| I would love to do something like this except Verizon only
| provides IPv4 in my area. Some of the. Workarounds, like IPv6
| tunnels, seem to have big drawbacks like being blocked by major
| providers.
|
| I wish it were possible to force major operating systems to
| prefer IPv4 over IPv6, which might be a viable workaround to a
| less reliable IPv6 workaround, but such a configuration appears
| to be unfeasible for mobile phones, Windows, and perhaps MacOS
| too.
| LorenDB wrote:
| I read Jool and expected something in Kerbal Space Program. For
| example, here's some network setup around Jool:
| https://youtube.com/watch?v=n2eBwgW6sig
| ipython wrote:
| I have to admit, at first read I thought the headline was
| referring to the e-cig Juul and I was scratching my head
| wondering how one could build an ipv6 mesh network out of vapes.
___________________________________________________________________
(page generated 2025-01-06 23:02 UTC)