Re: Realistic number of hosts for a /64 subnet?

2019-05-14 Thread Mikael Abrahamsson

On Tue, 14 May 2019, WILSON Sam wrote:

Except those nasty security people are now allowing systems to randomise 
their MAC addresses.  I'm sure some people's Life Goal is to make life 
as difficult as possible for us network operators.


That's why one should always create solutions that do not depend on any 
kind of uniqueness.


15 years ago I checked the mac addresses of our customers (ADSL customer 
base). I noticed that 5% of the customers were using the same mac address. 
Tracked that down to D-Link shipping lots of routers via electronics 
stores, all with the same mac address. Then I was happy I had designed the 
solution with single broadcast domain (vlan) per customer so this still 
worked. Other ISPs weren't so lucky, and this caused significant customer 
service costs.


If you want a robust access network, make sure it works even if the 
customers have customer-controlled identifiers that overlap, such as DUID, 
MAC addresses etc. Track people on physical ports (so you know where that 
port/cable goes) or on username/password (802.1x). Make sure the 
customers/users can't affect each other (protect the Internet from them).


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Realistic number of hosts for a /64 subnet?

2019-05-10 Thread Mikael Abrahamsson

On Thu, 9 May 2019, Doug Barton wrote:

It's been a while since I was configuring subnets, and last time I did the 
guidance was always no more than 1,000 hosts per subnet/vlan. A lot of that 
was IPv4 thinking regarding broadcast domains, but generally speaking we kept 
to it for dual stacked networks, equating an IPv4 /22 with an IPv6 /64. (This 
was commonly in office environments where we used a subnet per floor to 
accommodate all of the desktops, printers, phones, tablets, etc.)


Is this still how people roll nowadays? Have switches and/or other network 
gear advanced to the point where subnets larger than 1k hosts are workable? 
In IPv4 or IPv6? I've done quite a bit of web searching, and can't find 
anything newer than 2014 that has any kind of intelligent discussion of this 
topic.


It's a good topic to bring up. There has been some work on this in the 
IETF, for instance https://tools.ietf.org/html/rfc8273


This means there is single broadcast domain and single /64 per customer, 
which if properly implemented helps with a lot of the problem space people 
like to solve in this area. It however includes moving away from quite a 
lot of what you call "IPv4 thinking".


I however do not operate wifi networks so I have no idea how widely this 
is implemented in gear available today. If someone else knows, I would 
appreciate if they would share.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: IPv6 on VoLTE

2018-11-07 Thread Mikael Abrahamsson

On Wed, 7 Nov 2018, Anurag Bhatia wrote:


I recently got VoLTE from my provider (AS9498). I noticed that after
VoLTE is enabled, device is creating two IPsec tunnels and also has
IPv6 address on those IPsec tunnels.

Was wondering if someone can point me to any paper/documentation on
how VoLTE works and how this IPv6 over ipsec works in the background?


https://en.wikipedia.org/wiki/Voice_over_LTE , there should be links to 
the 3GPP specifications.


I have not heard of VoLTE using IPSEC, that's not how it was supposed to 
work at least when I looked into this 5 years ago. Instead it should have 
additional bearer on mobile interface to handle this traffic.


How are you identifying this as IPSEC tunnels? What kind of device is it 
you're looking at?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: IPv6 plan for multisite corporate

2018-05-21 Thread Mikael Abrahamsson

On Mon, 21 May 2018, Luigi Rosa wrote:


Hi,
one of my customer is a US corporate with offices literally on 5 continents 
and one datacentre. Offices are connected each other and to the datacentrevia 
MPLS, each office accesses the Internet via local ISP.


Since they asked me to start planning for IPv6, my idea was originally to buy 
a netblock from ARIN (maybe a /40) and use it for the offices (each office 
has many different IPv4 networks).


My concern is: if I buy a netblock from ARIN and use it in every office, how 
can I handle the access to local ISP?


I thing I should NAT the netblock of each office to handle the routing, or is 
there some other way to do so?


https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-06 
might be relevant to your requirements.


If you feel you must perform NAT, make sure you do 1:1 NAT and not 1:N NAT 
(ie, create a solution where each internal IPv6 address gets a unique 
external address so you avoid all the port translations).


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Win10 update CLAT

2017-07-27 Thread Mikael Abrahamsson

On Thu, 27 Jul 2017, Ross Chandler wrote:

I've had no luck getting it to work either on an IPv6-only LAN with 
DNS64 and NAT64. Ross


After reading the text again, I speculated that it was Win10 mobile only. 
I therefore dug up a win10 mobile phone I have, and updated it, and tried 
to connect to NAT64+DNS64 wifi I have. After updating it to 1703 I still 
can't see any CLAT being detected in any way (for instance test-ipv6.com).


So the only thing I can think of is that the CLAT is mobile-only on win10 
mobile only. So I put in a SIM card in it and tried to create a new APN, 
and it indeed does have a new APN type called "IPv4v6XLAT" (in addition to 
"IPv4", "IPv6" and "IPv4v6"). Unfortunately my mobile provider is dual 
stack and doesn't offer NAT64+DNS64 (at least not on its default APN) so I 
can't test it.


So my take on this is that it's a Win10 only feature, and it's mobile 
only.


Pity.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Win10 update CLAT

2017-07-27 Thread Mikael Abrahamsson


Hi,

I did all the updates in Win10 because of the claim that CLAT would be 
included in the latest updates. I can't make it work. DNS64+NAT64 works 
correctly, but I can't ping IPv4 literals (expected behaviour of a host on 
IPv6-only+DNS64+NAT64 without CLAT).


https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/

"Improved 464XLAT support
464XLAT was originally designed for cellular only scenarios since mobile 
operators are some of the first ISPs with IPv6 only networks.  However, 
some apps are not IP-agnostic and still require IPv4 support.  Since a 
major use case for mobile is tethering, 464XLAT should provide IPv4 
connectivity to tethered clients as well as to apps running on the mobile 
device itself. Creators Update adds support for 464XLAT on desktops and 
tablets too. We also enabled support for TCP Large Send Offload (LSO) over 
464XLAT improving throughput and reducing CPU usage."


Is there anything specific I need to do to enable this?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: question regarding over the counter devices

2017-03-07 Thread Mikael Abrahamsson

On Tue, 7 Mar 2017, Brian E Carpenter wrote:

I notice this because I log IPv6 connectivity. My wife has no idea this 
is going on. (Why my ISP offers inconsistent IPv6 service is another 
question, which their help desk cannot answer.)


Yeah, I have the same experience. Historically I've had my IPv6 down for 
days before I actually needed it to ssh home to one of my devices. HE 
solvs most user issues.


Only thing that makes it break is if there is PMTUD blackhole. So better 
to stop IPv6 (or IPv4) working completely, than to introduce PMTUD 
blackhole.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: question regarding over the counter devices

2017-03-06 Thread Mikael Abrahamsson

On Mon, 6 Mar 2017, Gert Doering wrote:

3G mandated IPv6, no carrier actually deployed it *before* they had a 
huge legacy of IPv4-only handsets in the field...  could have been done 
from day one.


On the other hand no handset manufacturer apart from Nokia ever made any 
3G handsets that supported IPv6.


Also, since you needed two concurrent bearers and the 3GPP network vendors 
charged per bearer, it also make IPv6 deployment extremely expensive.


Yes, plenty of blame to go around. It's not only a carrier problem.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: question regarding over the counter devices

2017-03-06 Thread Mikael Abrahamsson

On Mon, 6 Mar 2017, Gert Doering wrote:

If a CPE has no v6 support, having it available on the DSLAM (in passive 
mode = do not start IPv6CP until the client initiates it) will not do 
harm.


The issue here isn't devices that do not support IPv6, it's the ones that 
do support IPv6 when it "suddenly" is turned on.


The mobile carriers nicely demonstrated how *not* to do it - by ignoring 
the mandate for IPv6 in 3G, and rolling out huge masses of v4-only 
handsets, they suddenly had a huge installed basis of, well, v4-only 
legacy devices to deal with...


Most carriers do not control handsets anymore. Those days are long gone.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: question regarding over the counter devices

2017-03-01 Thread Mikael Abrahamsson

On Wed, 1 Mar 2017, Nick Buraglio wrote:


Is this actually a realistic fear?


Let me put it this way, I have personally found an anon-ftp server with 
company confidential documents on it, that was reachable from the outside 
without the owners knowledge, because there was a port-forward in the 
residential gateway that the owner wasn't actively aware of, and the NAS 
had anon-ftp turned on without the owners active knowledge.


So google had indexed all files on this NAS. I contacted the person (did 
some digging using pictures etc on this NAS) via their employer, and 
talked to the person who had no idea.


Now, with unfiltered IPv6 it would be harder to actually find this NAS, 
but once found, there is no need for port forward for it to be reachable 
from the Internet.


So yes, I can understand the fear and I agree that it's realistic. That's 
why most ISPs have chosen to have stateful filtering toward the customers 
by default.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: question regarding over the counter devices

2017-03-01 Thread Mikael Abrahamsson

On Wed, 1 Mar 2017, Bjørn Mork wrote:


As an ISP: If you don't manage the CPE, should you even care?


That is good question. In Sweden ISPs have gotten in trouble historically 
for not filtering stuff and customers files were exposed. For instance 
when ETTH had people plug their computers directly into the ETTH RJ45 jack 
(12-15 years ago), had no-password SMB shares on their computers, and 
there was no broadcast filtering on the LAN. Then they could "see" other 
users SMB shares and access them, and this made the papers as "unsecure". 
This was blamed on ISPs, not users.


