Re: MTU/MSS testing IPv6

[Ignatios Souvatzis]

On Fri, Apr 29, 2016 at 08:30:50AM +0200, Mikael Abrahamsson wrote:
> 
> 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.

Yes please.  Guess what I'm trying to debug right know, and having a 
reliable testing point out there would be an immense help.

-is

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

[Ignatios Souvatzis]

On Tue, Sep 16, 2014 at 08:16:06PM +0100, Tom Hill wrote:
> On 16/09/14 13:34, Bj?rn Mork wrote:
> > This depends on all-stations multicast being forwarded to inactive
> > ports. If it works with your switches, then fine.  But I don't think you
> > can assume it works everywhere.
> 
> 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.

But... that would mean you'd have to configure that. WoL wants to work
with minimal hardware action - it only checks for any  followed
by a couple of times its mac address anywhere in a packet, right?

-is

Re: test-ipv6.com out of service?

[Ignatios Souvatzis]

Hm:

On Thu, Nov 12, 2015 at 01:16:51PM +0100, Thomas Schäfer wrote:
> 
> is the this site down?
> 
> http://test-ipv6.com/
> 
> Some minutes ago it displayed wrong test results. Now it seems to me it is
> down.

TOMEETOO

on a related note: it doesn't have any IPv6 resolution anymore:

theory.cs.uni-bonn.de 5% host -t  test-ipv6.com
test-ipv6.com has no  record

-is

Re: IPv6-misconfigurations

[Ignatios Souvatzis]

On Mon, Sep 28, 2015 at 07:17:41AM -0700, Ca By wrote:
> On Mon, Sep 28, 2015 at 6:57 AM, Thomas Schäfer 
> wrote:
> 

> Generally speaking, it is better to have no IPv6 access than broken IPv6.
> 

Famous old words.[2]

-is

[2] 
http://www.guug.de/veranstaltungen/ecai6-2007/slides/ecai6-2007_Souvatzis_ER_7yr_IPv6.pdf,
 p.28

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

[Ignatios Souvatzis]

Hi,

On Thu, Jun 11, 2015 at 09:56:45AM +, Benedikt Stockebrand wrote:

 As far as tweaking these values to deal with some sleepy devices is
 concerned: I'd personally prefer to consider these devices broken; they
 should at least send an RS when they wake up and ensure their
 configuration is still up to date.

What I thought exactly.

-is

Re: Google no longer returning AAAA records?

[Ignatios Souvatzis]

Hi,

On Thu, Apr 16, 2015 at 10:56:38PM -0700, Doug Barton wrote:
 On 4/16/15 10:22 PM, Frank Habicht wrote:
 Hi,
 
 On 4/17/2015 6:45 AM, Erik Kline wrote:
 On Fri, Apr 17, 2015 at 12:28 PM, Brian E Carpenter
 But the incentive is wrong. Forcing users to drop back to IPv4 offers
 no incentive to fix the IPv6 problem. The correct incentive would be to
 tell an operator that they will be blacklisted unless they fix {X and Y}.
 
 We almost never know what X or Y are.  We only detect that there
 appears to be a problem.
 
 maybe just a short email to the whois contacts (some really read them)
 we have noticed something wrong with your IPv6, we're now not giving
  to these resolvers: x.x.x.x/y and maybe a link to a test site...
 
 without that you're lowering chances of it being fixed. with that email
 you increase them.
 
 They also increase chances of the operator trying drag Google into an IPv6
 helpdesk role.
 
 I don't like Google's policy on this, and I'm not sure it's what I would do,
 but I see their point.

Well, as far as I (as an outsider) can detect: Google does whatever
can be formulated as algorithms or heuristics and given to their
machines, and nothing else (or at least they don't admit it unless
forced in court).

Google's business model wouldn't scale to their number of peers* if
they had individual human support.

Their  serving policy is consistent with this rule. If they
would handle it through auto-generated e-mails, they'd land on some
blacklist sooner or later; if they'd try to phone the responsibles,
that'd consume too much manpower. 

Not much that anybody can do about that. So if you're a knowledgable
peer detects no , searching for IPv6 problems on your side
or your connectivity provider's is what you should do; and if you
don't, you'll get connectivity by v4.

I suspect Google will change their rule to be protocol independent
in the future... if v6 is better than v4 for you, they won't give
out A records to your resolver ;-)

-is

*) most don't pay them, so they're not customers.

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

[Ignatios Souvatzis]

