Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Tore Anderson]

* JORDI PALET MARTINEZ

> I don't know it by memory

Huh. In that case, what do you base your claims about what the GDPR requires 
on, exactly?

> 1) Before 25 May 2018, every EU citizen or resident must get a confirmation 
> from any database holder with his personal data, to re-confirm the 
> authorization.

Not true.

Assuming the lawful grounds for processing is «consent» pursuant to article 
6(1)(a) GDPR, and consent was given prior to 25th of May 2018 in a way that 
satisfies the requirements for consent pursuant to article 7 GDPR, then there 
is no need to ask the data subject to «re-confirm».

The process of subscribing to a mailing list does to me seem to constitute 
valid consent.

It would also be possible to instead the lawful grounds «necessary for the 
performance of a contract» pursuant to article 6(1)(b) GDPR, in which case 
valid consent is not required.

The lack of a privacy statement is likely a bigger problem as far as GDPR 
compliance is concerned.

> 2) Right to object. Art. 59, but also many others. It is not probably clearly 
> said that it must be in a footer but it must be clearly available how to.

It is most definitively not mentioned in the article 59 GDPR because that 
article about annual activity reports issued by the supervisory authorities, so 
that one totally irrelevant here.

You are right that there is a right to object (article 21 GDPR). However that 
has absolutely nothing to say about mailing list footers either.

Tore

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Tore Anderson]

* JORDI PALET MARTINEZ

> It is true however, that this list must follow GDPR, and this means having an 
> explicit unsubscription link in the footer

Which GDPR article requires that, exactly?

Tore

Re: Link-local and ACLs

[Tore Anderson]

* Brian E Carpenter

> So, I'm not aware of any realistic case where this happens, or any
> reason for it.

As Gert already pointed out: Neighbour Discovery.

A few examples from an IX near me:

23:06:11.020045  In IP6 fe80::8678:acff:fe66:80db > 2001:7f8:12:1::3:9029: 
ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
23:06:11.563763  In IP6 fe80::aa0c:dff:fe71:5768 > 2001:7f8:12:1::3:9029: 
ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
23:06:29.958824  In IP6 fe80::92e2:baff:fe3f:7665 > 2001:7f8:12:1::3:9029: 
ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
23:06:34.239488  In IP6 fe80::523d:e5ff:fe89:4ec4 > 2001:7f8:12:1::3:9029: 
ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
23:06:45.177659  In IP6 fe80::2c1:64ff:fe60:380 > 2001:7f8:12:1::3:9029: ICMP6, 
neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32

Tore

Re: Linux and ULA support and default route

[Tore Anderson]

* Holger Zuleger 

> Hmm, what's so bad with still using the global prefix until the global
> connectivity comes back and the CPE gets a new one?
> Than it's early enough to set the preferred time of the former prefix to
> 0 and let them time out.
> In this way all local communication will not be interrupted if your
> Internet connection fails.

If the delegated prefix changes, you'll be simply postponing the local
communication failure, not prevent it.

I've run Homewrt for over a year now and have no shortage of annoying
experiences like for instance a movie that is being streamed to my HTPC
from my NAS just suddenly freeze just because the Internet uplink have
gone down and/or the delegated prefix changes.

The last year has convinced me that the best user experience is
achieved by having an in-home stable ULA prefix to complement the
ISP-delegated global prefix[es] [if any], and that all the internal
hostnames should resolve to the IPv6 addresses assigned from the ULA
prefix.

Tore

Re: push apps failing in Android until you disable IPv6

[Tore Anderson]

* Lorenzo Colitti

> On Fri, May 13, 2016 at 3:27 PM, Mikael Abrahamsson 
> wrote:
> 
> > My guess is that any device which sees this, will install default IPv6
> > route but will only have link local addresses on the interface, thus there
> > is no source address to use to send packets to the world outside the link.
> 
> You're forgetting that the device might have an an IPv6 address on the
> cellular interface, and an OS that uses the weak host model like Linux is
> perfectly happy to use the cellular interface's IPv6 address to send
> packets on the wifi interface.

Hmm...so Android doesn't simulate a strong host model using
per-interface network namespaces or private routing tables with
associated policy rules?

If not, how do you avoid running into BCP38 issues when both the
cellular and wifi interfaces are connected and both have active global
IPv6 addresses? (That is, the cellular address being used as the source
in packets sent to the wifi default router or vice versa?)


Tore

Re: push apps failing in Android until you disable IPv6

[Tore Anderson]

* Erik Kline 

> If this router were to send out an RA advertising itself as a default
> router in this configuration that would probably cause the symptoms
> you're seeing.  That's why I asked for a sample of any RAs seen on
> such a network.  (Such a configuration would of course be broken,
> effectively requiring Happy Eyeballs to function at all.)

Assuming the source address selection is implemented in a sane way,
just having a an IPv6 default router doesn't on its own explain the
symptoms described. IPv4 should be preferred due to the Android device's
link-local address not having the same scope as the IPv6 address of the
web site or whatever. See RFC6724 sections 5 and 6, rule 2.

The RA would have to additionally contain a PIO with global scope, as I
understand it. Then you'd certainly get in trouble (disregarding Happy
Eyeballs). Even a ULA PIO could be problematic if Android's source
address selection algorithm isn't updated to RFC6724 defaults. RFC3484
predates ULAs, so it treats them the same as other globally scoped
addresses.

Tore

Re: Ubuntu 16.04

[Tore Anderson]

Hi again,

> Ubuntu (at least previous versions) hard-codes privacy extensions to be
> on and preferred, overriding any user configuration to the contrary in
> NM or /etc/network/interfaces.

For the record, this has actually been fixed in 16.04, probably as a
side-effect of changing to systemd. Now the sysctls get loaded before
the network is brought up, so if you explicitly configure "privext 0"
in /etc/network/interfaces or "ipv6.ip6-privacy 0" in nmcli con edit
, that device-specific setting does not get overwritten later on
in the boot process.

> > I used to administrate this device using its EUI64 based SLAAC
> > address, which was stable across reboots. Now with 16.04, I get two
> > addresses, none of them stable across reboots.
> > 
> > Anyone know what the thought is behind this? I want to continue using 
> > SLAAC and I'm fine with privacy extension addresses over time, but I
> > want a single stable address across reboots.  
> 
> Are you 100% sure one of the addresses isn't stable? NM-1.2 defaults to
> using RFC7217 IID instead of EUI-64, and I believe Ubuntu 16.04 ships
> with a NM-1.2 or (or a release candidate).

I was able to reproduce the issue. I'm guessing you're using a wired
ethernet with no explicitly saved connection profile? When NM
auto-creates an ephemeral connection profile, it gets an equally
ephemeral UUID. The RFC7217 implementation in NM derives the UUID from
the connection profile (amongst other things), which means the results
of the algorithm - the IID - isn't stable at all.