So when IPv6 now comes along, ISPs are scared that users might have 
no-firewall IPv6 devices, so when IPv6 is enabled all of a sudden lots of 
unsecured devices are then reachable from the Internet, devices that were 
configured in that way because before NAT "protected" them.



yes, yes, being nice is good.  But this is an impossible task.  There is
no way you can make assumptions about the security of any unmanaged CPE,
with or without IPv6.


I tend to agree, but I can also understand why an ISP might hesitate in 
this case.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: question regarding over the counter devices

2017-03-01 Thread Mikael Abrahamsson

On Wed, 1 Mar 2017, JORDI PALET MARTINEZ wrote:


IPv6 firewall non-on by default. I’ve 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 just checked Netgear R6100. Factory default has "IPv6 disabled", when I 
change it to "Auto Detect" the setting "IPv6 filtering" is "secured" by 
default.


So this seems to be same thing that you've been seeing.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: question regarding over the counter devices

2017-02-28 Thread Mikael Abrahamsson

On Wed, 1 Mar 2017, JORDI PALET MARTINEZ wrote:

What I’ve seen, yes is on by default, but I also heard the same 
complain, but actually never seen a device not-on by default … so I’m 
not really convinced is very real.


"not-on", do you mean "IPv6" or "IPv6 firewalling"?

--
Mikael Abrahamssonemail: swm...@swm.pp.se

question regarding over the counter devices

2017-02-28 Thread Mikael Abrahamsson


Hi,

I just had a discussion with people from an ISP in the process of 
implementing IPv6. They were afraid of turning on IPv6 for customers who 
had purchased their own routers themselves, because these routers might 
not have IPv6 firewalling on by default, thus exposing customers who used 
to be "protected" by IPv4 NAT, to now be exposed with unfirewalled IPv6.


So my question:

Devices that people buy in electronics stores etc, do they even come with 
IPv6 turned on by default?


If they do, is firewalling turned on by default?

My Apple Airport Express at least came with firewalling turned on, I don't 
remember what the default setting was for IPv6 support. But if one turned 
on IPv6 support, then one had to unclick the firewall clickbox to be able 
to get incoming connections.


I'm going to check the devices I have in my boxes here at home, but in the 
mean time would appreciate if others could share their experiences.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: contact with One & One ?

2016-10-14 Thread Mikael Abrahamsson

On Fri, 14 Oct 2016, Paul Stewart wrote:

honestly we’ve never fixed it.  it works for lots of customer/visitors 
but breaks for others (and they fail back to IPv4) - we thought it was


Errr, how does this fallback work? I am not aware of any such mechanism.

Happy Eyeballs is done when the SYN+ACK gets back.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: contact with One & One ?

2016-10-14 Thread Mikael Abrahamsson

On Fri, 14 Oct 2016, Kurt Jaeger wrote:


www.corso-kino.de


Thanks.

If it helps, point them to this website (still in development/beta):

https://ipv6alizer.se/

The result is (verifies what you said):

INFO:  server-mss 1440, result: pmtud-fail
ERROR: http://www.corso-kino.de don't listen to PTB

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: DHCPv6 client in Windows 10 broken after anniversary update

2016-10-10 Thread Mikael Abrahamsson


So I did some more investigation. I had missed that I needed to use 
/renew6 and /release6 before.


Now I have 10 minute lease time.

5 minutes into the lease time, I can /renew6 the lease successfully and 
get 10 more minutes leasetime.


around 2-3 minutes before the lease-time expires I see that Win10 has 
marked the IA_NA as (deprecated), I try to do "/renew6" I get the 
following error:


"An error has occured while renewing interface Ethernet: The semaphore 
timeout period has expired".


This renew fails. If I now ctrl-c this /renew6 and run /renew6 again, the 
renew succeeds and the address is back again as (preferred) and the lease 
time is 10 minutes.


I also have a Ubuntu 16.04 box that won't keep its lease either... so I 
don't know what's going on. Will look further.


Harald, what DHCPv6 server are you using?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Re: Re: CPE Residential IPv6 Security Poll

2016-09-27 Thread Mikael Abrahamsson

On Mon, 26 Sep 2016, Ted Mittelstaedt wrote:

Well there is an answer to that.  Instead of paying your development 
team to do a from-scratch build, you can just have them port over dd-wrt 
or openwrt.  Both of these router firmwares are most likely tremendously 
advanced over anything your CPE development team can come up with.


I've been working with this for the past 3 years or so. We have a CPE 
using OpenWrt we use as development platform.


So while OpenWrt is great for supporting development of new protocols, 
it's nowhere near as stable/bug free as one of the more restrictive vendor 
CPEs. When you have millions of devices in the field, shipping OpenWrt 
with all the bells and whistles available would be just a nightmare. If 
one were to restrict it a lot and just use the features "needed", then it 
might be managable. I know some vendors who do this and ship HGWs based on 
OpenWrt. It's however quite heavily modified OpenWrt from what I can tell, 
and they don't rev their versions as fast as the OPenWrt project does.


I am sorry about this but there you have it.  The largest ISPs out there 
are solving the support issue by basically offering no useable support, 
the customer calls in, complains something doesn't work and is told to 
go away and find someone else to help them.  These ISPs know that no 
matter how angry the customer gets with a non-answer, that ultimately 
the customer knows if they quit service and go to another large 
competitor that the other large competitor is going to treat them 
exactly the same way - so they don't benefit by quitting service.


90% (or more) of people want their ISP to just "FIX IT! FIX IT! FIX IT!". 
So we're going to see more and more ISP provided equipment in peoples 
homes and ISPs getting more and more involved in running the home 
networks.


This is not something the ISPs are generally great at, the product cycles 
are generally long, it's quite a lot of "let's come up with something that 
works, is fairly bug free, then run the production line for 3 years, oh, 
and we need to support it for another 3-5 years". This is not a great 
combination with some customers wishes to always have the latest and 
greatest. Very few people give any kind of love to their "home router". 
They go and buy a USD40 device (or complain to the ISP that it's too 
expensive when the ISP wants to charge that kind of money for it) and then 
they connect their 1000 USD iPhone to it and expect everything to work 
great.


