Differences

en:dividing-the-indivisible [2013-04-01 10:30 UTC] rm		en:dividing-the-indivisible [2021-09-08 20:23 UTC] (current) rm
Line 1:		Line 1:
-	====== Dividing the indivisible ======	+	====== Dividing the Indivisible ======
		+	//Initially published on 2013-04-01.//
	===== How to live with a /64, if that's all they gave you? =====		===== How to live with a /64, if that's all they gave you? =====
	The "proper" approach would be to call up the provider and ask for more; there is no reason to limit IPv6 assignments to end-users to just a single /64, and in fact the current best practices document ([[http://www.rfc-editor.org/rfc/rfc6177.txt|RFC 6177]]) recommends "**giving home sites significantly more than a single /64**".		The "proper" approach would be to call up the provider and ask for more; there is no reason to limit IPv6 assignments to end-users to just a single /64, and in fact the current best practices document ([[http://www.rfc-editor.org/rfc/rfc6177.txt|RFC 6177]]) recommends "**giving home sites significantly more than a single /64**".
-	But what if changing the ways of your provider does not seem to be a feasible option, but you still want to have at least a semi-comfortable experience (i.e. not being forced to bridge everything into one L2 LAN)?	+	But what if changing the ways of your provider does not seem to be a feasible option, and you still want to have multiple physical networks with at least a semi-comfortable experience (i.e. not being forced to use DHCPv6 on every device, or bridge everything into one L2 LAN)?
	This simple HOWTO explains how you can have one "primary" network with functional SLAAC, and an arbitrary (16 in my example) number of "secondary" networks, where only DHCPv6 will be available. Full two-way routing between all these networks will work without any issues.		This simple HOWTO explains how you can have one "primary" network with functional SLAAC, and an arbitrary (16 in my example) number of "secondary" networks, where only DHCPv6 will be available. Full two-way routing between all these networks will work without any issues.
		+
		+	Why bother trying to combine SLAAC and DHCPv6 networks, and not simply split the /64 into several smaller subnets and use DHCPv6 everywhere? Because I believe it is convenient to retain **at least one** network with SLAAC, I imagine this would be your main private LAN, where majority of your computers and other devices are, so that you can enjoy the convenience of SLAAC without needing to set up DHCPv6 clients on all of those.
	===== Network configuration =====		===== Network configuration =====
-	Let's assume we have the following.	+	Let's assume we have the following on the router.
-	| IPv6 routed subnet from the provider: |  ''2001:db8:abcd:cdef::/64''  |	+	| An IPv6 subnet from the provider: |  ''2001:db8:abcd:cdef::/64''  |
-	| One primary internal interface, where we want SLAAC to function:  |  ''eth0''  |	+	| NIC on the primary internal network, where we want SLAAC to function:  |  ''eth0''  |
-	| Three (or more) secondary internal interfaces, which also \\ need IPv6, but they will have to live without SLAAC:  |  ''eth1'', ''eth2'', ''eth3''  |	+	| NICs on three (or more) secondary internal networks, which also \\ need IPv6, but these will have to live without SLAAC:  |  ''eth1'', ''eth2'', ''eth3''  |
	What we do is...		What we do is...
Line 21:		Line 24:
	Let's say this network will be ''2001:db8:abcd:cdef:ffff:ffff:fff0::/108''.		Let's say this network will be ''2001:db8:abcd:cdef:ffff:ffff:fff0::/108''.
-	But if hosts on the main LAN assume they have the /64 directly accessible on-link, how will they know they need reach some subnets that are technically within it, via the router?	+	But if hosts on the main LAN assume they have the /64 directly accessible on-link, how will they know they need to reach some subnets that are technically within the /64, via the router?
-	The answer is: from a more-specific route in RAs!	+	**The answer is: from a more-specific route in RAs!**
	===== On the router =====		===== On the router =====
Line 59:		Line 62:
	AdvSendAdvert on;		AdvSendAdvert on;
	AdvManagedFlag on;		AdvManagedFlag on;
-	prefix ::/112 { };	+	prefix ::/112 { AdvAutonomous off; };
	};		};
Line 65:		Line 68:
	AdvSendAdvert on;		AdvSendAdvert on;
	AdvManagedFlag on;		AdvManagedFlag on;
-	prefix ::/112 { };	+	prefix ::/112 { AdvAutonomous off; };
	};		};
Line 71:		Line 74:
	AdvSendAdvert on;		AdvSendAdvert on;
	AdvManagedFlag on;		AdvManagedFlag on;
-	prefix ::/112 { };	+	prefix ::/112 { AdvAutonomous off; };
	};		};
	</file>		</file>
Line 78:		Line 81:
	Simple.		Simple.
	* ''eth0: 2001:db8:abcd:cdef::1/64''		* ''eth0: 2001:db8:abcd:cdef::1/64''
-	* ''eth1: 2001:db8:abcd:cdef:ffff:ffff:fff1::1/112''	+	* ''eth1: 2001:db8:abcd:cdef:ffff:ffff:fff1:1/112''
-	* ''eth2: 2001:db8:abcd:cdef:ffff:ffff:fff2::1/112''	+	* ''eth2: 2001:db8:abcd:cdef:ffff:ffff:fff2:1/112''
-	* ''eth3: 2001:db8:abcd:cdef:ffff:ffff:fff3::1/112''	+	* ''eth3: 2001:db8:abcd:cdef:ffff:ffff:fff3:1/112''
-	===== Downsides =====	+	===== On the clients =====
-	The clients on eth1/2/3 will constantly complain into 'dmesg' about "IPv6 addrconf: prefix with wrong length 112". This is harmless and can be ignored.	+	On the GNU/Linux clients connected to the "primary" LAN, the following change may be required for them to start accepting the extra more-specific route:
-	===== Address collisions? =====	+	<file>echo 108 > /proc/sys/net/ipv6/conf/[INTERFACENAME]/accept_ra_rt_info_max_plen</file>
-	Hosts from your primary LAN assume that the whole /64 is their own personal playground, and that they can pick any address they want. In theory this can lead to address collisions with some hosts on your secondary networks. But in practice chances of this is astronomically low.	+
-	- We ruled out possibility of collision with a EUI-64 address by using ''...ff:ff...'' in the middle of our /108 (those will always have ''ff:fe'');	+	===== Address collisions? =====
-	- The probability of "Privacy Extensions" address suddenly having ''....ffff:ffff:fff...'' in it, is... well, calculate yourself, seems pretty low too.	+	Hosts from your primary LAN assume that the whole /64 is their own personal playground, and that they can pick any address they want. In theory this can lead to address collisions with some hosts on your secondary networks. But:
		+	- We have ruled out the possibility of collision with a EUI-64 address by using ''ff:ff'' in the middle of our /108 (those will always have ''ff:fe'');
		+	- The probability of a "Privacy Extensions" address suddenly having ''ffff:ffff:fff'' in it, is... well, calculate yourself, seems "pretty low" to me.