https://bugzilla.gnome.org/show_bug.cgi?id=765464

You can work around this by saving the connection profile, e.g.:

$ nmcli con edit 'Wired connection 1' # the name might be localised
nmcli> save

Alternatively, if you don't want RFC7212 addresses at all and prefer
the previous behaviour, you can do:

nmcli> set ipv6.addr-gen-mode eui64

Tore

Re: Ubuntu 16.04

[Tore Anderson]

* Mikael Abrahamsson

> I have a pretty standard Ubuntu 14.04 machine I just upgraded to 16.04, 
> which means I get a "4.4.0-21-generic" kernel.
> 
> I guess I'm using straight up network manager, because my 
> /etc/network/interfaces doesn't mention anything about eth0 or wlan0, only 
> lo.
> 
> In the GUI, it came default with "privacy extensions disabled".

Ubuntu (at least previous versions) hard-codes privacy extensions to be
on and preferred, overriding any user configuration to the contrary in
NM or /etc/network/interfaces. You need to
delete /etc/sysctl.d/10-ipv6-privacy.conf for your NM/interfaces
setting to take effect.

https://bugs.launchpad.net/bugs/1497166

> I used to administrate this device using its EUI64 based SLAAC
> address, which was stable across reboots. Now with 16.04, I get two
> addresses, none of them stable across reboots.
> 
> Anyone know what the thought is behind this? I want to continue using 
> SLAAC and I'm fine with privacy extension addresses over time, but I
> want a single stable address across reboots.

Are you 100% sure one of the addresses isn't stable? NM-1.2 defaults to
using RFC7217 IID instead of EUI-64, and I believe Ubuntu 16.04 ships
with a NM-1.2 or (or a release candidate).

https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/

(This is orthogonal from the use of RFC4941 privacy addresses, btw.)

However RFC7217 IIDs are supposed to be stable across reboots, and on
my Fedora 23 system, they are. If they aren't with you, maybe something
goes wrong with storing the stable secret key? On my system, it's
stored in /var/lib/NetworkManager/secret_key, for what it's worth.

What does "nmcli con show  | grep ipv6" say?

Tore

Re: Curious situation - not urgent, but I'd like to know more

[Tore Anderson]

* Kurt Buff

> Can you expand a bit on the above? I'm quite ignorant of what you're
> speaking, and would love to know more.
> 
> Why shouldn't ATT allow her 6to4 packet back, and what is the tcpdump
> session to which you refer? And, I've only recently become aware that
> CGN has its own address range, but don't understand why breakage would
> occur for 6to4.

Ok, so her home router improperly uses the public IPv4 range 1.0.0.0/24
on her LAN (instead of a private IPv4 range such as 10.0.0.0/24). This
tricks Windows to starting 6to4 in a situation where it really should
not (it should only do so if it has a public IPv4 address). That's what
causing the problems in the first place.

It would be interesting to know what kind of home gateway she has,
where she got it from, and if it came with this broken config out of
the box.

Another thing, ATT supports IPv6 via 6RD (AFAIK), so I'd look into why
this doesn't work and try to get that fixed. ATT's own 6RD IPv6
connectivity is going to be better than 6to4 in every way possible.

Anyway, the reason why return traffic won't work is simply the way 6to4
works. The public IPv4 address of the host is embedded in bits 17-48 of
the IPv6 address, and this is where the return traffic gets sent.

That is, if she wants to talk to ipv6.example.org, her initial outbound
6to4 packet will look like this:

| IPv4 outer header: src=1.0.0.105 dst=192.88.99.1
| IPv6 inner header: src=2002:100:69::100:69 dst=ipv6.example.org
| TCP SYN

The packet leaves her LAN (possibly after having the 10.0.0.105 address
be rewritten to her real public address by her home gateway, but this
does not really help), and gets routed to the nearest 6to4 relay
(192.88.99.1). It strips off the IPv4 outer header and injects the
resulting packets into the IPv6 network:

| IPv6 header: src=2002:100:69::100:69 dst=ipv6.example.org
| TCP SYN

This reaches ipv6.example.org which responds normally:

| IPv6 header: src=ipv6.example.org dst=2002:100:69::100:69
| TCP SYN+ACK

This packet gets routed to the nearest 6to4 relay (since it it's
addressed to an address inside 2002::/16), which encapsulates in IPv4.
As mentioned before IPv4 destination address is found in bits 17-48 of
the IPv6 destination address, thus:

| IPv4 outer header: src=192.88.99.1 dst=1.0.0.105
| IPv6 inner header: src=ipv6.example.org dst=2002:100:69::100:69
| TCP SYN+ACK

This packet then gets injected into the IPv4 network and routed to
1.0.0.105. But, from the Internet's point of view, that address points
to APNIC - not your colleague. Thus it won't ever reach your colleague.

The tcpdump session I (jokingly) referred to belongs to Geoff Huston and
George Michaelson, APNIC's fine scientists who are listening in on all
traffic sent to 1.0.0.0/24 and use the data to give us amusing
presentations at the various networking conferences. Mayhaps your
colleague will be honoured with a slide next time.

The situation is pretty much the same for 100.64.0.0/10, i.e., it is an
IPv4 range that is being used behind NAT but that most 6to4
implementations won't recognise as private. There's no route to
100.64.0.0/10 on the public IPv4 Internet, thus return 6to4 traffic
cannot reach the original sender.

Tore

Re: Curious situation - not urgent, but I'd like to know more

[Tore Anderson]

Hi Kurt,

First of all, +1 to Brian's suggestion to disable 6to4. I'd also disable
Teredo.

> On my test machine (Also Win8.1), sitting outside of my corporate
> firewall on a public IP address, I see the following:
> 
> Tunnel adapter 6TO4 Adapter:
> 
>Connection-specific DNS Suffix  . :
>Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>DHCP Enabled. . . . . . . . . . . : No
>Autoconfiguration Enabled . . . . : Yes
>IPv6 Address. . . . . . . . . . . : 2002:4332:7632::4332:7632(Preferred)

Ok, so this tells us that this machine has the public IPv4 address
67.50.118.50 (0x43.0x32.0x76.0x32). 6ot4 requires public IPv4 addresses
to work, so on this machine it has at least a *chance* of working.

Note that Windows won't activate 6to4 if the local address is a
special-use one, such as RFC1918 ones typically seen behind NAT.

> On her machine, which is on a wireless connection at her home on ATT,
> I see this:
> 
> Tunnel adapter 6TO4 Adapter:
> 
>Connection-specific DNS Suffix  . : attlocal.net
>Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>DHCP Enabled. . . . . . . . . . . : No
>Autoconfiguration Enabled . . . . : Yes
>IPv6 Address. . . . . . . . . . . : 2002:100:69::100:69(Preferred)

