Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
>> Independent of the prefix distribution mechanism, it may be worth revisit= >ing >> having a single /48 for an organisation of 4 employees. > >Sure, but if we start handing out /40s like there's enough of them, >eventually there won't be. I find it weird that the IEEE manages to allocate a unique 48 bit MAC address to each ethernet / wifi interface and that the RIRs would be unable to allocate 40 bit unique numbers to companies with 4 employes. >> So having an address policy that would support a /64 per host makes sense= > to >> me.=20 > >This is, interestingly enough, too big and too small at the same time. Can you eleborate on the too small part. Of course, we are talking about averages. There may be some big VM hosts that may need more. Some simple devices may not need any /64.
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
>So you need to somehow build a prefix distribution mechanism, so people >can have an arbitrary number of PD prefixes in "wherever network they=20 >happen to be". So we're back to multi-level PD, with all the challenges >(firewall rules, ACLs, internal routing, ...). And even then, a /48 >might no longer be sufficient for a company with, say, 500 internal >network segments and 40.000 employees - where it would be extremely=20 >spacious otherwise. Independent of the prefix distribution mechanism, it may be worth revisiting having a single /48 for an organisation of 4 employees. There needs to be way to shield network complexity within a host from the rest of the network. If we don't then limits on what routers can track (ND) can become a limit in what we can do on a host. Even now people are already worried about the number of 'privacy addresses'. So having an address policy that would support a /64 per host makes sense to me. If we assume that hosts have no further structure (i.e., this just requests one or a few /64s) then managing prefixes allocated to hosts is very similar to managing individual addresses. So there is no reason why PD would not work for that. Of course, in a network of routers, PD makes less sense. However in this case, when the network is actually managed, routers get prefixes from some addressing plan, not from an automated mechanism. That leaves homenet as the most complex dynamic case: potentially multiple layers of routers that should configure automatically. However, in the homenet case, the network is typically small enough that keeping track of individual /64s is possible. So PD where each request is a /64 could very well work. (I'm not trying to express an opinion on HNCP here)
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. IA_PD 'works' (for small values of works) for hosts today. The upstream interface of a CPE is defined as a host instead of a router. The big gap in IA_PD is that it doesn't specify how routing is supposed to work. This is fine if IA_PD happens between routers and all routers have a common routing protocol. For IA_PD to hosts, including CPEs, there is a varity of hacks to install the prefix in the FIB of the access router.
Re: Atlas probes and 6to4 [Re: IPv6 ingress filtering]
>I tried to traceroute one of them (Probe #3009) at >2002:568:1047:1:220:4aff:fee0:20ac >and it petered out at 6to4.tyo1.he.net [2001:470:0:17a::2] > >The embedded IPv4 address is 5.104.16.71, which is reachable, >and is indeed the published address of probe #3009, so it does >indeed look like a failure in the return relay path. Probe 3009 doesn't have a default route on IPv6. I can look at other probes if requested. In the context of 6to4, I'm more curious how users would experience broken 6to4. Happy Eyeballs was supposed to hide broken IPv6 in general and the priority of 6to4 address in destination selection should be below IPv4.
Re: juniper weird IPv6 error ICMPs
>> And I'm really curious how to got sizes like 989, 990, 993 >> >> > >Did you check the actual contents of the packets? The contents of the packets look fine. The packets I'm sending contain a bit of data and then zeros. The error ICMPs I get back contain the same data and zeros. That aspect looks okay.
juniper weird IPv6 error ICMPs
Playing with traceroute I noticed that juniper routers send error ICMPs with weird sizes. Did anyone else notice this as well, I can't remember seeing it mentioned anywhere. Here is some tcpdump output: 11:51:14.691810 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::13:0:0:1, length 32 11:51:14.694750 IP6 2001:67c:2e8:13::3 > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, neighbor advertisement, tgt is fe80::13:0:0:1, length 32 11:51:14.694781 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 1, length 1308 11:51:14.697665 IP6 2001:67c:2e8:13::3 > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 989 11:51:14.708090 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 2, length 1308 11:51:14.710634 IP6 2001:67c:2e8:13::3 > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 989 11:51:14.721396 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 3, length 1308 11:51:14.728065 IP6 2001:67c:2e8:13::3 > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 989 11:51:14.739038 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 4, length 1308 11:51:14.741656 IP6 ams-ix.sara.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 989 11:51:14.752068 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 5, length 1308 11:51:14.754816 IP6 ams-ix.sara.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 989 11:51:14.766003 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 6, length 1308 11:51:14.770292 IP6 ams-ix.sara.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 989 11:51:14.780776 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 7, length 1308 11:51:14.784750 IP6 0.ae4.xr3.3d12.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 990 11:51:14.795372 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 8, length 1308 11:51:14.798701 IP6 0.ae4.xr3.3d12.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 990 11:51:14.809910 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 9, length 1308 11:51:14.812934 IP6 0.ae4.xr3.3d12.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 990 11:51:14.823234 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 10, length 1308 11:51:14.828122 IP6 0.ae0.dr12.d12.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 993 11:51:14.838781 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 11, length 1308 11:51:14.842716 IP6 0.ae0.dr12.d12.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 993 11:51:14.853966 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 12, length 1308 11:51:14.857645 IP6 0.ae0.dr12.d12.xs4all.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 993 11:51:14.868309 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 13, length 1308 11:51:14.889053 IP6 stereo6.hq.phicoh.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 1240 11:51:14.899403 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 14, length 1308 11:51:14.920754 IP6 stereo6.hq.phicoh.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for 2001:980:1284:10:2a0:c9ff:fe9f:17a9, length 1240 11:51:14.931113 IP6 2001:67c:2e8:13:21c:42ff:fe9f:b8b3 > 2001:980:1284:10:2a0:c9ff:fe9f:17a9: ICMP6, echo request, seq 15, length 1308 11:51:14.951985 IP6 stereo6.hq.phicoh.net > 2001:67c:2e8:13:21c:42ff:fe9f:b8b3: ICMP6, time exceeded in-transit for
Re: Netflix hates IPv6
In your letter dated Wed, 15 Jun 2016 11:12:19 +0200 you wrote: >The interesting question is why they hand out v6 addresses in the first >place - I'd assume that Netflix is doing the same global DNS content >steering thing as all the other big content networks, so they should know >where the user is coming from... and if the DNS query is coming from a >(v4) access network in the US, it seems silly to disallow access to the >v6 server *they have told the client to use* later on. Note that people are actively trying to bypass whatever geo restrictions netflix puts in place. And of course, netflix wants to avoid blocking legitimate users as much as possible. So to the extent that DNS is used to implement geo blocking, people will use DNS resolvers in the desired country to avoid the blocks. Of course, in the case of HE tunnels, netflix could just add an IPv4-only option to the users' profiles and redirect people to an IPv4-only server. I guess they can just offer the redirect as an option whenever they show the VPN-detected banner for an HE address.