On Thu, Feb 12, 2015 at 10:00:21AM +0100, Ole Troan wrote:
  So, any thoughts on this topic, and any qualified guesses on when we no 
  longer need to do IPv4 and still be able to call our internet product 
  premium?
 
 When will IPv6 provide me as an end-user with more value than what my 
 current NATed IPv4 connection does?

Since December of 2008.  You can't reach
uggc://cubgb.orireyl.xyrvaohf.bet/argybt
through IPv4.

-is

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

[Ignatios Souvatzis]

On Thu, Feb 12, 2015 at 10:41:05AM +0100, 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.

You mean, trained to see their downloads/web page updates break all
the time, like when they're in the mid of a tourist region during
vacation time? Hotel's WLAN's NAT tables clog, mobile phone provider's
NAT tables overflow. A lose-lose situation.

IPv4 will deteriorate more and more over the years. We have know this
for a quarter century now, and there is no way back. 

-is

Re: Cloudflare IPv6 folks

[Ignatios Souvatzis]

On Mon, Jan 12, 2015 at 04:46:03PM -0500, Paul Timmins wrote:
 I'm having problems that are getting debugged uselessly that seem to tie to
 IPv6. Can someone hit ticket 301481 and hit me back offlist?

In case this is of interest: I've reported to n...@cloudflare.com that
they have a PMTUd hole, at least towards AS680. Well - at least towards
2001:638:403::/48, to be precise.

-is

Re: google path mtu?

[Ignatios Souvatzis]

Hi,

On Fri, Jan 23, 2015 at 07:32:47AM +0100, Tore Anderson wrote:
 * Mikael Abrahamsson swm...@swm.pp.se
 
  So I guess the problem this time was some Google servers sending me 
  PTB=1280 and then Chrome not taking this into account when sending
  UDP packets when using QUIC, resulting in fragmented IPv6 packets
  (which works very badly in real life), and then not handling this
  situation by doing fall-back to something else.
 
 I highly doubt that Google would be sending you PTBs. 10 SEK says it's
 your tunnel ingress router (i.e., your Airport Express)...

Wrong direction for getting video from Google, isn't it? That is,
the other end of the tunnel would have to send PTB's successfully
to Google to make Google send you smaller _data segments_.

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.

And you can't do anyhing at all for incoming UDP-transported
data streams on the receiving side (unless the higher protocol
has some way to do it).

-is

Re: google path mtu?

[Ignatios Souvatzis]

Hi,

On Mon, Jan 26, 2015 at 10:47:51AM +0100, Mikael Abrahamsson wrote:
 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

to the outside...

 when sent 1500 byte packets, and my airport extreme will send PTB=1280.

to the inside only, or even to the outside for incoming packets?

-is

Re: google path mtu?

[Ignatios Souvatzis]

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.

Regards,
-is

Re: google path mtu?

[Ignatios Souvatzis]

On Mon, Jan 19, 2015 at 10:13:25AM +, Alec Edworthy wrote:
 
 
 On 19/01/2015 10:06, Ignatios Souvatzis wrote:
  Hi,
  
  there seems to be something that smells of a path mtu problem
  reaching google servers from here[1]... (first-hop of the University's 
  external link is a short tunnel). Workaround is blocking google v6 using
  the 4or6 addon.
  
  Has anybody else seen this?
 
 Related https://twitter.com/Prolixium/status/557018191919337474 ?

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.

-is

Re: Clueless national monopoly providers

[Ignatios Souvatzis]

On Fri, Oct 10, 2014 at 03:08:43PM +0100, Tim Chown wrote:
 On 10 Oct 2014, at 15:01, Phil Mayers p.may...@imperial.ac.uk wrote:
 
  On 10/10/14 14:50, Bjoern A. Zeeb wrote:
  
  % telnet -4 www.bt.com 80
  Trying 62.239.186.73...
  Connected to www.bt.com.
  Escape character is '^]'.
  GET /
  Connection closed by foreign host.
  
  
  Whatever load balancer that is, it needs an upgrade and understand g?ol 
  HTTP 0.9 as well in addition to IPv6 ;-)
  
  In fairness, I've run into a lot of actual, real-life webserver code 
  (usually Java Servlet based cough Oracle cough) that requires, at minimum, 
  a Host: and Accept: header. Annoying, but I guess...
  
  However as another person points out, this fails with real, browser, HTTP 
  requests. The nc was just a convenient way of showing it ;o)
 
 Indeed, from a v6 capable browser on a v6 network, I get /sadface This web 
 page is not available.

Here, The connection to the server was reset while the page was loading.
(AS680)

-is

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

[Ignatios Souvatzis]

Hi,