This tells us that her IPv4 address is 1.0.0.105. That's a completely
normal and public IPv4 address, so Windows proceeds to activate 6to4.
But I am going to assume that your user does not live in an APNIC lab,
which is where this prefix is currently being used...

If ATT will allow her 6to4 packets through to the Internet in the first
place (they shouldn't), any server replies will not come back to her
but instead head straight to Geoff or George's tcpdump session. (With
some luck they'll be the topic of an amusing blog post.)

The exact same breakage is bound to happen with CGN deployments using
100.64.0.0/10, by the way.

Tore

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Tore Anderson]

* Lorenzo Colitti lore...@google.com

 On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson t...@fud.no wrote:
 
   are *all* IPv6 packets blocked, or just multicast packets? I know
   that a number of devices will drop multicast IPv6 packets. This
   eventually blackholes connections because the device stops receiving
   RAs and thus loses its default route, but that can be worked around
   by setting long timers in the RA. I wasn't aware of devices dropping
   all inbound IPv6 packets, that really seems like a bad bug.
 
  AIUI, the maximum RA Lifetime is 9000 seconds. RFC 4861, section 6.2.1.
 
 Except that 65535 works fine. :-)

Right.

There was another thing I thought of, though. We have a wireless
network with two redundant upstream routers that are not running a FHRP
like VRRP. Active/passive, since they do stateful inspection of
traffic. My solution to facilitate reasonably speedy failover from the
active to the passive router was to have a quite low RA lifetime, so
that the clients would quickly stop using a router that went offline.

Maybe I could instead leave the RA lifetime high, but set the reachable
time low, and depend on the client doing NUD. Would that work? In this
situation the clients would after a failover have two default routes,
where one has a next-hop that fails NUD. Do you know if clients in
general Do The Right Thing here and ignore the route that fails NUD?

In any case I get a problem when the primary router comes back online,
because then the clients end up with two default routes that both pass
NUD fine. I guess having the backup router send an few RAs with
lifetime=0 when it enters passive mode ought to handle that...

Also, lowering the reachable time isn't ideal on network with on-link
prefixes either as it'll impact client-client traffic too, not only
client-router. But that's probably not an issue on most WiFi
deployments I guess.

Tore

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Tore Anderson]

* Lorenzo Colitti

 are *all* IPv6 packets blocked, or just multicast packets? I know
 that a number of devices will drop multicast IPv6 packets. This
 eventually blackholes connections because the device stops receiving
 RAs and thus loses its default route, but that can be worked around
 by setting long timers in the RA. I wasn't aware of devices dropping
 all inbound IPv6 packets, that really seems like a bad bug.

AIUI, the maximum RA Lifetime is 9000 seconds. RFC 4861, section 6.2.1.

So unless you're a polyphasic sleeper, the handset will loose
connectivity overnight no matter what...

 A network that is configured to send RAs every 15 seconds will have a
 devastating effect on battery life, and such networks are part of the
 reason that manufacturers drop all multicast packets during sleep.
 Please don't do that. Nexus devices rate-limit RAs in firmware in
 order to survive on such aggressive networks, but that's not perfect.

Frequent unsolicited RAs was how I worked around the above problem.
While my phone would loose connectivity while on my nightstand, at
least with frequent RAs the IPv6 connectivity would recover quickly
once I started using my phone again in the morning. With infrequent
RAs, it would stay broken for a very long time.

But this was a few years ago, so maybe the situation has improved since
then? I imagine the handset could get away with not listening to RAs
while in sleep mode if it did send an RS some time before any of the
information learned from RAs was about to expire, for example.

Tore

Re: Looking for information on IGP choice in dual-stack networks

[Tore Anderson]

* Philip Matthews philip_matth...@magma.ca

 We are looking particularly at combinations of the following IGPs:
 IS-IS, OSPFv2, OSPFv3, EIGRP.

We're using OSPFv2 and OSPFv3 as ships in the night for IPv4 and IPv6,
respectively. That said, somewhere far down in the darkest depths of my
TODO list I have an item about investigating the possibility of
replacing OSPFv2 for IPv4 with OSPFv3 + RFC 5838. I see this
possibility is briefly mentioned in your I-D - if you're able to gather
more information about the viability of such a solution, that would be
a very valuable addition to the I-D, I think.

As an aside, I can mention that we're using AH for OSPFv3
authentication. I sometimes see people saying AH is never used for
anything anymore and should be deprecated, but I'm not sure if there
are any real alternatives to AH for securing OSPFv3?

 If you run something else (RIP?) then we would also like to hear
 about this, though we will likely document these differently. [We
 suspect you run RIP/RIPng only at the edge for special situations,
 but feel free to correct us].

Indeed, we run RIPv2 and RIPng on the edge to allow certain
customer systems to advertise service addresses that can move between
locations for redundancy reasons (or anycasted services). These
advertisements get immediately turned into external routes in OSPF (in
other words we do not have a RIP topology). To get speedy failover we
lower the RIP timers as low as they can go, and have the customers send
updates every second. Using BFD would be an alternative to lowering
timers, but we haven't yet been able to deploy that because BIRD (which
we're typically using on the customer systems) doesn't support BFD for
RIP.

I do feel rather dirty using RIP in 2015, so I would be interested in
hearing about any alternatives approaches folks are using. We're not
using BGP because we'd have to pre-configure every neighbour on the
upstream router (not useful in dynamic or cloudy environments), nor
OSPF because we need the ability to filter out invalid advertisements
from the customer systems.

Tore

Re: Why do we still need IPv4 when we are migrating to IPv6...

[Tore Anderson]

* Anfinsen, Ragnar

 I am working with my management team to implement IPv6, but I got an 
 interesting question from one of the managers; Why do we need more
 IPv4 if we are moving towards IPv6?

IPv6 doesn't relieve you of IPv4 growth pains until you can start
shutting down IPv4 in parts of your network, and reassign those
reclaimed IPv4 addresses to more valuable end-points (such as the CPEs).

However, once you have implemented IPv6 (and I understand that your new
network architecture supports native IPv6?), you can actually do stuff
like that. Mikael already mentioned MAP and lw4o6, and I'd just like to
add that this does not necessarily mean oversubscription of IPv4
addresses - at least with MAP, you can still assign whole /32s to
customers (or even larger prefixes for that matter).

These technologies also allow for more efficient utilisation of your
available IPv4 address space then what you're usually able to
accomplish in a traditional IPv4 network. If you assign a /24 to the
MAP service, you can make use of every single one of the 256 IP
addresses - including the .0 and .255 if you so desire.

You can do similar stuff in the data centre BTW, and I'm sure my
employer would be happy to have me help you out with that. ;-)

 A quick background; We are having discussions around IPv4 and IPv6
 and the need to eventually buy more IPv4 addresses to keep a premium
 level on our Internet access.