But I also (I think we're in agreement here) think I am seeing people more 
interested in their home networks now compared to 5-10 years ago. More 
people now know that you shouldn't put your wifi router in the basement 
behind a lot of boxes if you want good wifi coverage. But there is more to 
be done here, and we need more tools to help the customers figure out 
what's wrong. Doing truck rolls to fix peoples home networks is going to 
be too expensive, so we need home network devices (and SoHo devices) to 
talk to each other so they can figure out what's going on and give advice 
to the customer. Right now I see forum posts all the time with people 
frantically kicking all the things to try to figure out what's going on. 
There is no indication to them if the connectivity is bad because the 
problem is in their home network, on the access line, ISP core network, or 
further out from the Internet. People just don't have the tools to help 
them understand what's going on. The only thing they can say is "my 
Internet is slow", which of course says nothing what the problem really 
is. Current devices can't even tell them if DNS lookups are slow, if TCP 
establishment is slow, if TCP transfer rate is low because of packet loss, 
because of high delay, because of something else. This information just 
isn't available to the end user, and it's sad state of affairs.


The IETF, vendors and ISPs are all quite siloed so I don't know where we 
would start to actually improve this. I tried talking to the TCP people at 
the IETF and had no takers. I tried talking to the IPPM people, but they 
just want to measure with test traffic. I don't know who to talk to next.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: A=1 L=0 PIO

2016-08-16 Thread Mikael Abrahamsson

On Tue, 16 Aug 2016, Bjørn Mork wrote:


if (L) then add route
if (A) then do autoconf


Win10 and MacOS seems to do the same as you described here.

Ok, goodness, that's what I wanted to hear.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: A=1 L=0 PIO

2016-08-16 Thread Mikael Abrahamsson

On Tue, 16 Aug 2016, Enno Rey wrote:

from my memory: yes to all of those, for common desktop OS (Win, Linux, 
Max OS-X). When we did the lab testing for this one 
(https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf) 
we played a bit with the L-flag as well, so the L=0 + A=1 scenario 
occurred. I don't remember any case where the things you mention did not 
happen. We still have that lab infrastructure so we can repeat (some of) 
the tests with L=1 (and without DHCPv6). Let me know if you (or the 
group) is interested; we can assign a student to the task. (I'm on 
family holiday myself until end of Aug).


I just tried A=1 L=0 with the following operating systems, all fully 
updated with whatever latest versions is shipping to normal people.


Windows 10
MacOS 10.11.6
iOS 9.3.4
Android 5.1.1
Linux 14.04 LTS

They all did what I consider "the right thing". They autoconfigured 
addresses and used them, and they did DAD on the link.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


A=1 L=0 PIO

2016-08-16 Thread Mikael Abrahamsson


Hi,

I'm trying to figure out what a "normal" currently deployed in the field 
IPv6 host would do if it receives an RA with PIO /64 where L=0 and A=1.


I've skimmed RFC4861 and RFC4862 without finding an answer.

Thoughts on this? I can of course try it out myself, but I have a limited 
number of operating systems available. Anyone here have any data or other 
insights?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Netflix hates IPv6

2016-06-15 Thread Mikael Abrahamsson

On Wed, 15 Jun 2016, Michael Oghia wrote:

That is a good and constructive suggestion. Forgive me if I'm a broken 
record, though, when I ask if Netflix is involved at any level or even 
aware of this discussion? If not, it seems advantageous to me to invite 
them to be included.


Every point that has been made on this list so far, has already been made 
in the huge thread on nanog-l. I would take for granted that Netflix is 
aware of that one.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: DHCPv6 relay with PD

2016-06-08 Thread Mikael Abrahamsson

On Wed, 8 Jun 2016, Ole Troan wrote:


I've talked to several people who claim there are lots of equipment out there 
which will happily do DHCPv6 relaying of PD messages, but then not install a 
route for the corresponding delegation.


That's perfectly fine behaviour by the way.
DHCPv6 PD snooping is just one way of doing route injection, among many.


Ok, I invoke https://en.wikipedia.org/wiki/Principle_of_least_astonishment

Does the DHCPv6-PD server backend have access to all information needed to 
trigger a provisioning system to install/remove a static route on the 
relay?


What other methods are there apart from provisioning a static route on the 
relay? BGP?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


DHCPv6 relay with PD

2016-06-02 Thread Mikael Abrahamsson


Hi,

I've talked to several people who claim there are lots of equipment out there 
which will happily do DHCPv6 relaying of PD messages, but then not install a 
route for the corresponding delegation.


One example seems to be HP 5400zl.

My own experience is only when I did this with a DOCSIS CMTS, which did install 
a static route properly. The two other examples I have are with DHCPv6(-PD) 
server running on the L3 device itself (no relaying), a Huawei 5300 L3-switch 
and a Cisco 7206 router. Both of them properly installed that corresponding 
static route as soon as the DHCPv6-PD process had completed the delegation.


I'm looking for experience with other equipment, please share!

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: MTU/MSS testing IPv6

2016-05-27 Thread Mikael Abrahamsson

On Fri, 27 May 2016, Matthew Luckie wrote:


Pass it an http or https URL of an object to test against.


This is great! Good work!

tbit from 2001:df0:4:4000::1:115 to 2001:67c:2b24:1000::30
 server-mss 1380, result: pmtud-fail
 app: http, url: http://www.tullverket.se/
 [  0.010] TX SYN 64  seq = 0:0
 [  0.331] RX SYN/ACK 64  seq = 0:1
 [  0.332] TX 60  seq = 1:1
 [  0.332] TX236  seq = 1:1(176)
 [  0.652] RX 60  seq = 1:177
 [  0.664] RX608  seq = 1:177(548)   ECT
 [  0.664] RX970  seq = 549:177(910) ECT
 [  0.664] TX 60  seq = 177:549
 [  0.664] TX 60  seq = 177:1459
 [  0.665] RX   1428  seq = 1459:177(1368)   ECT
 [  0.665] RX299  seq = 2827:177(239)ECT
 [  0.665] TX PTB   1280  mtu = 1280
 [  0.669] TX 60  seq = 177:1459
 [  0.985] RX   1428  seq = 3066:177(1368)   ECT
 [  0.985] RX   1428  seq = 4434:177(1368)   ECT
 [  0.985] RX   1428  seq = 5802:177(1368)   ECT
 [  0.985] RX   1428  seq = 7170:177(1368)   ECT
 [  0.990] RX   1428  seq = 8538:177(1368)   ECT
 [  1.943] RX   1428  seq = 1459:177(1368)
 [  1.943] TX PTB   1280  mtu = 1280
 [  3.863] RX   1428  seq = 1459:177(1368)
 [  3.863] TX PTB   1280  mtu = 1280
 [  7.704] RX   1428  seq = 1459:177(1368)
 [  7.704] TX PTB   1280  mtu = 1280
 [ 15.384] RX RST 60  seq = 9906:177

Here it's clear (to me) that they're not acting on the PTB message (just 
keep resending large packtes).


Question is how could this be translated into a more easily understandable 
test with some suggestions on what might be wrong? Because if I send the 
above to someone who isn't an IPv6 expert, I'd have to include 10-20 lines 
of text to explain why above behaviour is wrong.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: v6 naming and shaming - *.europa.eu

2016-05-18 Thread Mikael Abrahamsson

On Wed, 18 May 2016, Phil Mayers wrote:



Ok so basically, if more/most access networks were IPv6-enabled (because 
big or vital providers are IPv6 only) then all service networks would 
have to get it working?


Yes, if it's broken from one network but works from the rest, then the 
problem to fix is for that broken network.


If it's broken for everybody, then it's the one who has the broken end 
that needs to fix.


This is the same thing with IPv6, DNSSEC and all such new technologies. If 
there is only one ISP that does DNSSEC validation and it's broken because 
the zone is signed wrong, then that ISP gets blamed. In Sweden, where 85% 
of customers sit behind a DNSSEC validating resolver, nobody gets away 
with screwing up their zone signing because now it's their problem.


It's all about critical mass.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: push apps failing in Android until you disable IPv6

2016-05-13 Thread Mikael Abrahamsson

On Mon, 9 May 2016, JORDI PALET MARTINEZ wrote:


Just got a “screen” capture from one of those situations (rdisc6).

Hopefully is useful ! They made it from a virtual machine in the same network 
as the Androids have the problema, having the VMware interfaces in bridge mode.


So that looks like something is sending an RA, announcing itself as a 
router but there are no addresses to be used on the link (there is no 
on-link prefix thus implicitly A=0, and M=0).


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.


According to standards, this shouldn't be a problem. IPv6 would not be 
used to communicate with the outside world.


Looking at https://tools.ietf.org/html/rfc6724 2.1 and the table there. 
Why is there nothing there matching fe80::/10 ? I guess it just implicitly 
takes for granted that anything in fe80::/10 can't be used without also 
specifying the interface? If someone did something "smart" and thought 
they'd help the user by not requiring them to specify interface, then this 
might cause problems unless the application immediately gets an error 
back? And if it gets an error back, how do we know it tries the next 
option, for instance IPv4? Could this be the problem here, the 
applications only try one address family and if that doesn't work, it 
won't establish the notification channel?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: push apps failing in Android until you disable IPv6

2016-05-10 Thread Mikael Abrahamsson

On Tue, 10 May 2016, Erik Kline wrote:


It's really not clear to me what that version of rdisc6 would print if
it encounters options about which it did not know anything.  A pcap of
just an RA would be best.  The adb commands I pasted should also
suffice to show what the device thinks it has for DNS, routes,
everything.


The version of rdisc6 included in Ubuntu 14.04 displays recursive DNS 
server.


This is also seen in "tcpdump -vvv -n -i eth0 icmp6" and I see it as:

rdnss option (25), length 24 (3):

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: ip switching from ipv4 to ipv6

2016-04-29 Thread Mikael Abrahamsson

On Fri, 29 Apr 2016, re wrote:

but is there any explanation to the repeated changing of the ip address 
from ipv4 to ipv6?


https://en.wikipedia.org/wiki/Happy_Eyeballs

If network conditions change then IPv4 or IPv6 might be preferred over 
time. It'll usually give a little bit of head-start for IPv6 (depending on 
implementation), but if v6 is significantly worse parts of the time, then 
you'll see the client bouncing between versions.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: ip switching from ipv4 to ipv6

2016-04-29 Thread Mikael Abrahamsson

On Fri, 29 Apr 2016, re wrote:


is it us or the deutsche telekom who is causing the problem?


This isn't a problem, this is expected behavior.

Don't trust the IP address to be stable, at least not between IPv4/IPv6.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


MTU/MSS testing IPv6

2016-04-29 Thread Mikael Abrahamsson


Hi,

I've run into a scenario where a website doesn't seem to be listening to 
PTB. I can reach them just fine from an MTU1500 clean IPv6 connection, but 
if I reach from a MTU1500<->MTU1480<->MTU1500 connection, it doesn't work. 
I don't get the big packets after SYN handshake.


I've been considering asking iis.se (the .SE ccTLD registry) who are 
already running multiple testing tools for web sites and domain name 
owners) to include these kinds of testing, and perhaps develop more of 
them.


So I'd like to gather some information and feedback here.

1. Are there are already FOSS tools out there that could be used for this, 
or would be good to enhance to include capability for this kind of 
testing. I don't want to waste work, and if I can enhance FOSS tools 
already existing and also solve my problem, that's a double win.


2. Test cases? From my testing, I've seen two different behavior just in 
the last two days:


Site A as described in top paragraph, probably doesn't listen to PTB. Can 
be either because they drop PTBs, or traffic traverses a load 
balancer/IPv4v6proxy that doesn't correctly handle PTB.


Site B which sends all data packets as fragments. This is most likely 
because they have some kind of AFTR where the IPv4 side has MTU1500 and 
the IPv6 side has MTU1320 or something like that.


Neither of this is of course optimal, and I'd like to be able to test for 
these and tell the site owner that their solution either is broken or 
suboptimal (the fragment case isn't strictly broken, it's just not a good 
way to do things).


Opinions? Thoughts?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Slow WiFi with Android Marshmallow & IPv6?

2016-04-27 Thread Mikael Abrahamsson

On Tue, 26 Apr 2016, Jeroen Massar wrote:


