Live data from Hacker News

Building a Mostly IPv6 Only Home Network

varunpriolkar.com

101–106 of 106 posts

Re: Building a Mostly IPv6 Only Home Network

#101
post #97
post #83

Earlier quoted context omitted.

> using a static v6 block, not only would this address never change, each device in my LAN would have an extra identifier attached to it. This is not true. IPv6 stack allocates at least 3 addresses: - Link-local - "Permanent" Address derived from the subnet and MAC - Temporary address that changes several times per day The default address for new connections is always the temporary address. So IP-based tracking from…

Ah, handy! Though it can't always be true, at least for manual configuration ;-) I have two VPSes with v6 addresses (the others don't have it configured...), and both only have LL and their permanent Internet addresses. My understanding is v6 has two different autoconf schemes, DHCPv6 and a more "native" solution. Do these both always result in interfaces having multiple (routable) addresses? Most of my IPv6 experien…

Man... I typed that reply on my phone and dropped the ball formatting it lol.

> My understanding is v6 has two different autoconf schemes, DHCPv6 and a more "native" solution. Do these both always result in interfaces having multiple (routable) addresses?

The answer to that is "yes," but only insofar as DHCP is _not_ the norm for IPv6 networks. If you're planning to use DHCP to assign network addresses in an IPv6 range, you would run it in addition to using automatic configuration, and DHCPv6 would be responsible only for the "permanent" IPv6 address. Automatically-configured addresses (via RA with SLAAC or whatever) would still create the temporary address that you'd use for outbound internet connectivity, and the DHCP address hangs around for your use in DNS and for hosting "permanent" services like a webserver or whatever.

You've hit on one of the subtler problems of IPv6 being that it requires more things being let through the edge firewall[0], but given a stateful IPv6 firewall on the client side, the onus is on the hosting service's admin to ensure that works correctly (AFAIK).

[0]: http://shouldiblockicmp.com/

Re: Building a Mostly IPv6 Only Home Network

#102

Do you actually own that /48? The problem with using the globally routable addresses internally is that your public /48 might change in the future, and and that will force you to change a bunch of internal stuff. I have my router set up to advertise two /64 prefixes on each LAN subnet: one from fddd:deca:fbad::/56* that I use for all internal communication, and one from 2001:5a8:xxxx:xxxx::/56 that is only used for t…

> * You're really supposed to pick a random prefix in fd00::/8, but uniqueness only matters if you intend to merge networks with somebody else later, I care more about it being easy to remember. If you don't care about collision resistance, why didn't you pick fd00:: ? That's way easier to remember than that jumble of letters you selected. It's actually my go-to subnet when someone claims that local-only IPv6 address…

fddd:: is easier to type than fd00::

Re: Building a Mostly IPv6 Only Home Network

#103
post #94

Earlier quoted context omitted.

Adding two bytes would have been just as much work as adding 12 bytes, and would have left us with too few addresses rather than too many. The MAC address space is now 64 bits and L3 is necessarily less dense than L2, so 128 bits is the smallest power of 2 where we can be reasonably sure we won't end up with too few addresses. Considering how hard deploying a new L3 protocol is, we're only going to get one shot at it…

Ehm but IPv6 packets still have the L2 layer as well right? Which already includes the MAC address. So that 64 address MAC space is doubled, it's not like you're saving any. It was a pretty arbitrary decision to accommodate the MAC address inside the IPv6 address and these days it's usually randomised anyway for privacy purposes, so the MAC part of an IPv6 packet doesn't have to be the size of the MAC address. L3 has…