Can you really with a straight face today call your product «premium»,
when it lacks the IPv6 support at least two of your largest competitors
offer?

If you consider the existence of optional/opt-in IPv6 support as
sufficient to call the entire product «premium», then perhaps you could
extend that line of reasoning to public IPv4?

In other words, give your customers to shared IPv4 by default, but allow
them to opt-in to get a public IPv4 address. Some percentage of your
customers won't care to do so as they're perfectly happy without (just
as they might be perfectly happy without IPv6), leaving you with
available IPv4 addresses you can assign to your CGN/MAP/lw4o6/whatever
equipment and to those of your customers who opt in to get public IPv4.

Tore

Re: Why do we still need IPv4 when we are migrating to IPv6...

[Tore Anderson]

* Ole Troan

 When will IPv6 provide me as an end-user with more value than what
 my current NATed IPv4 connection does?

If you, like me, like to play games online, and at some point find
yourself googling for the cause of connectivity problems (it is just
*so* *extremely* infuriating to have the game stall on you while you're
sneaking up for the kill, and suddenly three seconds later it recovers
only that now *you're* the one sitting there in a pool of blood,
waiting to respawn), you'd surprised to see how much grief there is
about which «NAT Type» one has and suggestions on how to improve this.

Gamers in this situation might also stumble across Microsoft's
statement that if you want to experience ideal online connectivity with
the Xbox One, then you'll want to be using IPv6. And then if the gamer
then starts googling this «IPv6» thing he might find out that it
abolishes the hated NAT stuff entirely, and suddenly Microsoft's
statement makes perfect sense to him, and he will actually end up
actively *wanting* IPv6.

Anyway, this is how it is *today* for the XB1, and I've been told that
IPv6 support for the PS4 is on its way as well.

Tore

Re: Why do we still need IPv4 when we are migrating to IPv6...

[Tore Anderson]

* Thomas Schäfer

 This might be so in Norway. In German customer portals the gamers
 mostly demand ipv4 (public ipv4 address to their home) instead of
 DS-Lite. They have already native IPv6 but avm was forced to allow
 teredo over DS and DS-lite - because xbox has problems with native
 IPv6.

IIRC this was for communication between a dual-stacked XB1 and an
IPv4-only XB1. It's impossible to use IPv6 for that, because IPv4 is
the lowest common denominator. The XB1 is simply using Teredo to tunnel
P2P traffic over IPv4.

Is there any known problems related to IPv6 communication between two
XB1s that both have native IPv6 access?

  Anyway, this is how it is *today* for the XB1, and I've been told
  that IPv6 support for the PS4 is on its way as well.
 
 Any public source/ statement from sony?

No, I just exchanged some e-mails with an SCE guy back in October. He
said:

«As for the PS4, the hardware was designed with IPv6 in mind and they
are planning to enable IPv6 at some point. (It is just a firmware
thing.) Initially we were told that the PS4 would launch with IPv6, but
in the end I think they were just so busy getting all the other stuff
done that they decided to wait on implementing IPv6 on it.  I know that
they are still planning on implementing it, but unfortunately no one
has shared any dates with me.»

Hopefully it'll come soon.

Tore

Re: google path mtu?

[Tore Anderson]

* Mikael Abrahamsson swm...@swm.pp.se

 So I guess the problem this time was some Google servers sending me 
 PTB=1280 and then Chrome not taking this into account when sending
 UDP packets when using QUIC, resulting in fragmented IPv6 packets
 (which works very badly in real life), and then not handling this
 situation by doing fall-back to something else.

I highly doubt that Google would be sending you PTBs. 10 SEK says it's
your tunnel ingress router (i.e., your Airport Express)...

But this could be found out, run tcpdump -nvi eth0 'icmp6 and ip6[40]
== 2' in a terminal while reproducing the problem and see what's the
source address of the PTBs?

Tore

Re: Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)

[Tore Anderson]

* Jeroen Massar

 On 2014-11-08 18:38, Tore Anderson wrote:
  Yannis: «We're enabling IPv6 on our CPEs»
  Jeroen: «And then getting broken connectivity to Google»
  
  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.

Only if Google and Akamai are universally broken, which does not seem
to have been the case. I tested Google from the RING at 23:20 UTC
yesterday:

redpilllinpro@redpilllinpro01:~$ ring-all -t 120 -n 0 'wget -q -6 --timeout=10 
-O /dev/null 
https://lh6.googleusercontent.com/-msg_m1V-b-Y/Ufo23yPxnXI/AMw/Mv5WbEC_xzc/w387-h688-no/13%2B-%2B1
  echo OK || echo FAILED'  | egrep '(OK|FAILED)$'| sort | uniq -c
10 FAILED
255 OK

And Akamai just now (10:30 UTC):

redpilllinpro@redpilllinpro01:~$ ring-all -t 120 -n 0 'wget -q -6 --header 
User-Agent: foo --timeout=10 -O /dev/null 
http://www.akamai.com/images/img/banners/entertainment-home-page-banner-932x251.jpg
  echo OK || echo FAILED'  | egrep '(OK|FAILED)$'| sort | uniq -c
10 FAILED
252 OK

The files I get are both plenty larger than 1500B. Note that (some of)
the FAILED might be explained by the RING-node in question having
generally defective IPv6 connectivity, so it doesn't have to be
Akamai/Google specific.

I'll investigate the failing nodes further and let you know if I find
something that points to Google/Akamai-specific problems.

 No, PMTUD is fine in both IPv4 and IPv6.
 
 What is broken is people wrongly recommending to break and/or
 filtering ICMP and thus indeed breaking PMTUD.

There's a critical mass of broken PMTUD on the internet (for whatever
reasons). It does not matter who's fault it is, the end result is the
same - the mechanism cannot be relied upon if you actually care about
service quality.

From where I'm sitting, Google is advertising me an IPv6 TCP MSS of
1386. That speaks volumes. I don't believe for a second that my local
Google cluster is on links with an MTU of 1434; the clamped TCP MSS must
have intentionally have been configured, and the only reason I can
think of to do so is to avoid PMTUD.

What works fine in theory sometimes fail operationally (cf. 6to4).
Insisting that there exists no problem because it's just everyone else
who keeps screwing it up doesn't change operational realities.

 I also have to note that in the 10+ years of having IPv6 we rarely saw
 PMTU issues, and if we did, contacting the site that was filtering
 fixed the issue.

Looking at it from the content side, users using IPv6 tunnels are in a
tiny, tiny minority, while still managing to be responsible for a
majority of trouble reports. Our stuff reacts to ICMPv6 PTBs, so it's
not *all* tunnel users that get in trouble at the same time, it's just
that they're suspectible to problems such as:

* Dropping ICMPv6 PTBs emitted by their CPE/tunnel ingress in their
  computer's personal/local firewall.
