[swinog] Call for presentations EPF 10

2015-06-30 Diskussionsfäden Arnold Nipper
Call for Presentations
European Peering Forum 10

AMS-IX, DE-CIX, LINX, Netnod and guest IXP Equinix, are happy to host
the 10th European Peering Forum (EPF) in Madrid, Spain from the 21st
till the 23th of September 2015. The event will welcome up to 250
peering managers and coordinators from networks connected to the host
Internet exchanges. Besides an interesting topical agenda, the three-day
event accommodates room for attendees to meet on a one-to-one basis to
discuss bilateral peering business opportunities.

The programme committee will be looking for presentations and lightning
talks related to peering and technical topics of interconnection. Your
presentation should address

 * Interconnection Automation
 * Regional Peering
 * Interconnection and Peering Internet Governance and Regulatory Topics
 * Economic and Product Trends
 * Peering/Interconnection Strategy
 * Interesting findings about peering
 * 100GE


Submissions
===

Presentations must be of a non-commercial nature. Product or marketing
heavy talks are strongly discouraged.

Submissions of  presentations should be made to the programme committee
. Please include:

 * Author's name and e-mail
 * Presentation title
 * Abstract
 * Slides (if available)
 * Time requested

Deadlines
=

Presentation Abstract Deadline   2015-07-20 12:00 UTC
Final Selection of Speakers  2015-07-31
Presentation Slides Submission Deadline  2015-09-04 12:00 UTC

-- 
Arnold Nipper
CTO/COO and Co-Founder

DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main |
Germany | www.de-cix.net | Phone +49 69 1730902 22 |
Mobile +49 172 2650958 | Fax +49 69 4056 2716 |
arnold.nip...@de-cix.net | Geschaeftsfuehrer Harald A. Summa |
Registergericht AG Koeln HRB 51135





signature.asc
Description: OpenPGP digital signature

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


[swinog] ISOC InterCommunity 2015

2015-06-30 Diskussionsfäden Jan Boogman
-- Forwarded message --

Invitation to ISOC InterCommunity 2015 on July 8th


Summary
===

On Wed, 08 July 2015 08-16 the ISOC InterCommunity 2015 is taking place as
a worldwide event interconnected by means of Videoconferencing. In
Switzerland we have two sites (Zurich and Geneva), where people can attend
physically.

From Zurich National Councilor (Nationalrat) Balthasar Glättli
will inform us about the latest development regarding the new
surveillance From Istanbul we will hear about the consequences of
governmental Internet interference.

The is also lots of room for discussions among the participants around
Europe. Breakfast and lunch included for all local participants.

Please register by July 5th on:

*  Zurich: http://www.isoc.ch/events/isoc-intercommunity-2015-zurich
*  Geneva: http://www.isoc.ch/events/isoc-intercommunity-2015-geneva


Long version


The ISOC InterCommunity 2015 meeting will take place on Wednesday, 8. July 2015 
08:00; a meeting around the globe by means of video-conferencing. We cordially 
invite you to join us locally in Zurich or Geneva. We will offer breakfast and 
lunch for all local participants.

After the global part (8-10:30), an Inter-European meeting, with interconnected 
hubs from Istanbul, Amsterdam, Geneva and Zurich is taking place (11-16). 
Besides presentations from all the hubs, the agenda (see below) has a lot of 
room for interactive discussions.

As you may know the Swiss Parliament is currently debating on two new laws
to extend surveillance of citizens in Switzerland (BÜFF/NDG), where law 
enforcement and secret service demand more access to all citizens communication 
data.

National Councilor (Nationalrat) Balthasar Glättli will give us an update on
the state of the parliamentary debate of these two surveillance acts.
Another highlight will be the contribution from Istanbul which shows the
consequences of too much governmental surveillance (including censorship).
You can find all contributions in the agenda below.


If you will attend personally in Zurich or Geneva, please register now on:

*  Zurich: http://www.isoc.ch/events/isoc-intercommunity-2015-zurich
*  Geneva: http://www.isoc.ch/events/isoc-intercommunity-2015-geneva

We kindly request you to register latest by July, 5th.


Agenda:

07:45 – 08:00 Arrival of participants / Networking / Breakfast