The point of L3 is to aggregate hosts into networks, so that routing only has to keep track of network prefixes instead of the individual MAC address of every machine. (The amount of routing updates needed for the latter would scale as something like O(hosts²) which just wouldn't work for large networks, let alone the Internet.)

The aggregation necessarily "wastes" L3 addresses, so if you think you'll have enough machines to justify an L2 address size of n bits then that also implies needing an L3 address size of n+m bits, where m is a number that represents how densely packed your L3 address space is. Anything smaller than that will be too small to handle the full extent of your L2 address space.

RFC 3194 (https://www.rfc-editor.org/rfc/rfc3194.html) suggests we'd want something like 80 bits to handle EUI-64. 128 bits is the next power of 2 up from there.

> It was a pretty arbitrary decision to accommodate the MAC address inside the IPv6 address [...] Sure, it avoids having to implement ARP

You're thinking of SLAAC, which picks the address by slapping the MAC/EUI-64 into the right-hand 64 bits, but this is just a convenient way of picking the address bits. There's no special significance to those bits and you still need to do ARP.

> I'm pretty sure that if we'd just gone for "a couple bytes extra" we'd have long been completely over.

We still can't get people to stop hardcoding socket(AF_INET, ...) or manually crafting sockaddr_in structures. This is the minimum amount of work that will always be needed, regardless of how many extra bits are involved, and even this part hasn't been quick.

Re: Building a Mostly IPv6 Only Home Network

#104
post #75

Earlier quoted context omitted.

Nothing is stopping your router which does RA to also work in tandem with an internal dns server that can do hostnames for you mapped to slaac addresses.

I'm not sure I follow? AIUI, RA lets you tell hosts about a DNS server, and an internal DNS server could have AAAA records pointing at SLAAC addresses, but how would it know what hostnames go to those addresses?

Oof you are right. It seems openwrt does something smart that only works for dual stacked hosts.

Re: Building a Mostly IPv6 Only Home Network

#105

Earlier quoted context omitted.

> Do you actually own that /48? Well. From TFA: So I decided to use Free Range Cloud service provider to lease a /48, which cost me around C$10/year. I also used their tunnel service to then route this over to me. The link embedded in the pull quote is [0], which isn't maximally helpful, but it's useful. Approximately 60 seconds of poking around there brings us to [1], which quotes a "ARIN - /48 IPv6 lease ... Use on…

It's was a rhetorical question, he doesn't own it. And it takes much less than sixty seconds to figure that out: $ whois 2602:fed2:7e02:: ... NetRange: 2602:FED2:: - 2602:FED2:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2602:FED2::/32 NetName: 10VPN-PRIMARY NetHandle: NET6-2602-FED2-1 Parent: NET6-2600 (NET6-2600-1) NetType: Direct Allocation If that VPN provider goes out of business, he probably loses those addresses.

You must be aware that he owns the allocation in exactly the same way you "own" an ARIN allocation? Unless you have an exemption, there are fees that you must pay annually [0]. If you do not pay them, you relinquish your assignment. [1]

There's another sense in which he owns the allocation... the one you constructed in your original question:

  Do you actually own that /48? The problem with using the globally routable addresses internally is that your public /48 might change in the future, and and that will force you to change a bunch of internal stuff.
He's paying his money to get a statically assigned /48.

It's not too surprising that you can't get this information out of a whois invocation. It is -however- a bit surprising that you weren't aware that whois couldn't tell you this.

[0] https://www.arin.net/resources/fees/fee_schedule/#rsp-servic...>

[1] See section 4(c) of https://www.arin.net/about/corporate/agreements/rsa.pdf>

Re: Building a Mostly IPv6 Only Home Network

#106

Earlier quoted context omitted.

I'm pretty sure that you can use both. RAs even have bits to indicate if one is supposed to autoconfigure, [0] hit up a DHCPv6 server for some or all configuration, [1] or both. radvd refers to them as AdvAutonomous and AdvOtherConfigFlag/AdvManagedFlag, respectively. [0] https://datatracker.ietf.org/doc/html/rfc4861#section-4.6.2 > [1] https://datatracker.ietf.org/doc/html/rfc4861#section-4.2 >

You can use both, but I've never found a good reason to at home. The DHCPv6 option for specifying an NTP server might be a good reason to... but even Linux machines ignored it when I tried. Maybe in five years :)

> The DHCPv6 option for specifying an NTP server might be a good reason to... but even Linux machines ignored it when I tried.

Odd.

  option dhcp6.name-servers ;
  option dhcp6.sntp-servers ;
work to get my Linux systems an IPv6 DNS and NTP server (respectively) when I'm using ISC DHCPd and 'dhcpcd'. Perhaps your DHCPd and/or your DHCPc were either misconfigured or badly broken?

It is a little weird to be using the 'sntp' option, but on the systems I have access to, the address passed back to the client is treated exactly the same as the DHCPv4 NTP information. ~Thirteen years ago, one of the ISC DHCP bigwigs seemed to be of the opinion that the DHCPv6 NTP Server Option was "badly broken" [0]. Perhaps that's why the 'sntp' option is used instead.

[0] https://lists.isc.org/pipermail/dhcp-users/2013-June/016882....>

Post reply on HN