* The Internet tunnel ingress router rate-limiting ICMPv6
  generation. For example, Juniper has a hard 50pps ICMP generation
  limit per FPC, and at least one Cisco platform has 100/10 by
  default. Given enough traffic on the tunnel router, this limit will
  exceeded more or less continously. See the thread «MTU handling in 6rd
  deployments», btw.

Native users are immune against these problems, because they do not have
to use PMTUD.

 The two 'workarounds' you mention are all on the *USER* side (RA MTU)
 or in-network, where you do not know if the *USER* has a smaller MTU.

LAN RA MTU, yes. TCP MSS, no - it can be done in the ISP's tunnel
router.

 Hence touching it in the network is a no-no.

It appears to me that the ISPs that are deploying tunnels (6RD) for
their users consider these a yes-yes. Presumably because they've
realised that reducing reliance on PMTUD is in their customer's best
interest, as it gives the best user experience.

Is there *any* ISP in the world that does 6RD that does *not* do TCP MSS
clamping and/or reduced LAN RA MTUs? (Or, for that matter, does IPv4
through PPPoE and does not do TCP MSS clamping?)

For what it's worth, the vast majority of tunneled IPv6 traffic we see
comes from ISPs with 6RD, which generally works fine due to these
workarounds. Thankfully.

  «this must be a major issue for everybody using IPv6 tunnels»
  «MTU 1480 MSS 1220 = fix»
  «the 1480MTU and 1220MSS numbers worked for my pfsense firewall»
  «The only thing that worked here is 1280 MTU / 1220 MSS»
  «clamping the MSS to 1220 seems to have fixed the problem for me»
  «I changed the MSS setting [...] for the moment Google pages are
  loading much better»
  
  This is all perfectly consistent with common PMTUD mailfunctioning /
  tunnel suckage.
 
 NOTHING to do with tunnels

Re: Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)

[Tore Anderson]

* Nick Hilliard

 On 09/11/2014 11:00, Tore Anderson wrote:
  Only if Google and Akamai are universally broken, which does not
  seem to have been the case. I tested Google from the RING at 23:20
  UTC yesterday:
 
 did you do a control run on a known working site?

No. I feel that 250+ successes vs 10 failures is enough to conclude
that Akamai and Google are *not* universally broken, far from it. Thus
refuting the claim that «Google and Akamai IPv6 are currently broken,
enabling IPv6 thus breaks connectivity to those sites».

Whatever broke, it must have been much more local than that, or only
occurring under certain conditions (e.g., tunnels dependent on PMTUD).

 Not all ring nodes have working ipv6.

Exactly. That's a likely explanation for (some of) the 10 failures.

I redid the tests now, and the failing nodes were:

beanfield01.ring.nlnog.net
bluezonejordan01.ring.nlnog.net
claranet02.ring.nlnog.net
hosteam01.ring.nlnog.net
keenondots01.ring.nlnog.net
maxitel01.ring.nlnog.net
nicchile01.ring.nlnog.net
occaid01.ring.nlnog.net
popsc01.ring.nlnog.net
rackfish01.ring.nlnog.net
robtex01.ring.nlnog.net

Of these, only three were able to ping 2a02:c0::1 which I know should
respond fine. The other ones got various no route to host,
destination beyond scope of source, and stuff like that.

The three that had working IPv6 connectivity were:

hosteam01.ring.nlnog.net
nicchile01.ring.nlnog.net
occaid01.ring.nlnog.net

hosteam01 and occaid01 have defective local DNS, they can't resolve
anything it seems. So nothing to do with Google and Akamai there.

nicchile01 is the only one that looks interesting, as it works for
Google but not Akamai:

redpilllinpro@nicchile01:~$ wget -6 --header User-Agent: foo -O /dev/null 
http://www.akamai.com/images/img/banners/entertainment-home-page-banner-932x251.jpg
--2014-11-09 12:03:41--  
http://www.akamai.com/images/img/banners/entertainment-home-page-banner-932x251.jpg
Resolving www.akamai.com (www.akamai.com)... 2600:1419:7:185::22d9, 
2600:1419:7:189::22d9
Connecting to www.akamai.com (www.akamai.com)|2600:1419:7:185::22d9|:80... 
failed: Connection refused.
Connecting to www.akamai.com (www.akamai.com)|2600:1419:7:189::22d9|:80... 
failed: Connection refused.

However, tcpdump reveals that this isn't Akamai's doing, as it's
ICMP errors originating from a NIC Chile-owned IP address.

12:06:19.388093 IP6 2001:1398:32:177::40  2001:1398:3:120:200:1:120:28: ICMP6, 
destination unreachable, unreachable port, 2600:1419:7:185::22d9 tcp port 80, 
length 88
12:06:19.389095 IP6 2001:1398:32:177::40  2001:1398:3:120:200:1:120:28: ICMP6, 
destination unreachable, unreachable port, 2600:1419:7:189::22d9 tcp port 80, 
length 88

Perhaps they have firewalled out Akamai for some reason?

In any case. I summary I see *zero* evidence of ubiquitous IPv6
problems with Google and Akamai. So ISPs should not worry about
deploying IPv6, at least if they're doing it native and don't
expose themselves to PMTUD breakage.

Tore

Re: Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)

[Tore Anderson]

* Jeroen Massar

 Testing from colod boxes on well behaved networks (otherwise they
 would not know or be part of the RING), while the problem lies with
 actual home users is quite a difference.

So far you've been claiming that the problem lies with Google or
Akamai. If true - and I don't dispute that it is - then testing from
the RING should work just as well as from any home network.

And, as Job has pointed out, the RING nodes are not all «well behaved».

 Also the statement universally broken comes from you.

I refer to this blanket statement of yours, responding to my
paraphrasing you and Yannis:

«Yannis: «We're enabling IPv6 on our CPEs
Jeroen: «And then getting broken connectivity to Google»

You: «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.»

In order for this to be correct, Google and Akamai must necessarily be
universally broken over IPv6.

If on the other hand the problem is not universal, but only occurring in
a certain corner cases (such as when hitting the cluster in Mexico
City, when client is behind a 1500B MTU link, or whatever), then
you have no reason to claim that ISPs in general (like OTE) will
break connectivity to Akamai and Google when they enable IPv6.

  Thus refuting the claim that «Google and Akamai IPv6 are currently
  broken, enabling IPv6 thus breaks connectivity to those sites».
 
 As Google has admitted fixing it, you have been proven wrong.

I don't dispute that there is or has been *a* problem, only the scope
of it.

The way I see it, most of the available data points to there indeed
being a problem specific to tunnels/PMTUD (which I've said all along,
cf. tunnels suck). Perhaps Google turned up a new cluster and forgot
to enable TCP MSS clamping or something like that. No idea about the
Akamai one.

 Actually, I wonder why you are trying to fight so hard that various
 people have reported this problem. You are apparently not working for
 either Google or Akamai, you are not an access network, your network
 is not involved either; hence... what is your problem with such a
 statement?