specifically a 'router' but a CPE (that for IPv4 NATs and for IPv6 sorta


Let me just say that when I used "CPE" in a document, I was reminded by 
BBF (BroadBand Forum) people that they use "CPE" as "any device in the 
home". Their terminology for the first router in the home is "RG" as in 
"Residential Gateway".


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Ubuntu 16.04

2016-04-23 Thread Mikael Abrahamsson

On Sat, 23 Apr 2016, Tore Anderson wrote:


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


This worked for me perfectly, and restored the old behavor so I get an 
EUI64 address. Thanks!


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Ubuntu 16.04

2016-04-22 Thread Mikael Abrahamsson

On Fri, 22 Apr 2016, Bjørn Mork wrote:


$ ip -d link show dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode 
DORMANT group default qlen 1000


$ ip -d link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP 
mode DEFAULT group default qlen 1000
link/ether 90:fb:a6:8a:7d:de brd ff:ff:ff:ff:ff:ff promiscuity 0 
addrgenmode none

I have another machine I upgraded that does still use EUI64. I will 
compare settings and try to find out what the difference between them is.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Ubuntu 16.04

2016-04-22 Thread Mikael Abrahamsson

On Fri, 22 Apr 2016, Jeroen Massar wrote:


Isn't it awesome that Ubuntu wants dynamic addresses on servers? :)


Well, this wasn't a server, this is installed as a desktop.


They have been told about that problem by many people already,
unfortunately, they claim to know better...


Who are "they"?


But, check your 'sysctl -a | net.ipv6.conf' you might find some knobs
there. Next to that, check systemd settings as that thing wants to take
over the kernel and thus ignores those settings and comes up with it's
own...


It's strangem it looks like they still have the kernel to process RAs? 
Doesn't it seem like the kernel now has support for the kind of stable 
non-EUI64 based addresses from https://tools.ietf.org/html/rfc7217 ?


http://unix.stackexchange.com/questions/251401/cannot-read-key-net-ipv6-conf-all-stable-secret-in-sysctl 
seems to indicate that the error message below is because the secret isn't 
set? So potentially if I set the secret I'll get the same address every 
time? Let's try...


$ sudo sysctl -a | grep net.ipv6.conf | grep -i eth0
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.eth0.stable_secret"
net.ipv6.conf.eth0.accept_dad = 1
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.accept_ra_defrtr = 0
net.ipv6.conf.eth0.accept_ra_from_local = 0
net.ipv6.conf.eth0.accept_ra_min_hop_limit = 1
net.ipv6.conf.eth0.accept_ra_mtu = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 0
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.eth0.accept_ra_rtr_pref = 0
net.ipv6.conf.eth0.accept_redirects = 1
net.ipv6.conf.eth0.accept_source_route = 0
net.ipv6.conf.eth0.autoconf = 1
net.ipv6.conf.eth0.dad_transmits = 1
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.eth0.force_mld_version = 0
net.ipv6.conf.eth0.force_tllao = 0
net.ipv6.conf.eth0.forwarding = 0
net.ipv6.conf.eth0.hop_limit = 64
net.ipv6.conf.eth0.ignore_routes_with_linkdown = 0
net.ipv6.conf.eth0.max_addresses = 16
net.ipv6.conf.eth0.max_desync_factor = 600
net.ipv6.conf.eth0.mc_forwarding = 0
net.ipv6.conf.eth0.mldv1_unsolicited_report_interval = 1
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
sysctl: reading key "net.ipv6.conf.wlan0.stable_secret"
net.ipv6.conf.eth0.mldv2_unsolicited_report_interval = 1000
net.ipv6.conf.eth0.mtu = 1500
net.ipv6.conf.eth0.ndisc_notify = 0
net.ipv6.conf.eth0.proxy_ndp = 0
net.ipv6.conf.eth0.regen_max_retry = 3
net.ipv6.conf.eth0.router_probe_interval = 60
net.ipv6.conf.eth0.router_solicitation_delay = 1
net.ipv6.conf.eth0.router_solicitation_interval = 4
net.ipv6.conf.eth0.router_solicitations = 3
net.ipv6.conf.eth0.suppress_frag_ndisc = 1
net.ipv6.conf.eth0.temp_prefered_lft = 86400
net.ipv6.conf.eth0.temp_valid_lft = 604800
net.ipv6.conf.eth0.use_oif_addrs_only = 0
net.ipv6.conf.eth0.use_tempaddr = 2


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Ubuntu 16.04

2016-04-22 Thread Mikael Abrahamsson


Hi,

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".

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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google<<>>Deutsche Telekom

2016-03-06 Thread Mikael Abrahamsson

On Sun, 6 Mar 2016, Christian Kildau wrote:


Hi,

I can confirm I am also having issues reaching anything behind 15169 via
3320.
Example src:  2003:de:4be0:a800::/56, dst: 2a00:1450:4016:804::2003.
$ traceroute6 google.de
traceroute6 to google.de (2a00:1450:4016:804::2003) from
2003:de:4be0:a800:cd43:321a:ad4e:b726, 64 hops max, 12 byte packets
1  fritz.box  1.793 ms  1.195 ms  1.013 ms
2  p200300de4bbf20a80001.dip0.t-ipconnect.de  10.093 ms *
10.843 ms
3  * * *


I don't have any insight, but it could be that Google is now doing the 
same thing to DTAG as it has done to Cogent for a few weeks, ie 
specifically ask its transit partners to not announce 15169 routes to 
AS3320, and deciding AS15169 now to be IPv6 Tier1, and if you don't peer 
with AS15169, you're not getting the routes.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Windows 10 + VLC + IPv6 SSM

2016-02-22 Thread Mikael Abrahamsson

On Sun, 21 Feb 2016, Harald F. Karlsen wrote:

They broke IPv6 multicast streaming in VLC version 2.0.6. It works in 
version 2.0.5 although it required that you opened for ICMPv6 type 143 
outgoing in the windows firewall (at least in Windows 7) in order to get 
SSM to work. ASM worked fine iirc.


I opened a ticket with the Videolan team 15 months ago, but the ticket 
hasn't received much attention: 
https://trac.videolan.org/vlc/ticket/13071


Thanks a lot for this info.

I have now verified that VLC 2.0.5 indeed works on Windows 10 (at least if 
I join the stream from a Linux box on the same subnet as the windows 
machine), and VLC 2.0.6 gives an immediate error when trying to open the 
same URL/stream.


I will send in this comment in the ticket.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Cost of IPv6 for IT operations team

2015-04-04 Thread Mikael Abrahamsson

On Fri, 3 Apr 2015, Ted Mittelstaedt wrote:

normal hardware refresh cycles is something the Fortune 1000 have. 
It's a nice concept but not one universally adopted by everyone else in 
the real world.  Another one of these is hardware service contracts 
That's not universally adopted, either.


Obviously, otherwise Win XP market share wouldn't be where it is 
considering MS has stopped supporting it.


The state of the SCADA and other industry applications is the result of 
a near total disregard for security when it comes to application 
programming. This will hopefully improve, but it'll take time, the same 
way IPv6 adoption will take time. However, it's still the truth that if 
you're buying equipment today that you intend to have around for 5-10 
years and you don't check them for IPv6 functionality, you're being 
short-sighted.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


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

2015-02-13 Thread Mikael Abrahamsson

On Fri, 13 Feb 2015, Richard Hartmann wrote:


On Fri, Feb 13, 2015 at 12:26 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:

so I guess clients need to try a few times and not listen to the (initial)
ICMP messages until the hole is open.


That sounds slightly broken as well.


I agree. Do you have a better suggestion?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


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

2015-02-13 Thread Mikael Abrahamsson

On Fri, 13 Feb 2015, Thomas Schäfer wrote:

and the practice in Germany to blocking all IPv6-inbound traffic the 
result is the problem for some gamers.


So I guess applications should use the same technique as one does to 
traverse NAT44:s, ie both ends of the connection send packets to each 
other to open their respective firewall.


I do agree that the firewall in question needs to not send rejects for 
this traffic for this to work. I am happy this use-case was brought up, 
because I hadn't heard and thought about this before. Personally I don't 
want to silently drop packets, so I guess clients need to try a few times 
and not listen to the (initial) ICMP messages until the hole is open.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

2015-02-13 Thread Mikael Abrahamsson

On Fri, 13 Feb 2015, Phil Mayers wrote:

None of this should be a problem for non-NATed IPv6. The absence of NAT 
will mean an ICMP error doesn't block a NAT translation - there's no 
such thing to block - so a CPE can send errors or not.


Ah, thanks for pointing that out.

So currently there are multiple providers disallowing incoming connections 
to IPv6 addresses for customers. But if I understand correctly, including 
what you described before, this would work:


U1=User1, U2=User2...
HGW1=HomeGateWay, belonging to U1.
Assume IPv6 and no NAT.

U1 and U2 are going to play a game together. They're speaking to the game 
server. U1 says please talk to me on U1IP UDP port U1PORT). U2 says 
please talk to me on U2IP UDP port U2PORT. Game server informs 
respective user about the other users' IP/PORT combination.


Now, U1 sends a UDP packet from U1IP,U1PORT to U2IP,U2PORT.
HGW1 creates flow state for U1IP,U1PORT-U2IP,U2PORT.
Packet reaches HGW2, which has no flow state, and is dropped. ICMP error 
message might be created.
In case of ICMP error message, U1 should ignore this.
U2 sends a packet from U2IP,U2PORT to U1IP,U1PORT.
HGW2 creates flow state.
Packet hits HGW1 which already has a flow state, and packet successfully 
reaches U1.
U1 now can start sending packets to U2 as well and they've worked around 
both of them having HGWs with stateful firewalls disallowing new 
connections to them.


Right?

The crucial step here seems to be the fact that initial packets might be 
dropped and error messages be generated, but these should be ignored by 
the application. Is this commonplace? Is it a problem at all?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


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

2015-02-12 Thread Mikael Abrahamsson

On Thu, 12 Feb 2015, Ole Troan wrote:

But that's better value by making IPv4 work less good. and I'll 
postulate that we can make A+P / shared IPv4 work good enough that 
end-users who are trained to live behind a NATs will not notice.


Problem with that is that this doesn't work with anything that doesn't 
have +P, so for instance my corporate VPN doesn't work because for some 
reason it uses GRE.