On Sun, Sep 21, 2014 at 08:01:49PM +0100, Tom Hill wrote:
 On 17/09/14 11:07, Ignatios Souvatzis wrote:
 In IPv6, the data forwarding rules are more straight forward because
 MLD is mandated for addresses with scope 2 (link-scope) or greater.
 The only exception is the address FF02::1 which is the all hosts
 link-scope address for which MLD messages are never sent.  Packets
 with the all hosts link-scope address should be forwarded on all
 ports.
 
 Forgive me if I'm missing some crucial element here, but wouldn't it be
 possible to:
 
 (1) assign new multicast address for v6 WoL (and not use ff02::1)
 (2) require that traffic for this address is forwarded /like/ ff02::1

Ah - but this would not work on existing switches that do MLD.
That's the same reason IPv4 WoL is typically addressed to
255.255.255.255 or subnet broadcast, to result in ff:ff:ff:ff:ff:ff.

Given that waking up machines isn't a frequent event (compared to
other multicast traffic, where used - neighbour discovery, routing
protocols, video streams, etc.), I don't feel ignoring others WoL
packets on the interupt stack is a huge burden for the non-addressed
machines.

Do we have typical numbers? If I'd measure on my networks, I'd have
about none on our work LANs, and one every couple of weeks at home.

But I imagine people might want to wake every host once a night
and run some backup or software update remotely; so unconcerned
machines would see, say, one or two packets times the number of
sleeping machines per night. How many hosts do you have per broadcast
domain? more than 2**8?

There's another consideration: if you do have the need, due to huge
broadcast domains, nobody prevents you to make your machines
subscribe to a locally assigned multicast address and send your
WoL packets there. All the magic is in the data portion. So why 
change how switches work?

-is

MTU Problem: Akamai,HE,GTT

[Ignatios Souvatzis]

Hi,

for at least one weatheronline.co.uk seems to hang most of the time for
some of my users. The reason is javascript code unconditionally loaded
from connect.facebook.net.

connect.facebook.net is an alias for connect.facebook.net.edgekey.net.
connect.facebook.net.edgekey.net is an alias for e3821.dspe1.akamaiedge.net.
e3821.dspe1.akamaiedge.net has IPv6 address 2a02:26f0:6a:191::eed
e3821.dspe1.akamaiedge.net has IPv6 address 2a02:26f0:6a:18f::eed

The latter two networks (or at least one of them) seem to block
IPv6 packets of too large a size.

I get replies to ICMPv6 echo requests with PING6(1280=40+8+1232 bytes)
but not bigger; I suspect an icmpv6 black hole somwehere.

However, some others show the same problem.

Working (addresses shortened):

2001:638:a000:: (fully inside DFN), but also

2a00:19e0::
2001:608::
2001:200::

so I think it's not a problem with two DFN internal tunnels I'm aware of
(one inside Univ. of Bonn, one the UoB's next hop).

Not working:

2001:470::  (routed through he.net)
2001:1900:2254::(routed through he.net/yahoo)
2a02:26f0:6a::  (routed through gtt.net)

I can workaround on my workgroup edge router, but I guess it would be
more helpful if the real problem would be fixed.

Regards,
Ignatios Souvatzis

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

[Ignatios Souvatzis]

Hi,

On Wed, Sep 17, 2014 at 10:14:31AM +0200, Mikael Abrahamsson wrote:

 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.

Uh, no.

the link-local stuff must never be snooped and blocked, because it is 
used to implement neighbour discovery and multicast routing protocols,
multicast group managment etc.

I think there's explicit wording for this - at least for the low /112 -
somehwere.

-is

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

[Ignatios Souvatzis]

On Wed, Sep 17, 2014 at 11:59:55AM +0200, Ignatios Souvatzis wrote:
 Hi,
 
 On Wed, Sep 17, 2014 at 10:14:31AM +0200, Mikael Abrahamsson wrote:
 
  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.
 
 Uh, no.
 
 the link-local stuff must never be snooped and blocked, because it is 
 used to implement neighbour discovery and multicast routing protocols,
 multicast group managment etc.
 
 I think there's explicit wording for this - at least for the low /112 -
 somehwere.

I slightly misremembered.

RFC 4541 Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches says:

3. IPv6 Considerations
 [...]

   In IPv6, the data forwarding rules are more straight forward because
   MLD is mandated for addresses with scope 2 (link-scope) or greater.
   The only exception is the address FF02::1 which is the all hosts
   link-scope address for which MLD messages are never sent.  Packets
   with the all hosts link-scope address should be forwarded on all
   ports.

-is

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

[Ignatios Souvatzis]

On Mon, Sep 15, 2014 at 07:46:04PM +0200, Thomas Schäfer wrote:

 I am still looking for an IPv6-wol (without mono)

I suspect that sending to the all-stations multicast would work, wouldn't
it? The hardware detects the magic pattern anywhere in the packet.

Thinking about it - it should work whether the target machine uses IPv6
in normal operation or not.

-is

Re: Poll on SMTP over IPv6 Usage

[Ignatios Souvatzis]

On Mon, Feb 17, 2014 at 03:37:28PM +, Nick Hilliard wrote:
 On 17/02/2014 15:16, Ignatios Souvatzis wrote:
  Not necessarily. All I'd imagine to do with

I should maybe have added: e-mail over

  UUCP can be done with
  postfix and maybe transport tables; I've run a connection that way
  for a couple of years.
 
 This is rapidly turning into a contest of who's admitting to the greatest
 MTA horrors.

Anonymized:

@domain.example uucp:nexthop
@.domain.exampleuucp:nexthop
@another.exampleuucp:nexthop!targethost

-is

Re: Poll on SMTP over IPv6 Usage

[Ignatios Souvatzis]

On Thu, Feb 13, 2014 at 03:23:21PM -0500, James Small wrote:
 Interested in what you're using to send/receive SMTP over IPv6:
 
 A) Using  (product) from __ (vendor)