My problem is with your claim that «not enabling IPv6 thus is a better
option in such a situation».

Whatever the problem is or was, it did not affect everyone - most
likely it affected just a tiny fraction of users - otherwise I think we
would have heard way more complaints from all over. There are millions
of IPv6 users out there in the world, and without Google(+YouTube/GMail)
and Akamai(+Facebook), internet doesn't work.

With no more specifics known about what went wrong, ISPs have zero
reason to stall their IPv6 rollouts, since there is no reason to assume
that they will be impacted by the problem. So: OTE.gr, Telefonica.cz,
Telenor.no, Telepac.pt, and others - go go go!

BTW: Some of our customers are heavy users of Akamai for video
streaming, and many have lots of interaction with various Google
services. So I have plenty of reason to care about any problem of
theirs.

Tore

Re: Some very nice IPv6 growth as measured by Google

[Tore Anderson]

* Jeroen Massar

 On 2014-11-08 11:34, Tore Anderson wrote:
  * Jeroen Massar
  
  On 2014-11-08 10:27, Yannis Nikolopoulos wrote:
  [..]
  the short story here is that we're (finally) enabling IPv6 on our
  (already capable) CPEs :)
 
  And then getting broken connectivity to Google:
 
  https://www.sixxs.net/forum/?msg=general-12626989
  https://forums.he.net/index.php?topic=3281.0
  
  Non sequitur. I'd be extremely interesting in understanding how
  Yannis' IPv6 deployment in OTE (kudos!) could possibly impact the
  SixXS/HE tunnel users' ability to contact Google.
 
 That is not what I wrote or intended.
 
 Something unrelated to their deployment broke. But doing the
 deployment does mean that you are now providing connectivity that
 breaks to two major providers: Google and Akamai.

I still do not follow. Is (or were) OTE's deployment broken? If
yes, is the reason for the brokenness the same as for the SixXS/HE
users? (Is OTE using 6RD?) If no, what is the connection between OTE's
deployment and the SixXS/HE problems you linked to?

 Tunnels do not suck, people who have broken clusters that randomly
 drop packets suck.

Let me rephrase: PMTUD sucks. Tunnels suck by association, because
they rely on PMTUD not sucking.

(Except where the tunnel can accomodate an inner MTU of 1500.)

 Note that even with a full 1500 MTU you will have
 broken connectivity to Google at the moment, lots of fun thus for
 those native deployments like Unitymedia who forcefully stuff folks
 in DSlite land.

This is news to me, both Google and Akamai works just fine from here
in Norway. Could you elaborate on what broke and how I could try to
reproduce it?

Tore

Re: Some very nice IPv6 growth as measured by Google

[Tore Anderson]

* Jeroen Massar

 The only link: they are all using IPv6.
 
 You are trying to make this OTE link. I have never stated anything
 like that. Though, you likely take that from the fact that the reply
 followed in that thread.

Yannis: «We're enabling IPv6 on our CPEs»
Jeroen: «And then getting broken connectivity to Google»

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

Anyway, I'm relieved to hear that there's no reason to supect IPv6
breakage in OTE. As we host a couple of the top-10 Greek sites, one of
which has IPv6, we're dependent on the big Greek eyeball network like
OTE to not screw up their IPv6 deployment - it is *I* who get in trouble
if they do. :-)

 PMTUD is fine.
 
 What sucks is 'consultants' advising blocking ICMPv6 because that is
 what we do in IPv4 and that some hardware/software gets broken once
 in a while.

PMTUD is just as broken in IPv4, too. PMTUD has *never* been «fine»,
neither for IPv4 nor for IPv6. That's why everyone who provides links
with MTUs  1500 resorts to workarounds such as TCP MSS clamping and
reducing MTU values in LAN-side RAs, so that reliance on PMTUD
working is limited as much as possible. If you want to deliver an
acceptable service (either as an ISP or as a content hoster), you just
*can't* depend on PMTUD.

Even when PMTUD actually works as designed it sucks, as it causes
latency before data may be successfully transmitted.

 See the threads I referenced, they are still in the above quoted text.
 
 Note that the Google case is consistent: (as good as) every IPv6
 connection breaks.
 
 The Akamai case is random: sometimes it just works as you hit good
 nodes in the cluster, sometimes it breaks.

I see in the threads referenced things statements such as:

«this must be a major issue for everybody using IPv6 tunnels»
«MTU 1480 MSS 1220 = fix»
«the 1480MTU and 1220MSS numbers worked for my pfsense firewall»
«The only thing that worked here is 1280 MTU / 1220 MSS»
«clamping the MSS to 1220 seems to have fixed the problem for me»
«I changed the MSS setting [...] for the moment Google pages are
loading much better»