I think we're going to have to do some kind of A+P for protocols with 
port, and then do CGN (ds.lite) for everything else.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


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

2015-02-12 Thread Mikael Abrahamsson

On Thu, 12 Feb 2015, erik.tarald...@telenor.com wrote:


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.

xbox is no good example for *wanting* IPv6.


Could you elaborate on the IPv6 issues for xbox?  I was under the impresion 
that xbox works well with IPv6.


This thread probably:

http://lists.cluenet.de/pipermail/ipv6-ops/2014-March/009929.html

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-26 Thread Mikael Abrahamsson

On Sat, 24 Jan 2015, Andras Toth wrote:


Airport Express is setting the IPv6 Tunnel MTU to 1280 in all cases and
it's not configurable, as far as I'm aware.


That is what I have discovered. So the HE.net tunnel termination point 
will send PTB=1480 when sent 1500 byte packets, and my airport extreme 
will send PTB=1280.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-26 Thread Mikael Abrahamsson

On Mon, 26 Jan 2015, Ignatios Souvatzis wrote:

This is why setting the MTU (maximum _transmission_ unit) at your end 
doesn't necessarily help.  You'll have to lower your OS's notion of 
maximum TCP segment size negotiated for TCP reception.


That depends if the QUIC implementation in Chrome will understand path MTU 
and send smaller UDP packets than 1350 if needed. In my case it didn't.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-22 Thread Mikael Abrahamsson


I had another problem with Youtube just now, with Chrome+OSX. I saw my 
machine sending fragmented UDP-packets to google on 443, which it was not 
getting any responses to. On a hunch, I disabled QUIC in Chrome which made 
things start working again.


03:20:45.891286 IP6 2001:470:X  2a02:808:1:100::c: frag (0|1232) 59430  443: 
UDP, length 1350
03:20:45.891286 IP6 2001:470:X  2a02:808:1:100::c: frag (1232|126)

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-22 Thread Mikael Abrahamsson

On Fri, 23 Jan 2015, Lorenzo Colitti wrote:


Thanks for reporting this. What was the effect? Connections just getting
stuck? Was there fallback to IPv4?


I would get all the CSS, comments etc, the player would start to try to 
load the video stream, but there would be no video loaded at all (ie the 
progress bar never moved).



Personally I don't understand why everyone behind a manually-configured
tunnel doesn't set the MTU in the RA to the MTU of the tunnel... but that's
not an excuse for things not working.


I did that before, but I can't do it in my Airport Express. I have been 
considering changing my IPv6 tunneling to another device.


However, I have no clue why my OSX box thought it couldn't send 1350 byte 
sized UDP packets to the Internet. Could Google have sent me PTB=1280 from 
this host, so my OSX box thinks it can't send them unfragmented?


Anyone know how I can check in OSX for what destinations it has received 
PTB packets and what the PMTU it think it has for these destionations?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-22 Thread Mikael Abrahamsson

On Fri, 23 Jan 2015, Mikael Abrahamsson wrote:

Anyone know how I can check in OSX for what destinations it has received 
PTB packets and what the PMTU it think it has for these destionations?


Found it:

$ netstat -f inet6 -narlW
Internet6:
Destination Gateway Flags   
 Refs  UseMtuNetif Expire
default fe80::9272:40ff:fe07:cc74%en0   UGc 
   140   1500  en0
...

$ netstat -f inet6 -narlW | grep -v 1500 | grep en0
2620:109:c007:102::5be1:f881fe80::9272:40ff:fe07:cc74%en0   UGHWIi  
2  237   1280  en0
2a00:1450:4005:801::1017fe80::9272:40ff:fe07:cc74%en0   UGHWIi  
1  454   1280  en0
2a00:1450:400f:804::2000fe80::9272:40ff:fe07:cc74%en0   UGHWIi  
2   73   1280  en0
2a00:1450:400f:804::200efe80::9272:40ff:fe07:cc74%en0   UGHWIi  
2 1476   1280  en0
2a00:1450:400f:805::2003fe80::9272:40ff:fe07:cc74%en0   UGHWIi  
1   20   1280  en0
2a00:1450:4010:c07::bd  fe80::9272:40ff:fe07:cc74%en0   UGHWIi  
1  820   1280  en0

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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-22 Thread Mikael Abrahamsson

On Fri, 23 Jan 2015, Tore Anderson wrote:


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


I just took for granted that this would be the case because I've been told 
that google would be capping their communication at 1280. That's what I 
get for taking things for granted.



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?


08:10:06.394230 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240) 
2001:470:X:X::1  2001:470:28:35e:650d:12ec:4019:6a38: [icmp6 sum ok] ICMP6, 
packet too big, mtu 1280

You're correct. Wonder why I never noticed this before.

So I guess this explains why I sometimes saw SYN packets coming from my 
machine with MSS 1440 and sometimes with 1220, the 1440 was for 
destinations by which there was no PTB seen (yet), and 1220 for the ones 
where PTB had been seen.


Ok, thanks for helping clearing that up!

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-21 Thread Mikael Abrahamsson

On Wed, 21 Jan 2015, Ignatios Souvatzis wrote:


Hi,

On Tue, Jan 20, 2015 at 03:40:23PM +0100, Marco d'Itri wrote:

On Jan 20, Mikael Abrahamsson swm...@swm.pp.se wrote:


I turned off my IPv6 HE.net tunnel yesterday because family was complaining
about Youtube not working. I haven't enabled it again. Other people who had
problems, are things working again now?

Yes for me (2a00:1450:400c:c04::93).


For me (2001:638:403::), Google servers worked again yesterday,
but this was apparently implemented by our address ranges being
put onto Google's  blacklist.

Today it seems to work with  again.


I switched my HE tunnel back on again today and everything seems to work 
fine. As a data point, my fullsize packets from Youtube are IPv6 packets 
with length 1408 (as reported by tcpdump in OSX).


Flags [S.], seq 825239677, ack 2182453102, win 28160, options [mss 
1420,sackOK,TS val 1317228847 ecr 493983801,nop,wscale 7], length 0

The weird thing is that when I checked it again later, now both my machine 
and googles machine are saying MSS 1220 and I'm seeing packets that are 
1208. Some examples:


13:48:01.810082 IP6 2001:470:XXX.63869  2001:7f8:49:1::c.443: Flags [SEW], seq 
4278620568, win 65535, options [mss 1220,nop,wscale 5,nop,nop,TS val 494398939 ecr 
0,sackOK,eol], length 0
13:48:01.888071 IP6 2001:7f8:49:1::c.443  2001:470:.63869: Flags [S.], seq 
1292334177, ack 4278620569, win 28160, options [mss 1420,sackOK,TS val 1317649207 
ecr 494398939,nop,wscale 7], length 0

Then I get:

13:50:28.876356 IP6 2001:470:XX.63894  2001:7f8:49:1::c.443: Flags [SEW], seq 
2121307480, win 65535, options [mss 1220,nop,wscale 5,nop,nop,TS val 494544092 ecr 
0,sackOK,eol], length 0
13:50:28.970365 IP6 2001:7f8:49:1::c.443  2001:470:X.63894: Flags [S.], seq 
2118432000, ack 2121307481, win 28560, options [mss 1440,sackOK,TS val 1317796289 
ecr 494544092,nop,wscale 7], length 0

Notice the difference in MSS between those two machines that claim to have 
the same IPv6 address?


$ dig +short  r1.sn-gvopm-vu2e.c.youtube.com.
2001:7f8:49:1::c

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-20 Thread Mikael Abrahamsson

On Mon, 19 Jan 2015, Mikael Abrahamsson wrote:

But regardless, I had trouble this morning with Youtube that might be 
related to the same issue.


I turned off my IPv6 HE.net tunnel yesterday because family was 
complaining about Youtube not working. I haven't enabled it again. Other 
people who had problems, are things working again now?


It struck me that this should be possible to test on an host. Basically if 
the host can just respond to a packet with PTB, then checking if the size 
of the packets received changes or not would be interesting. Is anyone 
aware of someone implementing this already?


Basic functionality:

Would sniff traffic, send PTB packets for select sessions (configurable), 
and then I cold check using tcpdump or similar tool, if the packet sizes 
go down after the PTB has been sent.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: google path mtu?

2015-01-19 Thread Mikael Abrahamsson

On Mon, 19 Jan 2015, Ignatios Souvatzis wrote:

I had some problems at home, which is not tunneled, but a 
less-than-1500-octet-mtu PPPoE DSL line, so - thinking it's tunnels only 
ignores an increasing number of native private users.


Well, PPPoE is a tunnel, but I guess that's splitting hairs.

But regardless, I had trouble this morning with Youtube that might be 
related to the same issue.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: 6to4 in Internet aaaa records

2014-10-13 Thread Mikael Abrahamsson

On Mon, 13 Oct 2014, Nick Edwards wrote:


boxes, the box is dual stack, we just need 6yp4 to send ipv6 onto its
ipv4 address -  oh and before some bright spark says it, because we


From reading the above, 6to4 isn't what you think it is. 6to4 is a way to 

tunnel IPv6 on top of IPv4, it's not a translation mechanism.

It seems you want a load balancer that can take an IPv6 incoming TCP 
connection and talk to your IPv4 only news server... or you want to just 
add a TCP bouncer that'll listen to an IPv6 socket and connect this 
together with a new IPv4 socket call to ::1.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)

2014-09-23 Thread Mikael Abrahamsson

On Mon, 22 Sep 2014, Stig Venaas wrote:


Aren't the existing documents sufficient? See

RFC 4541
RFC 4605

