Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: simple DHCPv6 config with /56-Prefix (Simon)
----------------------------------------------------------------------
Message: 1
Date: Sat, 27 Aug 2022 20:44:30 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: simple DHCPv6 config with /56-Prefix
Message-ID: <00ae52f6-f213-4f8e-b3b1-0bfa8f0f3...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Walter H. <walte...@mathemainzel.info> wrote:
>>>
>> There?s quite a bit different in IPv6 - it?s not just ?extra address bits?.
>> The opportunity was taken to fix some of the limitations found with IPv4 -
>> such as the assumption that devices have a single address, and there?s only
>> one subnet on each network, and all hosts in a subnet have direct
>> communication. Unfortunately, as many people don?t realise that those
>> problems exist, it?s seen as making it overly complicated.
>>
>> I can recommend the free training available at
>> https://ipv6.he.net/certification/ IMO Hurricane Electric have provided a
>> great resource (including free IPv6 access via a tunnel over IPv4
>> https://tunnelbroker.net/
>> ). If you complete the certification program, you get what my local LUG
>> members decreed to be the geekiest tee shirt ever made :-) Even if you don?t
>> finish it, it worth the effort for the early stages where it introduces
>> various aspects in a staged manner.
>>
> yes, that IPv6 is different in more than just 3 bits from IPv4 is logic; but
> back to me origin intention ...
> my router has the following IPv4 172.16.0.1 with the subnetmask
> 255.255.0.0
> and I configured the dhcp to hand out addresses within this part:
> 172.16.127.1 ... 172.16.127.254
> and of course the DHCP clients got the correct IP, subnetmask and default
> gateway
> now the question: Why do IPv6 clients have a prefix length of 128?
Ah, now there?s another thing that?s different with IPv6 - well not actually
different, but in IPv4 was done differently.
An IP address (v4 or v6) does not itself have a prefix length or subnet
length/mask. This was the case with IPv4, but for reasons I don?t recall, the
two got tied closely together such that you always get a subnet length/mask
with an IPv4 address - and so people believe that you can?t have one without
the other.
This got fixed with IPv6. An address is an address<period> It does not have a
prefix length. However, since IP stacks have been built on the premise that
addresses have a 1:1 relationship with subnets, (AFAIK) all major
implementations have a data structure that includes it.
And we come back to the on-link/off-link determination.
In the IPv4 world, there?s an assumption that addresses within the same subnet
are on-link (nodes can communicate directly), and all other addresses are
off-link (nodes cannot communicate directly). So since the single
subnet/network and single address per interface are assumptions, the separate
elements of addressing packets and determining whether the other end of a
conversation is on the same network ended up being tied together.
In the IPv6 world, it?s different. When a node wishes to communicate with
another node, it looks to see if the remote address is contained with any
prefix advertised in an RA (Router Advertisement) as on-link. If it is, then it
can send the packet directly to the remote node regardless of whether it?s in
the same prefix or not. So you see that there is no value in tying an address
to a prefix - but since IP stacks do just that, you need to provide a value,
and /128 is logical.
Remember that IPv6 is designed for multiple addresses per interface, multiple
prefixes per network, and other than as signalled by flags in RAs, you cannot
assume whether another node is directly accessible just by considering whether
you have addresses in a common prefix.
The prefix length you see attached to IPv6 address IS NOT USED FOR ANY ROUTING
DECISIONS. To re-iterate: two nodes having addresses in the same prefix can?t
necessarily communicate directly; and two nodes with addresses in different
prefixes may be able to communicate directly. This information is not part of
the address, it is signalled by flags attached to each prefix in RAs.
You need to change the mindset from ?is the address in the same subnet? to ?is
the remote address within ANY subnet advertised as on-link for this network?
As an aside, this is doable in the IPv4 world, but it needs manual
configuration of routing tables - none of the standard tools (e.g. DHCP) can do
this, hence most people think it can?t be done. The equivalent of IPv6?s
off-link prefix would be to configure the address with a /32 subnet mask. The
equivalent of IPv6?s multiple on-link subnets is to configure routes for each
subnet as ?via interface? (rather than the more familiar ?via gateway
address?). It will also confuse the next person to come along and work on the
network :D
> why can't I simple tell the DHCPv6 tell to hand out
> 2001:db8:0:17f::1 ... 2001:db8:0:17f:ffff:ffff:ffff:ffff and that the clients
> have the same prefix length as the server itself?
See above, addresses have no prefix length - they are just addresses.
> I just want a little bit less chaos in the way that I structure the adresses
> but not the segments it should be one large network;
OK
> e.g. with IPv4 I would give the mail servers IP addresses from this part
> 172.16.253.1 ... 172.16.253.254
> the proxy server a IP address from this part 172.16.128.1 ... 172.16.128.254
> but all have the same subnet mask 255.255.0.0 and the same default gateway
> 172.16.0.1
OK
> and this I would have in IPv6 too
>
> the router should have
> 2001:db8:0:100::1/56
>
> the mail servers addresses from 2001:db8:0:1e0::1 ...
> 2001:db8:0:1e0:ffff:ffff:ffff:ffff
> the proxy server an address from 2001:db8:0:180::1 ...
> 2001:db8:0:180:ffff:ffff:ffff:ffff
>
> and would have the /56 as prefix length as one big network;
> no splitting in /57, /58, ... or /64 ...
You can do that, you just need to configure your RAs to advertise the single
2001:db8:0/56 prefix - and set the right flags to indicate to clients that this
is a managed network and they need to use DHCPv6 to get addresses.
However, be aware that SLAAC won?t work (properly/at all) on a /56 prefix, and
Android does not support DHCPv6*, so Android devices won?t work on this network
setup.
But also, you can advertise multiple /64 (or /63, or /62, or ...) prefixes
without the nodes needing to use the router to communicate. So you could
advertise :
2001:db8:0:1e0/64, configured as managed (i.e. no SLAAC), and either use DHCP
or manual config for you mail servers.
Ditto for 2001:db8:0:180/64
Provide a SLAAC configured prefix (/64) if you need to support Android devices
Provide a (say) /60 for DHCP configured devices
Configure all these as ?on-link? and the devices can communicate directly just
as they could if you used a single /56.
Lots of options, but you need to ?unlearn? some of the fundamentals you learned
with IPv4 - and that?s hard !
> but the DHCPv6 clients don't get /56 as prefixlength, they get /128, why?
As above, addresses do not have a prefix length, the /128 is simply there to
make it easier to refactor the IPv4 code to handle IPv6
* It?s tempting to say that Google consider it their job to snoop on everyone,
and network operators should not be allowed to - but it?s more subtle than
that. On a managed network using DHCP for address assignment, the network
operator has considerable control and can significantly impact user privacy
(e.g by providing ?static? addresses, or only providing one address instead of
allowing the device to have ?many? and change them frequently). It seems to be
Google?s view that user privacy trumps arguments such as legal requirements in
many jurisdictions to be able to identify who was using an address at a
particular time in the recent past (that?s a requirement placed on UK ISPs, and
it?s common in financial and healthcare settings).
Regardless of the merits of either side of the argument, Google have a policy
that they will not support DHCPv6 in Android, and even actively block third
party implementations (by pressuring chipset vendors to block the packets in
the hardware).
Simon
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 166, Issue 12
*******************************************
