Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
>> We are already 90% of the way here: Make IA_PD work for hosts, not >> just for routers. That way Android handsets can have as many addresses >> as they want. > > You mean e.g. support IA_PD at CPEs on the LAN side? I'd like IA_PD to work both CPEs on the LAN side, and I'd like it to work for hosts. Steinar Haug, AS2116
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
>> We are already 90% of the way here: Make IA_PD work for hosts, not >> just for routers. That way Android handsets can have as many addresses >> as they want. > > DHCPv6 PD is one of the means suggested by RFC 7934, yes. I'm not sure that > the folks asking for IA_NA would be happy with IA_PD though. The reason > most often cited for wanting DHCPv6 is that it fits well with tracking > practices and systems that are built to support on-request addressing and > networks assigning individual IP address(es) to devices. DHCPv6 PD provides > request-based addressing, but it wouldn't do much to interoperate with > those tracking systems because they deal with addresses, not subnets. From > that perspective, ND snooping might be more likely to interoperate well. Well, I work for one othe ISPs who would *love* to use DHCPv6 PD. Yes, we'd have to make some modest changes to systems to handle prefixes instead of individual addresses. But we'd be happy to just track IPv6 prefixes and *not* have to track individual addresses. Our estimates is that the work to incorporate such a change (handling IPv6 prefixes) would be significantly less than doing ND snooping and similar in all relevant boxes and systems. YMMV. Steinar Haug, AS2116
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
> There are several reasons that people shout about DHCPv6: ... > - politics: probably the most contentious area. One well-known example > - is how ipv6 on cellular impacts carrier vs handset control > - politics. 3GPP specifies that the ppp context for tethering must > - support SLAAC and therefore it provides a /64 for LAN > - connectivity. This means that the handset applications have as much > - address space as they need. The argument goes that if DHCPv6 were a > - viable option for this, then the mobile operators would effectively > - wrestle control of the applications running on the handset (and > - ultimately control of the handset capabilities itself away from the > - handset software vendors) by handing control of the number of > - available IPv6 addresses to the cellular operator. This is, at least, > - the reason cited by the Android authors for the point-blank refusal to > - implement DHCPv6 in android (bug ID 32621). We are already 90% of the way here: Make IA_PD work for hosts, not just for routers. That way Android handsets can have as many addresses as they want. Steinar Haug, AS2116
Re: question regarding over the counter devices
> > IPv6 firewall non-on by default. I$,1ry(Bve not seen that myself in any > > product up to now. > > How many products have you looked at? We're still talking about home > routers now, right? I was commenting on "all the IPv6 OSs *for hosts and servers*, have the IPv6 firewall on by default" (my emphasis). This would seem to include all the BSD variants, all the Linux variants, etc. And in that case, the statement "IPv6 firewall on by default" is clearly not true. Steinar Haug, AS2116
Re: question regarding over the counter devices
> However, I believe that all the IPv6 OSs for hosts and servers, have the IPv6 > firewall on by default, so this should not be a big issue, unless you have > other devices with no IPv6 firewall (IP cameras?), which I think is not > common, because those devices (what I$,1ry(Bve seen up to now), only > respond to the port that they have designated to work on. FreeBSD, at least until 11.0-STABLE: No IPv6 firewall turned on by default. Which is exactly what I want. Steinar Haug, AS2116
Re: Linux and ULA support and default route
> At the end, the whole behavior is because some host have problems in > handling situations where they have an IPv6 address configured and now > internet connectivity. But the solution to this requires that the host > is able to understand and work with RIO options, which seams to be "at > the time" not generally the case. > > Do we replace one evil by another? I like Tore's solution of using ULA for local communication even when the external link is down. Steinar Haug, AS2116
Re: IPv6 Dynamic Prefix Problems
> > 1) Many DNS changes for services behind the dyn prefix (not all devices > > are able to update DNS records) > > 2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range > > in other firewall policies?) > > 3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not > > optimal?) > > 4) Prefix Translation > 5) Use a SIXXS / HE Tunnel > 6) Paying extra for static prefixes (if even possible) > > There are several theories about why they change the prefix: > > a) customer demand (privacy) > b) we have always done it this way > c) as with v4 we can sell static addresses We run dynamic IPv4 allocation for our residential customers (and any business customer which wants it) - and we *don't* actively change the allocated address. As long as the customer sends a DHCP request from the same MAC address (or client identifier), the customer would normally get the same IPv4 address. We expect to use the same policy for IPv6 - i.e. there are no plans to *actively* change IPv6 address / prefix. Steinar Haug, AS 2116
Re: Some very nice broken IPv6 networks at Google and Akamai
I'm not a native speaker of English, but I struggle to understand it any other way than you're saying there's something broken about Yannis' deployment. I mean, your reply wasn't even a standalone statement, but a continuation of Yannis' sentence. :-P That statement is correct though. As Google and Akamai IPv6 are currently broken, enabling IPv6 thus breaks connectivity to those sites. Not enabling IPv6 thus is a better option in such a situation. I'm afraid I don't see the supporting evidence here. From my point of view, Google and Akamai IPv6 both work just fine. I happen to be in Norway, just like Tore - but we are in different ASes and as far as I know we also use different Akamai and Google cache instances. No specific problems that I can see. Steinar Haug, AS 2116
