Just noticed that Switzerland's IPv6 deployment level (according to
Google) has been skyrocketing lately, anyone know if this is just an
outlier or something real and big going on?
http://www.vyncke.org/ipv6status/compare.php?metric=p&countries=ch
$ google-ipv6-adoption.pl
Pos IPv6% Country
* Tore Anderson
> Just noticed that Switzerland's IPv6 deployment level (according to
> Google) has been skyrocketing lately, anyone know if this is just an
> outlier or something real and big going on?
To answer myself, it doesn't seem to be an outlier, as APNIC obser
* Jeroen Massar
> H fd00::/8, that really should never ever be visible on the
> Internet, being Unique *LOCAL* Addresses.
FWIW this is not unique to ULAs. When tracerouting through AS174, for
example, you'll see IPv4-mapped IPv6 addresses, courtesy of 6PE. At
least that was the case a couple
* Jeroen Massar
> That is, if you have 6PE (IPv4 LSP) in your network routers might send
> an ICMPv6 message from the IPv6-Mapped-IPv4 address.
>
> And as ::::0.0.0.0/96 should not be in anybody's BGP table, it will
> fail uRPF.
>
> Is anybody aware of a knob that can force for instance the
* Arturo Servin
>> What is the problem you are trying to protect against?
>
> Against scanning the whole /64 and doing a DDoS to the router.
Hmm. The DDoS attack to PTP links would work equally well with /126,
there's no need to "scan the whole /64" - just flood a non-assigned
address with traff
* 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
* Gert Doering
> On Wed, Jul 24, 2013 at 10:05:16AM +0200, g...@switch.ch wrote:
>> A customer reported to us that many of his users have been getting the
>> "Our systems have detected unusual traffic from your computer network"
>> message from Google since last week. Apparently, this is only
>>
* Jeroen Massar
> On 2013-08-20 15:37 , Tayeb Meftah wrote:
>> Hi guys,
>> i am planing a lab to build a Recidential ISP Platform
>> i have a tunneled /48 and i cut of 4 of /64 for routing use (OSPFV3)
>> what's the current recomandation for recidential IPV6 assignement?
>
> The recommendation de
* 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
http://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47.pdf
Quoting from slide 2:
«Network operators that want to provide the best possible user
experience for Xbox One Users:
* Provide IPv6 Connectivity»
Gamers tend to be a demanding bunch. I can tell from a ton of forum
posts and
* John Mann
> ---
> Even for users that *do have native IPv6 – Teredo will be used to
> interact with IPv4-only peers*, or in cases where IPv6 connectivity
> between peers is not functioning. In general, Xbox One will dynamically
> assess and use the best available connectivity method (Native IPv6
* 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 crit
* Brandon Ross
> I'd like an option to rotate my privacy address for every TCP session.
Considering that DAD needs a couple of seconds to complete before a new
privacy address is usable, I bet you'd change your mind about pretty
quickly...
(Well, I suppose happy eyeballs might prevent the user e
Some cool news to start the day with:
http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506
Tore
* 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
* Bjørn Mork
> Tore Anderson 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 test
Hi list,
Did any of you get to test whether or not the PS4 supports IPv6, and if
so to what extent?
Tore
* Bjørn Mork
> But what I believe you missed above is that these devices are added to a
> common bridge device, and *this* is the device with the global /64 route:
Nope, I didn't miss anything. There is no bridge being set up on my
device. The "brctl" tool is nowhere to be found on the file syste
* 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-heade
* Simon Perreault wrote:
> Is there any other Fedora user on this list that could confirm this?
I can confirm that SLAAC-learned addresses are added as /128s on the
interface, but I don't see how this is a problem, not to mention
"broken"? The route to the on-link /64 does get correctly added her
* Hannes Frederic Sowa
> The kernel should install the IPv6 address with /64 prefixlen without also
> installing a prefix route for that subnet. Currently the kernel does this
> automatically.
I don't think you can do that from user-space. If you add a /64 (any >
/128 really), you automatically g
Hi list,
Does anyone know what tricks, if any, the major 6RD deployments (AT&T,
Free, Swisscom, others?) are using to alleviate any problems stemming
from the reduced IPv6 MTU? Some possibilities that come to mind are:
* Having the 6RD CPE lower the TCP MSS value of SYN packets as they
enter/exit
* Hannes Frederic Sowa
> It also had some affect of anycast address generation.
>
>> But you are right, essentially it should work but some assumptions were
>> made in the kernel which should have been checked first.
>
> I guess they're switching back to 64 while suppressing automatically adddin
* 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 ge
* 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
>
* 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, d
* 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 happen
* 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_V6
* Hannes Frederic Sowa
> Tunnels should actually work fine and icmp rate limiting should take
> place per destination (or on a /64 boundary). Either someone messed up
> their filters or we have a software bug (maybe we should just introduce
> a netfilter target which does mid-path fragmentation of
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
* Jakob Hirsch
> On 13.03.2014 20:12, Eric Vyncke (evyncke) wrote:
>> Christopher and others => you are RIGHT! Do not change your mind
>
> Right abouth _what_? You provided not a single reason for the described
> behaviour, i.e. the missing fallback to native IPv6.
According to Microsoft, there
* Jakob Hirsch
>> not all of the XB1s communicating have native IPv6, fallback to Teredo
>> is the expected behaviour.)
>
> "documented", yes, but sureley not "expected".
In my world view, the documentation defines the expected. If it didn't,
what's the point of having documentation?
>> involve
* 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
* Nick Edwards
> Speaking of 6to4, can anyone recommend an understandable by non
> networking types, easy setup how-to?
>
> Preferably with the entire thing on the one box (we have only one bit
> of software that does not understand ipv6, everything else does, so
> are not wanting a specific ded
* 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
* 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.
* 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
> >>&g
* 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 b
* 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
> &g
* 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
* 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 dispu
* Jeroen Massar
> Also note that the Akamai problem (which still persists) is a random
> one. Hence fetching one URL is just a pure luck thing if it works or
> not. As a generic page has multiple objects though, you'll hit it much
> quicker.
Hm. As I've said before - WFM. Any more information you
* Mikael Abrahamsson
> 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
* 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
* 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 yo
* 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
> IPv
* Anfinsen, Ragnar
> On 12.02.15, 12.24, "Tore Anderson" wrote:
>
> >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?
>
> Keep in mind that end cus
* Anfinsen, Ragnar
> On 12.02.15, 22.53, "Tore Anderson" wrote:
>
> >There's a non-zero amount of end customers who *do* care about IPv6.
> >After all, you do have a opt-in service which several thousand of
> >your customers did actually opt in to -
* Anfinsen, Ragnar
> My goal with my question was to find sensible arguments for keeping IPv4
> as a native service for now
Maybe I'm being dense, but you seem to already have all the answers to
this question yourself? For example:
- «The cost/benefit of doing anything else than keeping IPv4 as
* Philip Matthews
> 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 inv
* 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
* Lorenzo Colitti
> On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson 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 b
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 . :
>
* 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 r
* 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.
>
>
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. No
* 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,
> eff
* 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 worl
* Ted Mittelstaedt
> This kind of mirrors the "default" security policy on IPv4 CPEs (since
> those CPE's have NAT automatically turned on which creates a "block
> in, permit out" kind of approach.) so I'm not sure why you would want
> to default it to being different for IPv6.
There are a gazill
* Jeroen Massar
> RA's only install the /64 and when default announced a default.
>
> Thus 'the rest of the ULA /48' would require a default route to be
> installed to reach that...
>
> When the device does not install a default route, there won't be an
> entry for anything in that /48, just th
* 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 i
* Pim van Pelt
> Our webservers aren't going anywhere, but it may take a little while
> to piece out the ULA bits from the other database activity we have,
> and it's my intention to destroy the PII (ie the database) after the
> sunset. I'll make a note of coming back to this after the dust
> sett
* 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
* David Farmer
> I think that means the Target address, and therefore the destination
> address of the packet, could be a Link-Local, GUA, or ULA address,
> and the source of the packet could be a Link-local address.
The source address could very well be GUA or ULA, too:
«If the source address
* 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
* 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
> aut
66 matches
Mail list logo
