Thank you for this introduction. On Sun, Jan 30, 2022 at 02:14:37PM +0000, Simon wrote: > Joel Roth via Dng <[email protected]> wrote: > > > My problem is connecting via dhcp over ethernet. On IRC > > I was advised to try > > > > ping ff02::1%eth1 > > > > which fails to get a response, indicating IPv6 is not enabled in my client. > > > > I tried setting "iface eth1 inet6 dhcp" in /etc/network/interfaces, > > then "ifup eth1". This fails with > > > > no link-local IPv6 address for eth1 > > > > References suggest that "ifconfig eth1 up" or "ip link set dev eth1 up" > > will trigger the kernel to assign an IPv6 address. Since > > this is not happening, I'm asking the wisdom of the list VUAs > > how to enable IPv6 for this port. > > You don’t actually need DHCP to configure IPv6. > By default, I think every major OS these days enables IPv6. When an interface > connects (link comes up), the device will solicit for routers on the network > - both actively by sending RS (Router Solicit) packets to trigger routers to > send RA packets, and passively by looking for RA (Router Advertisement) > packets that are sent periodically anyway. > Each RA lists all the network prefixes (IPv6 prefix is roughly analogous to > subnet number in IPv4) the router supports on that interface. Note that an > arbitrary number of prefixes are supported, and devices can have "many" IPv6 > addresses. Each prefix is accompanied by a number of flags - the key ones > here being whether autoconfig is supported (A flag) and whether the prefix is > managed (M flag), defaults normally being A set and M clear. > > With A set and M clear, devices will use SLAAC (StateLess Address Auto > Configuration) to create at least one address for itself in that prefix - > these days by randomly generating an address in a 64 bit range. For partly > historical, and partly philosophical reasons, SLAAC only works with 64 bit > prefix lengths, leaving 64 bits for the host address part. The device can > create multiple addresses, and change then as often as it likes. > This roughly analogous to the address autoconfig feature in IPv4 using the > 169.254/16 address ranges - except that with IPv6 the addresses are useful > for more than just the local network. > > NOTE: You will often see comments along the lines of “but the address is just > an extension of the MAC address meaning ...”. This was an early idea, but for > privacy reasons was dropped a looooong time ago and AFAIK no modern OS uses > it by default - whether they can be configured to use it I don’t know, but it > was deprecated a long time ago and it is strongly recommended not to use it. > > So that’s the most common network setup : each router (more than one can be > present) will advertise prefixes to be used on the network, and devices will > automatically configure their own addresses. This will generally work out of > the box once there is a router with the right IPv6 support connected to an > ISP that provides IPv6 support in their network. > > Note that none of this involves DHCPv6 - and in fact, adding a DHCPv6 service > to the network won’t have any effect. For this to work, the (IIRC) M flag > needs to be set in at least one RA. This signals to the clients that this ia > a managed network and they should use DHCPv6 to obtain some information. DHCP > doesn’t inform of IPv6 prefixes - these are still the preserve of RAs. > Setting the M flag for a prefix will involve configuration on the router. > > For completeness, another new concept in IPv6 is whether a prefix is “on > link”. In simple terms, if the prefix is on-link then a device can talk > directly to another device using addresses in that prefix - as is normally > the case with ethernet networks. However, there are some networks (wireless > networks with client isolation, some “locked down” secure networks, ...) > where this is not the case - where an intermediary (router) is needed to get > packets from one device to another - having the prefix flagged as no on-link > will trigger devices to send packets via the router even for addresses that > are in the same prefix. > > > Given the number of major ISPs (e.g. Sky and BT in the UK) who have turned on > IPv6, this autoconfig makes a huge proportion of users IPv6 enabled - and > mostly they’ve never noticed ! > > > And a note about Android. For mobile use, prefixes can change frequently as > the phone moves about. DHCP isn’t good at handling this, whereas it’s easy to > send out an RA with a new prefix and deprecating the old one by setting the > lifetime to a very short value. > Apart from the mobile use case, they also seem to think that no network > operator should be able to control the devices on the network - with DHCP > being seen as a tool for oppression and monitoring of devices. Never mind > that in some sectors, such control and monitoring is a legal requirement, or > needed to enforce security policies. > As a result, it would appear that Google have a policy of not supporting DHCP > in Android - and even go so far as to “encourage” the hardware vendors of the > chipsets to filter DHCP packets at the hardware level, thus blocking third > party software from working. As a result of this, a network cannot disable > SLAAC and use DHCP without breaking Android devices - and so persists a > situation where some people want to add everything from DHCP into RAs because > DHCP "doesn’t work”. > > > Steve Litt <[email protected]> wrote: > > > On my next router, (probably OpenBSD/pf), I'm going to block all IPV6. > > I enjoy that the badguys have to jump through one more hoop (NAT) to > > hit me where it hurts. > > NAT doesn’t really offer much by way of security - the “everything appears as > one IP address” being the only feature I can think of. A stateful firewall > will give you the same level of security for IPv6 as it does for IPv4. > With IPv6 however, you gain the ability to hide like a matchstick in a very > large forest. The MINIMUM address range an ISP can give you is a /64 prefix, > giving you 2^^64 addresses to play with - and as above, by default devices > will pick random addresses within this range. That’s a MINIMUM of 2^^32 times > the entire address space of the IPv4 internet all to yourself ! > > That’s the minimum. Recommendations are for ISPs to delegate at least a /56, > and preferably /48 - that gives you 256 (2^^8) or 16636 (2^^16) /64 prefixes > to do with as you like. So trivially easy to have separate prefixes for > multiple wired networks, WiFI SSIDs, etc, etc. All with global addresses - > just configure your firewall to allow/drop traffic according to your > requirements. Unfortunately, it appears some ISPs can’t shift the “addresses > are scarce” mentality, and offer only the minimum of a single /64. > > In terms of privacy, it simply changes from “everything behind one address” > to “everything behind one prefix and using random addresses that change > periodically”. Even if someone knows your prefix, they need to scan 2^^64 > addresses to find your devices (that’s assuming your firewall allows inward > connections) - and by the time they find an active address, it’s probably > changed. > Of course, where you want something to be externally accessible, that’s just > a matter of configuring a fixed address and opening a corresponding firewall > rule - you don’t need to configure NAT port forwarding as well as, and you’ve > plenty of addresses to run multiple servers/services on the same port(s), > something not easy when you’ve only one IPv4 address. > > > I'm not an authority on firewalls and routers, but I'm going to try > > hard to pass only a very few IP addresses on my LAN, and put the Wifi > > on a third network card. > > That’s easy enough to do. Get a switch that supports VLANs and you can > segregate traffic to multiple wired segments without needing multiple cards > in your server/router. > > > In my opinion, IOT (the Internet Of Things) is for the most part an > > abomination. I don't want my thermostat on the same subnet as my LAN. > > Agreed there. > > > > As an aside, and not specifically in response to either of the above emails, > I recommend the certification scheme run by HE at > https://ipv6.he.net/certification/, and if your ISP doesn’t yet offer IPv6, > then their tunnel service will provide you with good IPv6 connectivity. It’s > true that there is some learning you need to do for IPv6, but this course > will take you through things in steps - start with the basics and work up to > the more complicated stuff. The only bit I thought was a p.i.t.a. is a stage > where you have to provide ping and traceroute results to 100 different IPv6 > destinations over 100 days. The hardest part if finding 100 different > destinations - at the time I did it, I did some grepping of DNS server logs > at work to find them ;-) > > > > Simon > _______________________________________________ > Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- Joel Roth _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