This is all perfectly consistent with common PMTUD mailfunctioning /
tunnel suckage. I'm therefore very sceptical that this problem would
also be experienced by users with 1500 byte MTU links. (Assuming
there's only a single problem at play here.)

 In both cases, it is hard to say what exactly breaks as only the
 people in those networks/companies have access to their side of the
 view.
 
 As such... here is for hoping they debug and resolve the problem.

Having some impacted users do a Netalyzr test might be a good start.
Like I said earlier, WFM, but then again I'm not using any tunnels.

Tore

Re: Google IPv6 measurements in Europe appear heading down...

[Tore Anderson]

* erik.tarald...@telenor.com

 Telenor Norway has had an pretty steep growth in IPv6 enabled
 subscribers since the summer.  We are the larges ISP in Norway, so
 rollouts we do usually are somewhat reflected in the graphs.  On the
 fixed access (DSL and fiber) we had approx. 60.000 lines 1. oct.
 Today (24.oct) we have more than 100.000 lines activated.  Yet the
 graph for Norway shows an flattening in the same time period.
 https://www.vyncke.org/ipv6status/compare.php?metric=pcountries=no. 

I've been somewhat puzzled about Google's Norway graph as well. If you
zoom in, there is a dramatic increase between the 25th of September and
the 7th of October, from 4.22% to 5.85%. In the same period, my own
data from VG has been rather stable, peaking at about 4.5% (see
http://goo.gl/XvoNLE).

I do see a more gradual increase during October due to
Telenor's roll-out (see http://goo.gl/7OWJqL), especially visible in the
last few weeks. However, as Erik points out, in the same period (after
the 7th of October), the Google graph has hardly moved. Very odd.

Tore

Re: Clueless national monopoly providers

[Tore Anderson]

* Frank Bulk

 Note that www.att.net has been down for 156 days, www.charter.com for 266
 days, www.globalcrossing.com for 829 days

These tree WFM from Oslo. They look fine from the NLNOG RING as well.

Tore

464XLAT CLAT for Linux

[Tore Anderson]

Hi list,

In the hope that someone will find this interesting, and would like to
test it out: I've just published an implementation of a 464XLAT CLAT for
Linux at https://github.com/toreanderson/clatd/. It integrates with
systemd/upstart/NetworkManager to automatically enable/disable the CLAT
when appropriate. TAYGA (http://www.litech.org/tayga) is used for the
actual RFC 6145 IPv4-IPv6 translations.

If your ISP doesn't support NAT64/DNS64, there are a few public
instances available which you can configure clatd to use instead:

http://ipv6.lt/nat64_en.php
http://go6lab.si/current-ipv6-tests/nat64dns64-public-test/
http://www.trex.fi/2011/dns64.html

(Considering that this list has been silent fir the last few days, I am
hoping you'll find this little shameless plug admissible...)

Tore

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Tore Anderson]

* Hannes Frederic Sowa

 Let me cook up a patch this week and depending on the size we maybe can
 get this into stable.

Wow, that¹ was fast, thanks! \o/

[1] http://thread.gmane.org/gmane.linux.network/301135

How do you rate the chances of it going into stable? Or will it be
targeted at 3.14, do you think?

Tore (who needs this to be able to dual-stack his UDP OpenVPN servers)

Re: I can fetch the header of websites via IPv6 but not the webpage, why?

[Tore Anderson]

* Ez mail

 Since I have no fr**king clue what could the problem be, I'm trying on
 this list :)

I concur 100% with Erik's assessment that this in all likelihood is a
PMTUD problem, specifically in the web_server-your_desktop direction.

I'd just like to add that the fact that you see it happening to several
independent websites that are known to be operated by competent staff,
and that the problem comes and goes, further indicates that it is due to
rate-limiting of ICMPv6 PTB replies from your tunnel broker's tunneling
router/server.

The ICSI Netalyzr (http://netalyzr.icsi.berkeley.edu/) will give you
very useful debugging output from the outside point of view. You might
have to run it a few times to to reveal the MTU blackhole though, due to
the problem's intermittent nature.

As Erik mentions, lowering the TCP MSS will likely work around the
problem. You can probably do this by having the RAs your router emits to
the LAN advertise an MTU of 1452 to match your tunnel (which in turn
should make your desktop default to a TCP MSS of 1392), and/or have your
router rewrite (clamp) the MSS value in TCP packets it forwards
to/from the tunnel to 1392.

Or, even better, get rid of the tunneling crap and get native IPv6. This
is a very common problem for IPv6 tunnels. As a web site operator I
would actually prefer it if people stayed IPv4-only until their ISP
could provide them with properly supported IPv6 connectivity. Oh well...

Tore

Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Tore Anderson]

* Hannes Frederic Sowa

 In its current form, not so good. If you can tell me specific software
 that *breaks*, I can ask. At first I thought I might be able to just
 switch an 'if' but the patch got a bit more complex.

What breaks is OpenVPN servers listening on an UDP IPv6 socket with
IPV6_V6ONLY=0. If an IPv4 client attempts to set up a tunnel to a
non-primary address of the server (for example in the case of a server
with multiple interfaces or dedicated service OpenVPN service
addresses), the OpenVPN process fails to use the address it was
contacted on when replying to the client, instead using the default IPv4
source address of the system. This in turn leads to the tunnel failing
to establish.

See: https://community.openvpn.net/openvpn/ticket/306

FWIW: So far the solution has been to simply keep the UDP server
IPv4-only, which works fine since with current versions of OpenVPN you
have to explicitly ask for IPv6 to be used, which nobody (except I)
does. However when OpenVPN 2.4 gets released the client will start using
standard getaddrinfo() and thus prefer IPv6 when available, and then
having no process listening on IPv6 in the server end becomes a real
problem - nobody likes timeouts...

 Maybe the workaround with IPv4 PKT_INFO does help for the time being.

Probably, although I'm guessing Gert would rather not go there when your
more proper fix is right around the corner. No worries, I'll look into
backporting the patch to the kernel I'm currently running or upgrading
to 3.14 once it's released. Thanks again!

Tore

Re: MTU handling in 6RD deployments

[Tore Anderson]

* Gert Doering

 Have a higher IPv4 MTU between the 6rd tunnel endpoints  sounds like
 a nice solution an ISP could deploy.

True, well, in theory anyway.

The reason I didn't include this in my list was that considering the
whole point of 6RD is to be able to bypass limitations of old rusty gear
that don't support fancy features like IPv6...the chances of that old
rusty gear being able to reliably support jumbo frames wasn't very high
either.

Tore

Re: MTU handling in 6RD deployments

[Tore Anderson]

* Templin, Fred L

 6RD could use SEAL the same as any tunneling technology. SEAL makes
 sure that packets up to 1500 get through no matter what, and lets
 bigger packets through (as long as they fit the first-hop MTU) with
 the expectation that hosts sending the bigger packets know what they
 are doing. It works as follows:
 
   - tunnel ingress pings the egress with a 1500 byte ping
   - if the ping succeeds, the path MTU is big enough to
 accommodate 1500s w/o fragmentation
   - if the ping fails, use fragmentation/reassembly to
 accommodate 1500 and smaller
   - end result - IPv6 hosts always see an MTU of at least 1500

In order for the BR to support reassembly it must maintain state. That's
going to have a very negative impact on its scaling properties...

Tore

Re: in6_pfx_newpersistaddr: %s is already configured

[Tore Anderson]

* Jared Mauch

 Anyone seen these logs on their machines?
 
 I get a fairly consistent set of syslogs on my machines (MacOS 10.9) each 
 time I get a RA from my cable modem.
 
 14:18:13.209477 20:e5:2a:b8:10:cf  33:33:00:00:00:01, ethertype IPv6 
 (0x86dd), length 174: (hlim 255, next-header ICMPv6 (58) payload length: 120) 
 fe80::22e5:2aff:feb8:10cf  ff02::1: [icmp6 sum ok] ICMP6, router 
 advertisement, length 120
   hop limit 64, Flags [managed, other stateful], pref medium, router 
 lifetime 1800s, reachable time 0s, retrans time 0s
 source link-address option (1), length 8 (1): 20:e5:2a:b8:10:cf
   0x:  20e5 2ab8 10cf
 prefix info option (3), length 32 (4): 2601:4:2180:300::/64, Flags 
 [onlink, auto], valid time 345600s, pref. time 345600s
   0x:  40c0 0005 4600 0005 4600   2601
   0x0010:  0004 2180 0300    
 unknown option (24), length 24 (3): 
   0x:  3800 0005 4600 2601 0004 2180 0300 
   0x0010:    
 rdnss option (25), length 40 (5):  lifetime 1200s, addr: 
 2001:558:feed::2 addr: 2001:558:feed::1
   0x:    04b0 2001 0558 feed  
   0x0010:    0002 2001 0558 feed  
   0x0020:    0001
 
 Dec  3 14:57:43 Jareds-NTT-iMac kernel[0]: in6_pfx_newpersistaddr: 
 2601:4:2180:300:426c:8fff:fe33:d4b0 is already configured!
 Dec  3 14:58:13 Jareds-NTT-iMac kernel[0]: in6_pfx_newpersistaddr: 
 2601:4:2180:300:426c:8fff:fe33:d4b0 is already configured!
 Dec  3 14:58:43 Jareds-NTT-iMac kernel[0]: in6_pfx_newpersistaddr: 
 2601:4:2180:300:426c:8fff:fe33:d4b0 is already configured!
 Dec  3 14:59:13 Jareds-NTT-iMac kernel[0]: in6_pfx_newpersistaddr: 
 2601:4:2180:300:426c:8fff:fe33:d4b0 is already configured!
 Dec  3 14:59:43 Jareds-NTT-iMac kernel[0]: in6_pfx_newpersistaddr: 
 2601:4:2180:300:426c:8fff:fe33:d4b0 is already configured!
 
 I'm trying to diagnose if this is related to a problem I'm seeing as well.

I haven't seen these myself (I don't have anything running Mac OS), but
the fact that the managed flag is set reminds me of a strange
behaviour I saw from a Cisco EPC3928 cable modem. It would give out
DHCPv6 IA_NA leases that was based on the client's MAC address using
EUI-64, in other words it would give out the exact same address as the
client would auto-configure itself with using SLAAC. I see you have a
Netgear, but if it behaves in the same way as my Cisco ... well, it
would make the is already configured message make some sense as it
probably got that address from DHCPv6 and so the SLAAC code would
probably fail to add it (again).

Tore

Re: 'Upgrading' NAT64 to 464XLAT?

[Tore Anderson]

* Bjørn Mork

 Tore Anderson t...@fud.no writes:
 
 This is implemented in Android - its wireless hotspot feature works just
 fine using IPv6-only + 464XLAT as the upstream mobile connectivity. The
 hotspot zone remains IPv4-only though,
 
 Really?  I have only tested on Android 4.2 (without the CLAT), but USB
 tethering with IPv6 seems to work fine.  The phone sends RAs with it's
 allocated prefix. It's also sharing the DNS64 enabled DNS servers via
 DHCPv6, so DNS64/NAT64 works fine from the clients (of the phone).

Didn't try USB tethering, but there's no IPv6 on the wireless one as
far as I can tell. Here's how it looks under the hood with wireless
tethering enabled, using IPv6 for upstream connectivity:

shell@maguro:/ $ ip -4 address list scope global   
10: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
inet 192.168.43.1/24 brd 192.168.43.255 scope global wlan0
760: clat4: POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP mtu 1480 qdisc pfifo_fast 
state UNKNOWN qlen 500
inet 192.0.0.4/32 brd 192.0.0.4 scope global clat4
shell@maguro:/ $ ip -6 address list scope global   
6: rmnet0: POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP mtu 1500 qlen 1000
inet6 2a00:e18:8000:474::f0d9:7a01/128 scope global 
   valid_lft forever preferred_lft forever
shell@maguro:/ $ ip -6 route show dev wlan0
shell@maguro:/ $ getprop ro.product.model  
Galaxy Nexus
shell@maguro:/ $ getprop ro.build.description  
yakju-user 4.3 JWR66Y 776638 release-keys

Tore

IPv6 support in the PlayStation 4?

[Tore Anderson]

Hi list,

Did any of you get to test whether or not the PS4 supports IPv6, and if
so to what extent?

Tore

Re: 'Upgrading' NAT64 to 464XLAT?

[Tore Anderson]

* Dick Visser

 I just am reading up on the RFC and it looks like it doesn't have to
 be on the end host necessarily:
 
 http://tools.ietf.org/html/rfc6877#section-6.5

This is implemented in Android - its wireless hotspot feature works just
fine using IPv6-only + 464XLAT as the upstream mobile connectivity. The
hotspot zone remains IPv4-only though, which results in the amusing fact
that when I'm accessing my own home page through the traffic is being
subjected to NAT44646 (the final 46 happening in my data centres). Not
that I'm complaining, it works just hunky-dory (NATs are good).

Tore

Re: Microsoft: Give Xbox One users IPv6 connectivity

[Tore Anderson]

* Mark Townsley

 On Oct 10, 2013, at 4:56 PM, Geoff Huston wrote:

 I have not gathered data on Teredo-to-Teredo reliability. The
 connection failure numbers quoted above make use of a Teredo Relay.
 But this teredo-to-teredo connection failure rate in the Internet
 appears to be a critical assumption here for this form of connection
 architecture.
 
 This does sound like something you could do with your measurement
 architecture. Just a little tweak here and there. Any chance of that?

I'm actually not so sure about that. p2p is a very different thing than
a controlled measurement of client connectivity to a known good web
server - even if that web server is on a Teredo address.

In this p2p case both ends may well be behind a stack of NATs each with
their own unique set of limitations and peculiarities. The whole
environment is anything but controlled.

So the question isn't whether or not Teredo is reliable per se, it's
more interesting to ask if it is more or less reliable than the current
STUN stuff in the Xbox 360 - and whether or not *that* is reliable to
begin with.
https://www.google.no/search?q=xbox+360+nat+type+moderate+strict seems
to answer that with not at all... I doubt Teredo is a whole lot
better, but I suspect it's as good as it gets on the IPv4 internet today.

Tore

Re: PTR records for IPv6

[Tore Anderson]

* Holger Zuleger

 I think the subnet address with all 64 bits set to zero is reserved by
 [1] as the subnet router anycast address.

Only if there's a subnet to begin with, so e.g. 2001:db8::/128 isn't a
subnet-router anycast address.

Also see RFC6164.

Tore

Re: Windows 7 / IPv6 on PPP Adapter

[Tore Anderson]

* Liviu Pislaru

 since there's no opinion about this issue here's my viewpoint:
 i think this isn't an RFC 5072 compliant implementation and Microsoft
 should fix that on Windows 7.

Hi Liviu,

I'm not intimately familiar with PPP on Win7, but what you describe
sounds broken to me. I'd suggest getting in touch with Chris Palmer
about this, he's with Microsoft(you'll find his e-mail address in the
list archives).

For what it's worth, if you're using IPv6 over 3GPP mobile broadband,
you get an entire /64 to play with - not only the single interface
identifier assigned by the network using PCO (which is bridged into
IPV6CP when using PPP). The only requirement is that you use the
network-provided interface identifier when constructing the link-local
address - no such restriction is placed on the choice of global address.
464XLAT is one example of a technology that uses more than 1 address
from the assigned /64, so the behaviour you describe would make it
impossible to implement 464XLAT on Win7 for users using 3G dongles in
PPP mode.

Tore