three systems where I'm (partially) responsible

1. A) Using postfix from NetBSD

2. partially A) (clients to sub-dept. server) , using Postfix from NetBSD
  (big dept. server not IPv6-enabled, because infrastructure not on v6 yet)

3. was A using postfix from Gentoo for some years; machine moved to a
  location where IPv6 is promised really soon now. 

Regards,
-is

Re: show ipv6 destination cache on BSD host

[Ignatios Souvatzis]

On Thu, Jan 30, 2014 at 09:20:18PM +0100, Matjaz Straus Istenic wrote:
 On 30. jan. 2014, at 21:13, Nick Hilliard n...@inex.ie wrote:
 
  ndp -an
 Well, this is for local IPv6 ND cache only. I'm looking for a command to 
 display the _destination_ cache in order to check for changed Path MTU. Rui's 
 suggestions works fine:

Ah. For NetBSD, this seems to be what you want:

agent: netstat -f inet6 -nr | grep D
DestinationGatewayFlagsRefs 
 UseMtu Interface
2001:638:e813:a00::d25 fe80::20d:61ff:fe46:50ad%xennet0 UGHD
01   1280  xennet0
2a01:170:1012:77::25   fe80::20d:61ff:fe46:50ad%xennet0 UGHD
1   14   1280  xennet0

Re: Amount of announced IPv4-space by ASN not announcing IPv6?

[Ignatios Souvatzis]

On Tue, Aug 13, 2013 at 08:49:54PM +0200, Martin Millnert wrote:

 We still have the last big problem with access enablement (how many
 NRENs have member universities with access-enabled IPv6?), and CPEs.

In Germany, about 1.01 or 2.01 (the .01 being my part of my department),
to my knowledge.

-is

Re: teredo.ipv6.microsoft.com off?

[Ignatios Souvatzis]

Hello,

On Tue, Jul 16, 2013 at 09:27:54PM +, Christopher Palmer wrote:
 I am acking this thread.
 
 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. 

Let me ask one thing... a couple of years ago, when I read the
specification of Teredo, I was quite impressed by the details (If
you accept the premise that you have to work around being jailed
behind an IPv4 NAT) put into the protocol. One detail was that it
is supposed to be lowest priority and so go automatically away
(from the client end) as soon as some configued IPv6 is available
on the link.

Isn't that how it's implemented?

Regards,
-is

Re: teredo.ipv6.microsoft.com off?

[Ignatios Souvatzis]

On Sat, Jul 13, 2013 at 10:39:12PM +0300, Tassos Chatzithomaoglou wrote:

 At the same time, i'm thinking out loud...
 Why would a windows application send an a request to an IPv6 DNS
 server over native IPv6 in order to find the IPv4 address of a
 server and get IPv6 over IPv4 connectivity?

Why not? Thinking in order to is wrong... it's just a database
lookup.

It just happens that in this case, asking over IPv6 can't work.
But this should be no problem as the database lookup will be repeated
over other transports until it succeeds.

In the general case, you don't know whether connectivity to address X of
type Y is possible until you try it, and unfortunately, sometimes only 
after a time-out period has passed without answer. 

Regards,
-is