and also this is related
draft-ietf-pim-explicit-tracking-10


RFC 4541 is only informational, not standards track. RFC4605 is standards 
track. The PIM draft is also standards track, but as far as I can see, 
there is no standards-track document for MLD/IGMP snooping.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)

2014-09-20 Thread Mikael Abrahamsson

On Wed, 17 Sep 2014, Enno Rey wrote:

it should be noted that RFC 4541 is an Informational one and I don't 
think any normative value for a kind-of vendor-proprietary thing called 
MLD snooping might be attached to it ;-)


I would like to see IGMP and MLD snooping properly standardized.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)

2014-09-17 Thread Mikael Abrahamsson

On Tue, 16 Sep 2014, Tom Hill wrote:

I'd be quite surprised if you find a switch that doesn't treat ff02::1 
in the same way as IPv4 broadcast, by default.


Saying that, I'd much prefer that IPv6 WoL had a known IPv6 multicast 
address, as opposed to using ff02::1.


This is actually quite interesting. I read RFC 4291:

All Nodes Addresses:FF01:0:0:0:0:0:0:1
  FF02:0:0:0:0:0:0:1

   The above multicast addresses identify the group of all IPv6 nodes,
   within scope 1 (interface-local) or 2 (link-local).

So, one interpretation would be that if the device hasn't subscribed to 
the all IPv6 nodes multicast group, it's not an IPv6 node, and shouldn't 
receive the traffic.


Also, regarding the above, in order to keep being subscribed to a WoL 
multicast address group, wouldn't the NIC have to keep emitting REGISTER 
messages periodically? Is this something NICs do today, emitting packets 
while the CPU is in fairly deep sleep?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Residential subscribers: numbered or unnumbered?

2014-03-26 Thread Mikael Abrahamsson

On Tue, 25 Mar 2014, Philip Matthews wrote:


What were your reasons for selecting this option?


I see a few up-sides.

You get clean /56 handoff to customer, and you don't need to have any of 
the customer GUA addresses on the ISP router, meaning control plane 
protection is easier. You also lessen amount of table entries you need for 
uRPF.


Downside:

People actually need CPE, they can't connect a computer directly (at least 
not without turning on Internet Connection Sharing or alike).


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: interesting multicast packet

2014-02-25 Thread Mikael Abrahamsson

On Tue, 25 Feb 2014, Gert Doering wrote:


 ff08::2.8083  (UDP, payload length 21)

But that's not what I'm wondering about - I'm more curious about that
sort of packet - what is that?  What is it used for?  Which process is
emitting it, and what is it trying to achieve?


http://www.adminsub.net/tcp-udp-port-finder/8083

Port: 8083/UDP8083/UDP - Known port assignments (3 records found)
ServiceDetailsSourceus-srvUtilistor (Server)IANA EMC2 (Legato) 
Networker or Sun Solcitice Backup (Official)WIKI

QuickTime Streaming ServerApple

Does the windows machine run legato networker och similar backup service?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Bonjour / Apple / Service discovery

2014-02-04 Thread Mikael Abrahamsson


Hello.

I have an apple 802.11ac latest gen timecapsule+airport express. It's 
currently sitting with its WAN port connected to a GUA IPv4 and IPv6 
subnet. On that GUA subnet is an AppleTV3. The Apple Airport has an IPv6 
subnet delegated to it using DHCPv6-PD, and does IPv4 NAT. On the wifi 
behind these NAT+PD are Apple iPads, all running latest software available 
from Apple.


I want to be able to do AirPlay frmo the iPads to the Apple TV, but 
service discovery fails in this case and the units behind the NAT doesn't 
detect the AppleTV service announcements.


So, this is a typical scenario that Homenet tries to solve with its hybrid 
DNS-SD proxy etc


http://www.dns-sd.org/
http://www.ietf.org/proceedings/87/slides/slides-87-homenet-2.pdf
http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02

However, above probably isn't in any shipping code currently.

I have seen examples out there where they put a linux box with avahi 
deamon connected to both subnets and use as a dnssd proxy. I don't want to 
do that. There doesn't seem to be any service discovery related 
configuration on the AirPort using the AirPort utility.


Is there anything else I can do? I control the dns resolver that all 
devices use. I don't want to manually create entries, I would like this to 
be dynamic. If I at the same time could get devices to register their GUA 
IPv6 address at the same time (like dyndns) that would be an added bonus.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


RE: MTU handling in 6RD deployments

2014-01-17 Thread Mikael Abrahamsson

On Fri, 17 Jan 2014, Templin, Fred L wrote:


So, if we were to construct the pings from the IPv6 level we would
want to use link-local source and destination addresses.


No. What you want to do is ping your own 6RD address and see if you get 
the packet back. Link locals does not work in 6RD in that way.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


RE: MTU handling in 6RD deployments

2014-01-17 Thread Mikael Abrahamsson

On Fri, 17 Jan 2014, Mikael Abrahamsson wrote:


On Fri, 17 Jan 2014, Templin, Fred L wrote:

Sorry, I was looking at the wrong section. I see now that Section 8 is 
talking about a method for a CE to send an ordinary data packet that loops 
back via the BR. That method is fine, but it is no more immune to someone 
abusing the mechanism than would be sending a ping (or some other NUD 
message). By using a ping, the BR can impose rate-limiting on its ping 
responses whereas with a looped-back data packet the BR really can't do 
rate limiting.


You don't ping the BR, you ping yourself via the BR. The BR only forwards the 
packet.


My bad, I didn't read your text properly. Why would the BR want to 
rate-limit data plane traffic?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


RE: MTU handling in 6RD deployments

2014-01-17 Thread Mikael Abrahamsson

On Fri, 17 Jan 2014, Templin, Fred L wrote:

Sorry, I was looking at the wrong section. I see now that Section 8 is 
talking about a method for a CE to send an ordinary data packet that 
loops back via the BR. That method is fine, but it is no more immune to 
someone abusing the mechanism than would be sending a ping (or some 
other NUD message). By using a ping, the BR can impose rate-limiting on 
its ping responses whereas with a looped-back data packet the BR really 
can't do rate limiting.


You don't ping the BR, you ping yourself via the BR. The BR only forwards 
the packet.



Also, Section 8 of RFC5969 only talks about the CE testing the forward
path to the BR. Unless the BR also tests the reverse path to the CE it
has no way of knowing whether the CE can accept large packets.


You misread the text.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


RE: MTU handling in 6RD deployments

2014-01-17 Thread Mikael Abrahamsson

On Fri, 17 Jan 2014, Templin, Fred L wrote:

But, if the BR doesn't examine the packet it could get caught up in a 
flood-ping initiated by a malicious CE.


The BR should have enough dataplane forwarding capacity to handle this.

I am considering a specific ping rather than an ordinary data packet as 
a way for the BR to know whether the CE is testing the MTU vs whether it 
is just looping back packets. If the BR knows the CE is testing the MTU, 
it can send ping replies subject to rate limiting so a malicious CE 
can't swamp the BR with excessive pings.


Why does it need to know? The CE is pinging itself CE-BR-CE, and if the 
CE doesn't receive the packet back then the MTU is obviously limited.


So the CE sends out a packet towards the BR, with the IPv6 address being 
the CE itself. So the packet arrives at the BR, gets decapsulated, does 
IPv6 dst address lookup, gets encapsulated, and then sent onto the CE. 
Pure data plane.


I don't get why the BR should need to get involved in anything more 
complicated than that?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


RE: MTU handling in 6RD deployments

2014-01-09 Thread Mikael Abrahamsson

On Thu, 9 Jan 2014, Templin, Fred L wrote:

I don't doubt that your experience is valid for the environment you are 
working in. What I am saying is that there may be many environments 
where setting IPv4 link MTUs to 1520+ is a viable alternative and then 
the hosts can see a full 1500+ MTU w/o ICMPs. SEAL detects when such 
favorable conditions exist and uses limited fragmentation/reassembly 
only when they don't. Or, if fragmentation/reassembly is deemed 
unacceptable for the environment, then clamp the MSS.


6RD relays can be made cheap because they are stateless. 6RD 
implementation in hosts can be bade cheap, because it's easy. SEAL isn't 
stateless (obviously, since it can do re-assembly), thus increasing cost 
and complexity both in host and relay.


So while it might have a technical fit, it isn't really an operational or 
monetary fit right this minute. 6RD is widely implemented today, by the 
time any other mechanism is implemented, the use-case for IPv6 tunneled in 
IPv4 might be much less interesting, hopefully more are moving towards 
IPv4 over native IPv6 for new implementations.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: MTU handling in 6RD deployments

2014-01-07 Thread Mikael Abrahamsson

On Tue, 7 Jan 2014, Mark Townsley wrote:

Note I've heard some ISPs consider running Jumbo Frames under the covers 
so that IPv4 could carry 1520 and 1500 would be possible for IPv6, but 
have not yet seen that confirmed to me in practice.


Unless this is done in a very controlled environment I'd say this is 
bordering on the impossible. There are so many failure points for a jumbo 
solution it's scary. Most of them is also silent failure of PMTUD, 
basically blackholing of traffic.


Yes, it can be done of course, but I'd say operationally it's easier to 
just drop the MTU to 1480 and known working, than the jumbo alternative.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: RA DHCP problem...

2013-12-30 Thread Mikael Abrahamsson

On Sun, 29 Dec 2013, Nick Hilliard wrote:

large.  Either small numbers of very large l2 domains or else large 
numbers of l2 domains with lots of hosts.  In either case, the use case 
is tens of thousands of ipv6 hosts.


Why would one want to build huge L2 domains? It's a lot of pain, and there 
is no address limitation that means you must do this.