08:00 – 10:30 1st session

ISOC InterCommunity2015 (worldwide)

*  Introduction by Kathy Brown, President and CEO
*  The Global Internet Report and Accessibility, Michael Kende
*  Collaborative Governance, Constance Bommelaar
*  Collaborative Security, Olaf Kolkman
*  The Identity of the Internet Society, James Wood
*  Closing by Kathy Brown, President and CEO

10:30 – 11:00 Coffee Break

11:00 – 12:30 2nd session

*  From GENEVA:
  An overall view on privacy and surveillance
  by Christine Runnegar, ISOC Director of Public Policy

*  From AMSTERDAM:
  Recent development privacy and surveillance in the European Union (EU)
  by N.N.

*  Open Discussion among the participants (on all presentations)

12:30 – 14:00 Lunch Break

14:00 – 16:00 3rd session

*  From ZURICH:
  Current proposals in Swiss parliament on extending governmental
  surveillance (BÜPF/NDG)
  by National Councilor Balthasar Glättli, member of the Swiss Parliament

*  From ISTANBUL:
  Privacy, Censorship and Surveillance under Turkish Law and Practice: An
  Overview of a Problematic Decade
  by Ceren Unal, LLM-President, Internet Society Turkey Chapter

*  Open Discussion among the participants (on both presentations)





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Cablecom DS-Lite breaks IPv4 path MTU?

2015-06-30 Diskussionsfäden gall
On Mon, 29 Jun 2015 18:30:39 +0200, David Schweikert  said:

> Hi,
> I tried to report this issue to the Cablecom support, but I wasn't very
> successful...

> Recently, it looks like my home Cablecom connection was migrated to a DS-Lite
> setup. I get a public IPv6 address and a private IPv4 address. My IPv4 packets
> get encapsulated in IPv6, sent to a NATing gateway in the Cablecom network, 
> and
> NATed there. At least, I have native IPv6 at home now, which is nice, but this
> is creating various problems for me. The worse one seems to be that path MTU 
> is
> broken:

>   dws@shuttle:~$ ping -s 1433 8.8.8.8
>   PING 8.8.8.8 (8.8.8.8) 1433(1461) bytes of data.
>   From 192.0.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1474)
>   From 192.0.0.2 icmp_seq=2 Frag needed and DF set (mtu = 1474)
>   From 192.0.0.2 icmp_seq=3 Frag needed and DF set (mtu = 1474)

> So some Cablecom router is sending ICMP errors saying that I should fragment
> the packets to at most 1474 bytes, when in fact I am sending packets that are
> 1461 bytes long. As you can see above, ping doesn't work at all with path MTU
> discovery, because the discovered MTU is incorrect.

> If I manually reduce the size to 1460, it works, so this seems to be the
> real MTU:

>   dws@shuttle:~$ ping -s 1432 8.8.8.8
>   PING 8.8.8.8 (8.8.8.8) 1432(1460) bytes of data.
>   1440 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=10.4 ms
>   1440 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=10.6 ms

> Do you agree with my analysis that this is a problem in Cablecom's network?

The tunnel adds 40 bytes of overhead for the IPv6 header, but the
DS-Lite spec says that the tunnel endpoints MUST perform fragmentation
and reassembly of the IPv6 packet such that the IPv4 packet can be
transported without fragmentation.

I suppose that this actually works, since you're getting the PTB
message from the "AFTR" element's IPv4 address (the inside of the
carrier's NAT), i.e. the packet must have already left the tunnel.
Now, I'd expect that the MTU of the next link, which is the outside of
the CGN, is 1500.  In this case, that MTU appears to be 1474, which
would indicate that there is another encapsulation happening upstream,
but the overhead of 26 bytes (20 bytes IPv4 plus 6 bytes tunnel
header) looks unfamiliar.  This may be strange but it should still
work.  It would be interesting to understand why this additional
overhead is there, though.

The actual problem is the fact that packets that do conform to the
advertised MTU are dropped if they are between 1461 and 1474 bytes
long.  That's a classical MTU blackhole and breaks PMTUD, as you say.
This needs to be fixed by Cablecom.

-- 
Alex


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog