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
