simple DHCPv6 config with /56-Prefix

[Walter H.]

On 22.08.2022 20:34, Simon wrote:
> Adam Nielsen <a.nielsen at shikadi.net> wrote:
>
>>> This is not true in the IPv6 world. All it needs is for a router to
>>> advertise that both prefixes are on-link and the hosts can
>>> communicate directly. This is one area where IPv6 is fundamentally
>>> different (better) than IPv4. For completeness, a router can
>>> advertise that a prefix is not on-link - meaning that communications
>>> between hosts in the same prefix must communicate via the gateway.
>>> This can be the case in some non-broadcast networks, or networks
>>> where device-device direct communications is blocked (e.g. for
>>> privacy/security in public WiFi).
>> Very interesting, I didn't know that, thanks for the explanation!
> 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?

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?/

/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;/

/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/

/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 ...

on the firewall e.g. I would block outbound ports 25, 465 or 587 to 2001:db8:0:180::/64
because the proxy mustn't  send mails; but it would be allowed for ports 80 or 443
on the other side I would allow outbound ports 25, 465 or 587 only to 2001:db8:0:1e0::/64
because the mail servers  are the only that should send mails;

and the DHCP clients I would give a different profile;

but the DHCPv6 clients don't get /56 as prefixlength, they get /128, why?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220825/ca992e13/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3550 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220825/ca992e13/attachment.bin>