What's the use-case that requires large L2 domains as the best solution? 
And on top of that, that requires different hosts within this L2 domain to 
have different default gateways?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: RA DHCP problem...

2013-12-30 Thread Mikael Abrahamsson

On Mon, 30 Dec 2013, Roger Jørgensen wrote:

What is wrong with having something else than our _current_ RAs to 
provide defaultgateway on a network if the operator wish so? Let that be 
DHCPv6 or dibbler?


Because the current method is known to work and you haven't given 
convincing arguments why it doesn't or why doing what you want is superior 
enough to warrant having two (or more) ways to do this?


When I first looked into IPv6 I was of your opinion, why not do it the 
same way it's done in IPv4. Then I got over it. Operationally, I don't see 
having default gateway in DHCPv6 as something that makes much sense, apart 
from the fact that it means people have to learn less to start using IPv6, 
which I don't consider a valid use-case.


For me, RA/RS/ND is all one single thing, you can't make IPv6 function 
without ND, so there is little reason to try to avoid the RA/RS machinery.


A more valid use-case would be if you were propagating for new 
functionality and said that this would be easier to implement in DHCPv6 
than in ND, and then you would get default-gw for free. That is the path I 
would choose. Unfortunately, the use-case that comes to mind (having 
routers that shouldn't have ::/0 pointed to them) is already implemented 
in by means of RIO in RAs. There is just very little deployed support for 
it as far as I know.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

i...@prizmaphoto.com

2013-12-30 Thread Mikael Abrahamsson


Every time I post to the list I get an email back from 
i...@prizmaphoto.com. Could someone please check if that address is 
subscribed to this list, and in that case, remove it?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: RA DHCP problem...

2013-12-28 Thread Mikael Abrahamsson

On Sat, 28 Dec 2013, Roger Jørgensen wrote:

supply default gateway independing of RAs or no RAs. That is a client 
should be able to get only in a IPv6 only network _if_ there is no RAs, 
only DHCP there.


Why? What problem are you solving by changing the current behavior?

DHCP must support defaultroute and must be decoupled from RAs, no M-bit 
or whatever.


M-bit is a hint, nothing in the standard says a host isn't allowed to use 
DHCP on a network.


(tons of options on how DHCP and RAs can live together, all with their 
own pitfalls. From the simple one that dhcpclient can disable the kernel 
from accepting RAs with it's own pitfalls, to let the kernel sorting 
them out, and over to preferring either one - RAs or DHCPs defaultroute)


Personally I think it's a huge mistake for an implementor to have the 
kernel process RAs, all this control plane should be done in userspace, 
not in the kernel.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: RA DHCP problem...

2013-12-28 Thread Mikael Abrahamsson

On Sat, 28 Dec 2013, Roger Jørgensen wrote:


did you see the start of my mail?


Yes.


It should be possible to have a network running DHCP without any RA, if
someone wants to do that.


Why?

Because I want to isn't a good technical answer.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: IPv6 broken on Fedora 20?

2013-12-19 Thread Mikael Abrahamsson

On Fri, 20 Dec 2013, Lorenzo Colitti wrote:

Sigh. Why do we keep reinventing the wheel? What was wrong with the 
in-kernel RA implementation?


If you want to support other ND/RA functionality than the kernel supports, 
this is a good idea. Personally I think having ND processing built into 
the kernel is a mistake.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


question regarding Sweden IPv6 rollout

2013-12-18 Thread Mikael Abrahamsson


http://www.vyncke.org/ipv6status/project.php?metric=pcountry=se

The above indicates that Sweden went from 0.2% to 0.6% in two weeks. I 
don't know what this operator that did this is, and I'm extremely curious.


How can I find out?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: question regarding Sweden IPv6 rollout

2013-12-18 Thread Mikael Abrahamsson

On Wed, 18 Dec 2013, Lorenzo Colitti wrote:


On Wed, Dec 18, 2013 at 9:59 PM, Mikael Abrahamsson swm...@swm.pp.sewrote:



http://www.vyncke.org/ipv6status/project.php?metric=pcountry=se

The above indicates that Sweden went from 0.2% to 0.6% in two weeks. I
don't know what this operator that did this is, and I'm extremely curious.


From what I can see, it's not an ISP.


Now I am even more intrigued!

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: What is Brocade up to here?

2013-10-28 Thread Mikael Abrahamsson

On Sun, 27 Oct 2013, niels=clue...@bakker.net wrote:

It's been broken for months, too.  Happy Eyeballs seems to work pretty 
well for the internet.


Did they just fix it?

$ telnet -6 brocade.com 80
Trying 2620:100:4:6401::20...
Connected to brocade.com.
Escape character is '^]'.
quit
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title301 Moved Permanently/title
/headbody
h1Moved Permanently/h1
pThe document has moved a 
href=http://www.brocade.com/index.page;here/a./p

hr
addressIBM_HTTP_Server at internet.brocade.com Port 80/address
/body/html
Connection closed by foreign host.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: ipv6 source address selection

2013-10-20 Thread Mikael Abrahamsson

On Sun, 20 Oct 2013, Ole Troan wrote:


wouldn't this be RFC6724:

Rule 8: Use longest matching prefix.
  If CommonPrefixLen(SA, D)  CommonPrefixLen(SB, D), then prefer SA.
  Similarly, if CommonPrefixLen(SB, D)  CommonPrefixLen(SA, D), then
  prefer SB.


The host has a bunch of /64s. I am pinging stuff outside of these /64:s. I 
am however pinging stuff in adjacent /64:s within the same /56 (or /48), 
but the host tables I can find has no information about /56 or /48s.


$ ip addrlabel list
prefix ::1/128 label 0
prefix ::/96 label 3
prefix :::0.0.0.0/96 label 4
prefix 2001::/32 label 6
prefix 2001:10::/28 label 7
prefix 2002::/16 label 2
prefix fc00::/7 label 5
prefix ::/0 label 1

I don't understand why the host would choose source address in 
2001:db8:1:1000:/64 when pinging 2001:db8:1:1001:1/128 because of this, 
but use 2001:db8:1:8000::/64 when pinging the rest of the Internet (well, 
actually my hosts are in 2a00::/16 really, but never mind, should be the 
same).


What am I missing?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


ipv6 source address selection

2013-10-19 Thread Mikael Abrahamsson


I'm trying to influence my source address selection. First I thought I'd 
figure out how it works by default.


I have a /48. Let's call it 2001:db8:1::/48

I created three /64s on the same LAN with A-bit set so clients would do 
SLAAC within these:


2001:db8:1::/64
2001:db8:1:1000:/64
2001:db8:1:2000:/64

Then I set up loopback addresses on my router:

2001:db8:1:0001:1/128
2001:db8:1:1001:1/128
2001:db8:1:2001:1/128

Then I tried pinging each loopback address from a host which has 2 
addresses out of each /64. It now picked a source address within the same 
/56. I consistently both on a Ubuntu 13.04 and OSX 10.8.5 machine get the 
same behaviour.


So above means that pinging 2001:db8:1:1fff::1 it would use the :1000: 
address, and pinging :2fff::1 would use the :2000::/64 address.


If I ping outside my /48 it will consistently use the last created address 
(I tried adding a 4th lan, 8000, and it then uses that one), which I 
perfectly understand.


When I ping :5000: and so on, it will sometimes use the :: address and 
not the :8000: that is used for the rest of global traffic.


I have nothing /56 or /48 magic in routing table or ip addrlabel list, 
but it still seems to be something special when it comes to the same /48 
as the machine has addresses in.


Any help understanding what is going on is appreciated.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: interesting about OSX, NAT64 prefix discovery

2013-10-15 Thread Mikael Abrahamsson

On Tue, 15 Oct 2013, Mikael Abrahamsson wrote:


On Mon, 14 Oct 2013, Michael Loftis wrote:


or dscacheutil -flushcache


dhcp-28-70:Downloads mikaelabrahamsson$ dscacheutil -flushcache
dhcp-28-70:Downloads mikaelabrahamsson$ ping6 swm.pp.se
PING6(56=40+8+8 bytes) 2001:67c:64:47:ec62:fe83:affa:f283 -- 
2001:db8:624::d4f7:c88f

16 bytes from 2001:db8:624::d4f7:c88f, icmp_seq=0 hlim=49 time=83.997 ms
^C
--- uplift.swm.pp.se ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 83.997/83.997/83.997/0.000 ms

dhcp-28-70:Downloads mikaelabrahamsson$ grep swm.pp.se /etc/hosts
212.247.200.143uplift.swm.pp.se uplift swm.pp.se webmail.swm.pp.se

No DNS queries were done for swm.pp.se during this above interaction, as 
verified by tcpdump on en0.


Tore helped me figure it out.

It seems with that entry in the host field, if I ssh to swm.pp.se, it'll 
actually ssh to uplift.swm.pp.se (first entry on the line), which doesnt 
have a  record, so it'll be uplift.swm.pp.se IPv4 address DNS64 mapped 
to the NAT64 prefix.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


interesting about OSX, NAT64 prefix discovery

2013-10-14 Thread Mikael Abrahamsson


Macbook running 10.8.5 with latest updates.

I am at the RIPE67 meeting, on their IPv6 only wifi. This has NAT64+DNS64 
support.


I had an entry in my /etc/hosts with an IPv4 address only, and was SSHing 
to it. By some internal magic, OSX had discovered the NAT64 prefix and was 
using it by itself to connect to this ipv4 only host.


This caused great confiusion before I could figure out what was going on 
(didn't remember I had this hostname there), because when I was ssh:ing, 
it would first try the IPv4 address (using IPv4 LL, ie arp:ing directly on 
the link), and then it would try the IPv4 address mapped to the NAT64 
prefix, which I couldn't understand where it came from.


Well, I don't *know* this is what was happening, but I see no other 
mechanism that would explain the behaviour I was seeing. Anyone else seen 
this or know more?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: interesting about OSX, NAT64 prefix discovery

2013-10-14 Thread Mikael Abrahamsson

On Mon, 14 Oct 2013, Gert Doering wrote:


Hi,

On Mon, Oct 14, 2013 at 08:30:05AM +0200, Mikael Abrahamsson wrote:

Well, I don't *know* this is what was happening, but I see no other
mechanism that would explain the behaviour I was seeing. Anyone else seen
this or know more?


My guess would be more like resolver queries for IPv4 and IPv6.  IPv4 is
serviced from /etc/hosts, while IPv6 is serviced from DNS = DNS64.


Nope, there were no DNS queries on the wire for this host at all.

SSH would try to connect to the IPv4 address, fail, then would connect to 
the NAT64 prefixed IPv4 address. So I'd say that when there was an entry 
in /etc/hosts, no DNS queries were done at all for this name.



An IPv4-only entry in /etc/hosts will not result in IPv6 resolver lookups
will return NXDOMAIN.


This magic only seems to kick in when there is no real IPv4 connectivity 
at all. I encourage others to verify what I saw!


--
Mikael Abrahamssonemail: swm...@swm.pp.se


IPv6 only + NAT64 experience on iOS 7.0.2

2013-10-14 Thread Mikael Abrahamsson


Basic stuff works (web surfing for instance, I get 7/10 for IPv4 and 10/10 
for IPv6 on testipv4.com, but so far installing apps via App store just 
fails silently.


So I guess iOS 7 still doesn't have 464XLAT unfortunately.

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: interesting about OSX, NAT64 prefix discovery

2013-10-14 Thread Mikael Abrahamsson

On Mon, 14 Oct 2013, Simon Perreault wrote:


Did they implement the NAT64 prefix discovery heuristic? That would be
great!


Well, I dont know, but this is what happens: THis is without entry in 
/etc/hosts:


dhcp-28-70:~ mikaelabrahamsson$ ping6 swm.pp.se
PING6(56=40+8+8 bytes) 2001:67c:64:47:b501:73ad:3c6:867c -- 2a00:801::f
16 bytes from 2a00:801::f, icmp_seq=0 hlim=49 time=78.654 ms
16 bytes from 2a00:801::f, icmp_seq=1 hlim=49 time=81.850 ms
^C
--- swm.pp.se ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 78.654/80.252/81.850/1.598 ms

dhcp-28-70:~ mikaelabrahamsson$ host swm.pp.se
swm.pp.se has address 212.247.200.143
swm.pp.se has IPv6 address 2a00:801::f

Then I put

212.247.200.143uplift.swm.pp.se uplift swm.pp.se webmail.swm.pp.se

in /etc/hosts and I get:

hcp-28-70:~ mikaelabrahamsson$ ssh swm...@swm.pp.se -v
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to swm.pp.se [212.247.200.143] port 22.
debug1: connect to address 212.247.200.143 port 22: No route to host
debug1: Connecting to swm.pp.se [2001:db8:624::d4f7:c88f] port 22.
debug1: Connection established.
debug1: identity file /Users/mikaelabrahamsson/.ssh/id_rsa type 1

It's a bit strange, Chrome won't connect either, telnet doesn't work, but 
Safari does work, Firefox connects but it takes a very long time 
(minutes). So perhaps ssh and Safari/Firefox uses a different API call 
than the others?


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: interesting about OSX, NAT64 prefix discovery

2013-10-14 Thread Mikael Abrahamsson

On Mon, 14 Oct 2013, Rui Paulo wrote:

Are you sure no DNS queries were sent ? It might be cached by 
mDNSResponder. You can reset the cache with sudo killall -HUP 
mDNSResponder.


Well, tcpdump said no queries were sent. I will try the advice about 
emptying the dns cache and see if it persists.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


RE: Microsoft: Give Xbox One users IPv6 connectivity

2013-10-10 Thread Mikael Abrahamsson

On Thu, 10 Oct 2013, Christopher Palmer wrote:

The thing about protocols like UPnP - the vendors who would ignore an 
IETF recommendation are likely to be the same vendors to skip out on 
making an adequate UPnP stack. Most people today do NOT have home 
routers that support UPnP.


Do you have numbers on this? My belief has been that most people today who 
care about anything more than web surfing would have a decently new 
gateway (less than 3-5 years old) and that this would support UPnP.


I don't have any numbers so I would like to know more :)

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: PTR records for IPv6

2013-09-03 Thread Mikael Abrahamsson

On Mon, 2 Sep 2013, Mohacsi Janos wrote:

Yes, but we must not forget temporary addresses. If the MTA has temporary 
addresses, then it will prefer them for its smtp sessions. So, one should 
either disable temporaries on all MTAs or use DNS dynamic updates. I think 
that it would be much wiser to deprecate PTR checks for IPv6.


Why would you use temporary address on a defined SMTP server?


Mostly because it's on by default. Even if you configure a static address 
and default gw, as soon as the system sees RAs it might start to use SLAAC 
based privacy addresses for outgoing connections. I've already seen this 
happen once, which caused problems sending mail to google.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Linux IPv6 routing strange behaviour

2013-08-15 Thread Mikael Abrahamsson

On Thu, 15 Aug 2013, Jeroen Massar wrote:

Yes, that is 5 /40s worth of address space and everything is piped into 
the sixxs interface to a single neighbor that lives on the tapped 
interface. We thus indeed hit the Linux routing logic a bit, but as the 
table is small and it is a single neighbor nothing much dynamic happens 
there. ip -6 monitor route is thus nice an silent.


So you're actually not seeing any flow based routing here?

cat /proc/net/ipv6_route contains just those routes you see in ip -6 r 
show?


Because in my linux kernel 3.2 based machines I have a lot more entries in 
cat /proc/net/ipv6_route than I have routes.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Linux IPv6 routing strange behaviour

2013-08-14 Thread Mikael Abrahamsson

On Wed, 14 Aug 2013, Max Tulyev wrote:


What is the soultion? There are *MILLIONS* of flows in the backbone...


The solution is not to use a flow routing platform in the core. This 
lesson was learnt at the end of the 90ties.


So until the linux ipv6 forwarding code is fixed to do stateless 
forwarding, it's just not suited for your application.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: Sunsetting Teredo Experiment [IETF slides]

2013-08-04 Thread Mikael Abrahamsson

On Sun, 4 Aug 2013, Sander Steffann wrote:


Well, I am on that list, so the barrier is not *that* high ;-) Sander


I sent in a subscription request after I saw this discussion and after a 
few hours, I am also subscribed.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


RE: teredo.ipv6.microsoft.com off?

2013-07-16 Thread Mikael Abrahamsson

On Tue, 16 Jul 2013, Christopher Palmer wrote:

If there is feedback on the ongoing experiment or our consideration of 
sunsetting Teredo, do let me know.


So far people have been quite enthusiastic.


I am too. I would really like to see 6to4 and teredo be default off 
everywhere, and people who want it can manually turn it on. If teredo went 
away completely, that would also be a good thing.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: same link-local address on multiple interface and OSPFv3

2013-06-28 Thread Mikael Abrahamsson

On Fri, 28 Jun 2013, Matjaž Straus Istenič wrote:

Workaround is rather simple: use different link-local addresses on 
IPv6-enabled interfaces and you are safe. But, nevertheless, I think 
using same link-local pairs on links should not get you into any 
trouble, right?


Correct, the same way that configuring fe80::1 on one interface and 
fe80::2 on a second interface, and on this second interface the other end 
should be able to have fe80::1 as its address, and everything should work 
fine. Everything else is buggy, as you already have concluded.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

RE: New IPv6 king of the hill: Switzerland?

2013-06-14 Thread Mikael Abrahamsson

On Wed, 22 May 2013, Eric Vyncke (evyncke) wrote:

So, back to normal and Switzerland now 'ruling' the IPv6 world with 
9.47% vs. Romania which is now number 2 with 8.63% (and I do not talk 
here about the eurovision song contest of course ;-))


http://www.vyncke.org/ipv6status/compare.php?metric=pcountries=ch,us,de,fr,ro,se 
still showing CH in the lead.


Do we have any insights from within Swisscom? Have they seen any problems 
reported to their customer service? Sharing of experience would be really 
helpful in trying to convince other organisations that enabling dual stack 
for end users is safe and is not going to cause a storm of complaints to 
customer service.


--
Mikael Abrahamssonemail: swm...@swm.pp.se


enterprise IPv6 only client computers and IPv4 connectivity

2013-04-30 Thread Mikael Abrahamsson


Hi,

If an enterprise today would decide that they're going to run IPv6 only on 
their LAN, they would have recent Win7|Win8|OSX|Ubuntu clients on their 
client computers, what mechanism would they use to access IPv4 Internet?


My thinking immediately went to DS-lite, NAT64/DNS64 and MAP-E, but I 
NAT64/DNS64 isn't good enough without 464XLAT, and DS-lite and MAP-E 
requires additional software on most of these operating systems, right? 
Are these kinds of client software even available?


What other mechanism could be used to achieve IPv4 Internet reachability 
over IPv6 only access for end-systems? HTTP proxy or SOCKS-proxy also 
sounds too cumbersome.


--
Mikael Abrahamssonemail: swm...@swm.pp.se