From ben at bjencks.net  Tue Jul  6 20:11:25 2010
From: ben at bjencks.net (Ben Jencks)
Date: Tue, 6 Jul 2010 14:11:25 -0400
Subject: v6/v4 DNAT-like functionality in Linux
Message-ID: <AANLkTil1eX1BHXX2jTKtF6vkV57uulN_mOd6IQ1FwWjq@mail.gmail.com>

(This is a little OT because it's for a private network, but it could
have relevance to content providers as well.)

Here's the problem: I currently run IPv4 on a private network, and use
a Linux router with DNAT and SNAT/MASQUERADE on the edges to let
internal hosts open outbound tcp connections with specific external
hosts on specific ports, also over IPv4. I'd like to use IPv6 in the
private network, but still do the same DNAT to IPv4 so that it looks
the same from outside. That is, I want to be able to say something
like

ip6tables -t nat -A PREROUTING -p tcp -d 2001:0db8:dead:beef::1234/128
--dport 5678 -j DNAT64 --to 192.0.2.50:2345 --v4-source 192.0.2.49

The only thing I've found is ecdysis, but that's clearly limited to
providing general internet access, not allowing arbitrary
port-specific redirects. A similar thing in reverse would also be
useful, to catch v4 tcp streams and redirect them to v6 addresses.

I might be able to rig something up with netcat6 piped to itself, but
that sounds fragile, and it would be nice to just do it in netfilter.
Also, there doesn't seem to be any pure-v6 DNAT functionality either,
to redirect v6 tcp streams to a local address.

Is there such a module? Am I missing another, possibly more generic,
way of doing things? Does anyone else have this need? Is there a
better forum for this question?

-Ben

From md at Linux.IT  Wed Jul  7 00:02:00 2010
From: md at Linux.IT (Marco d'Itri)
Date: Wed, 7 Jul 2010 00:02:00 +0200
Subject: v6/v4 DNAT-like functionality in Linux
In-Reply-To: <AANLkTil1eX1BHXX2jTKtF6vkV57uulN_mOd6IQ1FwWjq@mail.gmail.com>
References: <AANLkTil1eX1BHXX2jTKtF6vkV57uulN_mOd6IQ1FwWjq@mail.gmail.com>
Message-ID: <20100706220200.GA5171@bongo.bofh.it>

On Jul 06, Ben Jencks <ben at bjencks.net> wrote:

> Here's the problem: I currently run IPv4 on a private network, and use
> a Linux router with DNAT and SNAT/MASQUERADE on the edges to let
> internal hosts open outbound tcp connections with specific external
> hosts on specific ports, also over IPv4. I'd like to use IPv6 in the
> private network, but still do the same DNAT to IPv4 so that it looks
> the same from outside. That is, I want to be able to say something
http://www.isc.org/software/aftr

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100707/a65e005b/attachment.bin 

From me at benedikt-stockebrand.de  Wed Jul  7 12:33:05 2010
From: me at benedikt-stockebrand.de (Benedikt Stockebrand)
Date: Wed, 07 Jul 2010 10:33:05 +0000
Subject: v6/v4 DNAT-like functionality in Linux
In-Reply-To: <AANLkTil1eX1BHXX2jTKtF6vkV57uulN_mOd6IQ1FwWjq@mail.gmail.com>
	(Ben Jencks's message of "Tue, 6 Jul 2010 14:11:25 -0400")
References: <AANLkTil1eX1BHXX2jTKtF6vkV57uulN_mOd6IQ1FwWjq@mail.gmail.com>
Message-ID: <sa7d3uz1t0e.fsf@benedikt-stockebrand.de>

Hi Ben and list,

Ben Jencks <ben at bjencks.net> writes:

> Here's the problem: I currently run IPv4 on a private network, and use
> a Linux router with DNAT and SNAT/MASQUERADE on the edges to let
> internal hosts open outbound tcp connections with specific external
> hosts on specific ports, also over IPv4. I'd like to use IPv6 in the
> private network, but still do the same DNAT to IPv4 so that it looks
> the same from outside.
> [...]
> I might be able to rig something up with netcat6 piped to itself, but
> that sounds fragile, and it would be nice to just do it in netfilter.
> Also, there doesn't seem to be any pure-v6 DNAT functionality either,
> to redirect v6 tcp streams to a local address.
>
> Is there such a module? Am I missing another, possibly more generic,
> way of doing things? Does anyone else have this need?

nc may be a bit of a kludge for this job, but consider using socat as
a transparent (aka. application agnostic) proxy.  I am using it for
that sort of job for a few years now and it works without problems.  I
suppose if you had a significant number of ports to forward you might
even start it via inetd, but I've never had a reason to try this.

Unless you are really desperate for performance this approach should
get you all the flexibility as well as portability (at least within
the Un*x world) you may need.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/


From tore.anderson at redpill-linpro.com  Wed Jul  7 13:46:45 2010
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Wed, 07 Jul 2010 13:46:45 +0200
Subject: v6/v4 DNAT-like functionality in Linux
In-Reply-To: <AANLkTil1eX1BHXX2jTKtF6vkV57uulN_mOd6IQ1FwWjq@mail.gmail.com>
References: <AANLkTil1eX1BHXX2jTKtF6vkV57uulN_mOd6IQ1FwWjq@mail.gmail.com>
Message-ID: <4C346925.9070005@redpill-linpro.com>

Hi Ben,

* Ben Jencks

> Here's the problem: I currently run IPv4 on a private network, and use
> a Linux router with DNAT and SNAT/MASQUERADE on the edges to let
> internal hosts open outbound tcp connections with specific external
> hosts on specific ports, also over IPv4. I'd like to use IPv6 in the
> private network, but still do the same DNAT to IPv4 so that it looks
> the same from outside.

If you only need to relay TCP, HAProxy can do it.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From sethm at rollernet.us  Wed Jul  7 23:19:23 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 07 Jul 2010 14:19:23 -0700
Subject: DNS Exit using ::1
Message-ID: <4C34EF5B.2090304@rollernet.us>

I recently ran across this gem while trying to troubleshoot a domain for
a customer:

ns1.dnsexit.com.        28800   IN      A       69.57.160.118
ns1.dnsexit.com.        28800   IN      AAAA    ::1
ns2.dnsexit.com.        59400   IN      A       64.182.102.188
ns2.dnsexit.com.        59400   IN      AAAA    ::1
ns3.dnsexit.com.        57600   IN      A       67.214.175.73
ns3.dnsexit.com.        57600   IN      AAAA    ::1
ns4.dnsexit.com.        57600   IN      A       67.214.161.154
ns4.dnsexit.com.        57600   IN      AAAA    ::1

I was trying to figure out why dig kept saying no servers were reachable
until I tried from a IPv4 only site and saw the above. So far it just
seems like a nice way to intentionally break things.

~Seth

From bmanning at vacation.karoshi.com  Wed Jul  7 23:34:05 2010
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 7 Jul 2010 21:34:05 +0000
Subject: DNS Exit using ::1
In-Reply-To: <4C34EF5B.2090304@rollernet.us>
References: <4C34EF5B.2090304@rollernet.us>
Message-ID: <20100707213405.GC8437@vacation.karoshi.com.>

On Wed, Jul 07, 2010 at 02:19:23PM -0700, Seth Mattinen wrote:
> I recently ran across this gem while trying to troubleshoot a domain for
> a customer:
> 
> ns1.dnsexit.com.        28800   IN      A       69.57.160.118
> ns1.dnsexit.com.        28800   IN      AAAA    ::1
> ns2.dnsexit.com.        59400   IN      A       64.182.102.188
> ns2.dnsexit.com.        59400   IN      AAAA    ::1
> ns3.dnsexit.com.        57600   IN      A       67.214.175.73
> ns3.dnsexit.com.        57600   IN      AAAA    ::1
> ns4.dnsexit.com.        57600   IN      A       67.214.161.154
> ns4.dnsexit.com.        57600   IN      AAAA    ::1
> 
> I was trying to figure out why dig kept saying no servers were reachable
> until I tried from a IPv4 only site and saw the above. So far it just
> seems like a nice way to intentionally break things.
> 
> ~Seth

	Certainly someone is not clear on how the DNS works. :)
	Perhaps they would get more consistent results if they
	were to map the A RR's to 127.0.0.1 :)


--bill

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Thu Jul  8 00:20:35 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Thu, 8 Jul 2010 07:50:35 +0930
Subject: DNS Exit using ::1
In-Reply-To: <4C34EF5B.2090304@rollernet.us>
References: <4C34EF5B.2090304@rollernet.us>
Message-ID: <20100708075035.0e38808b@opy.nosense.org>

On Wed, 07 Jul 2010 14:19:23 -0700
Seth Mattinen <sethm at rollernet.us> wrote:

> I recently ran across this gem while trying to troubleshoot a domain for
> a customer:
> 
> ns1.dnsexit.com.        28800   IN      A       69.57.160.118
> ns1.dnsexit.com.        28800   IN      AAAA    ::1
> ns2.dnsexit.com.        59400   IN      A       64.182.102.188
> ns2.dnsexit.com.        59400   IN      AAAA    ::1
> ns3.dnsexit.com.        57600   IN      A       67.214.175.73
> ns3.dnsexit.com.        57600   IN      AAAA    ::1
> ns4.dnsexit.com.        57600   IN      A       67.214.161.154
> ns4.dnsexit.com.        57600   IN      AAAA    ::1
> 
> I was trying to figure out why dig kept saying no servers were reachable
> until I tried from a IPv4 only site and saw the above. So far it just
> seems like a nice way to intentionally break things.
> 

From their webpage -

"Our DNS still keeps 100% uptime history since we started in 1998."

Not any more ... their DNS servers a ::1 don't work :-)



> ~Seth

From bmanning at vacation.karoshi.com  Thu Jul  8 00:22:50 2010
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 7 Jul 2010 22:22:50 +0000
Subject: DNS Exit using ::1
In-Reply-To: <20100708075035.0e38808b@opy.nosense.org>
References: <4C34EF5B.2090304@rollernet.us>
	<20100708075035.0e38808b@opy.nosense.org>
Message-ID: <20100707222250.GA9172@vacation.karoshi.com.>

On Thu, Jul 08, 2010 at 07:50:35AM +0930, Mark Smith wrote:
> On Wed, 07 Jul 2010 14:19:23 -0700
> Seth Mattinen <sethm at rollernet.us> wrote:
> 
> > I recently ran across this gem while trying to troubleshoot a domain for
> > a customer:
> > 
> > ns1.dnsexit.com.        28800   IN      A       69.57.160.118
> > ns1.dnsexit.com.        28800   IN      AAAA    ::1
> > ns2.dnsexit.com.        59400   IN      A       64.182.102.188
> > ns2.dnsexit.com.        59400   IN      AAAA    ::1
> > ns3.dnsexit.com.        57600   IN      A       67.214.175.73
> > ns3.dnsexit.com.        57600   IN      AAAA    ::1
> > ns4.dnsexit.com.        57600   IN      A       67.214.161.154
> > ns4.dnsexit.com.        57600   IN      AAAA    ::1
> > 
> > I was trying to figure out why dig kept saying no servers were reachable
> > until I tried from a IPv4 only site and saw the above. So far it just
> > seems like a nice way to intentionally break things.
> > 
> 
> >From their webpage -
> 
> "Our DNS still keeps 100% uptime history since we started in 1998."
> 
> Not any more ... their DNS servers a ::1 don't work :-)
> 
> 
> 
> > ~Seth

	Bosh! of course it works...  as long as the zones are defined
	on the nameserver running at ::1 ...

--bill

From Andreas.Schwarz at hansenet.com  Thu Jul  8 00:29:42 2010
From: Andreas.Schwarz at hansenet.com (Andreas.Schwarz at hansenet.com)
Date: Thu, 8 Jul 2010 00:29:42 +0200
Subject: DNS Exit using ::1
In-Reply-To: <20100708075035.0e38808b@opy.nosense.org>
Message-ID: <568239CAA3656B42876AAD66895250E714050D4B3D@hhexmb02.corp.hansenet.com>

ipv6-ops-bounces+andreas.schwarz=hansenet.com at lists.cluenet.de wrote:

> From their webpage -
> 
> "Our DNS still keeps 100% uptime history since we started in 1998."
> 
> Not any more ... their DNS servers a ::1 don't work :-)

But ::1 are not *their* DNS servers. This is the trick. 8)


best regards,
Andreas

-- 
     HanseNet Telekommunikation GmbH
     Andreas Schwarz, TOS, GPG KeyID 0x3C40103A
     ?berseering 33a, D-22297 Hamburg
     fon: +49-40-23726-3892, fax: +49-40-23726-3772

From marcoh at marcoh.net  Thu Jul  8 09:18:52 2010
From: marcoh at marcoh.net (Marco Hogewoning)
Date: Thu, 8 Jul 2010 09:18:52 +0200
Subject: DNS Exit using ::1
In-Reply-To: <20100708075035.0e38808b@opy.nosense.org>
References: <4C34EF5B.2090304@rollernet.us>
	<20100708075035.0e38808b@opy.nosense.org>
Message-ID: <664380FE-2522-4FC0-BD01-EA027A05179B@marcoh.net>

> "Our DNS still keeps 100% uptime history since we started in 1998."
> 
> Not any more ... their DNS servers a ::1 don't work :-)


Which doesn't mean it's not up :)

MarcoH


From elmi at 4ever.de  Thu Jul  8 09:21:19 2010
From: elmi at 4ever.de (Elmar K. Bins)
Date: Thu, 8 Jul 2010 09:21:19 +0200
Subject: DNS Exit using ::1
In-Reply-To: <664380FE-2522-4FC0-BD01-EA027A05179B@marcoh.net>
References: <4C34EF5B.2090304@rollernet.us>
	<20100708075035.0e38808b@opy.nosense.org>
	<664380FE-2522-4FC0-BD01-EA027A05179B@marcoh.net>
Message-ID: <20100708072119.GV96953@ronin.4ever.de>

marcoh at marcoh.net (Marco Hogewoning) wrote:

> > "Our DNS still keeps 100% uptime history since we started in 1998."
> > 
> > Not any more ... their DNS servers a ::1 don't work :-)
> 
> 
> Which doesn't mean it's not up :)

Actually:

$>dig 4ever.de soa @::1
[...]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63226
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 7

;; QUESTION SECTION:
;4ever.de.                      IN      SOA

;; ANSWER SECTION:
4ever.de.               345600  IN      SOA     ns.4ever.de. hostmaster.4ever.de. 2009122800 10000 5000 864000 36000
[...]


... works ;)

Cheers,
	Elmi.

From gall at switch.ch  Tue Jul 20 10:51:24 2010
From: gall at switch.ch (Alexander Gall)
Date: Tue, 20 Jul 2010 10:51:24 +0200
Subject: Strange source port filtering by Tinet
Message-ID: <19525.25484.514736.515104@hadron.switch.ch>

I've noticed a very peculiar problem with IPv6 traffic transitting
through AS3257.  They did respond to a request to find the problem,
but a week has passed and I suspect that they are not taking me very
seriously.  I believe that this problem affects all traffic, so I'd be
interested if some of you could verify this.  It's a bit complicated,
but please bear with me.  Here's the story.

Netnod has recently started to do IPv6 on their anycast DNS
infrastructure.  So far, only the sites in Stockholm and London are
announcing their prefixes.  They announce less-specifics from
Stockholm, so most of the traffic is currently going to LINX.  The
I-root server is covered by 2001:7fe::/33 (yes, that's /33).  They
also announce 2001:67c:1010::/48, which they use to number the name
servers for their TLD anycast service, like the one for CH called
ch1.dnsnode.net (2001:67c:1010:2::53).

The I-root prefix is announced from AS29216, while the other prefix is
announced by the Netnod AS 8674 itself.  At this time, the site in
London is behind the LINX AS 5459.  As such, the only IPv6 transit is
provided by Tinet, AS3257.  Here's a trace from here (source
2001:620:0:113:21b:78ff:fe30:297e)

traceroute to ch1.dnsnode.net (2001:67c:1010:2::53), 30 hops max, 40 byte packets
 1  swiCE3-V300.switch.ch (2001:620:0:113::1)  0.373 ms
 2  swiZH2-10GE-1-1.switch.ch (2001:620:0:c027::2)  4.125 ms
 3  swiIX1-10GE-1-3.switch.ch (2001:620:0:c015::1)  4.640 ms
 4  swiIX2-10GE-4-4.switch.ch (2001:620:0:c008::2)  4.146 ms
 5  swissix-glb.init7.net (2001:7f8:24::7)  4.152 ms
 6  r1fra1.core.init7.net (2001:1620:2::6)  10.792 ms
 7  ge-4-0-4-295.fra21.ip6.tinet.net (2001:668:0:3::2000:111)  11.406 ms
 8  xe-7-3-0.lon20.ip6.tinet.net (2001:668:0:2::1:1242)  24.745 ms
 9  xe-0-3-0.lon21.ip6.tinet.net (2001:668:0:2::1:1ae2)  24.805 ms
10  xe-5-3-0.lon10.ip6.tinet.net (2001:668:0:2::1:1642)  21.746 ms
11  g0-0-123.tr2.tfm7.thn.linx.net (2001:668:0:3::4000:82)  23.284 ms
12  2a01:40:1003:2::3 (2a01:40:1003:2::3)  23.246 ms
13  ch1.dnsnode.net (2001:67c:1010:2::53)  23.289 ms

I've set up SmokePing DNS and ping probes for I root as well as
ch1.dnsnode.net here:

http://lg.net.switch.ch/cgi-bin/smokeping.cgi?target=Services.CHLIDNS.AutonomicaIRoot
http://lg.net.switch.ch/cgi-bin/smokeping.cgi?target=Services.CHLIDNS.AutonomicaIRootPingv6
http://lg.net.switch.ch/cgi-bin/smokeping.cgi?target=Services.CHLIDNS.Autonomicav6
http://lg.net.switch.ch/cgi-bin/smokeping.cgi?target=Services.CHLIDNS.AutonomicaPingv6

Two things are immediately obvious

- ping RTTs are very stable and lossless

- DNS probes have high jitter (3ms) and loss

The jitter is most likely due to equal-cost multipathing within AS3257
(which affects TCP and UDP flows but all ICMP traffic is on a single
path).  This is not pretty but doesn't worry me too much.

When I tried to find the reason for the packet loss, I discovered that
all UDP and TCP packets with source ports in the range 35072 through
35327 are dropped!  This can be easily tested with dig, e.g.

: gall at atitlan[gall]; dig -b2001:620:0:114:21b:78ff:fe30:2974#35071 @ch1.dnsnode.net ch. soa +short +timeout=1
a.nic.ch. helpdesk.nic.ch. 2010072010 3600 900 2592000 3600
: gall at atitlan[gall]; dig -b2001:620:0:114:21b:78ff:fe30:2974#35072 @ch1.dnsnode.net ch. soa +short +timeout=1

; <<>> DiG 9.7.0-P1 <<>> -b2001:620:0:114:21b:78ff:fe30:2974#35072 @ch1.dnsnode.net ch. soa +short +timeout=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

With a traceroute that allows to fix the source port, the last hop I
see is the one preceeding the first Tinet router at DE-CIX

: gall at atitlan[gall]; traceroute6 -s 2001:620:0:113:21b:78ff:fe30:297e --sport=35072 -q1 -N1 -w1 ch1.dnsnode.net
traceroute to ch1.dnsnode.net (2001:67c:1010:2::53), 30 hops max, 40 byte packets
 1  swiCE3-V300.switch.ch (2001:620:0:113::1)  0.301 ms
 2  swiZH2-10GE-1-1.switch.ch (2001:620:0:c027::2)  4.144 ms
 3  swiIX1-10GE-1-3.switch.ch (2001:620:0:c015::1)  4.312 ms
 4  swiIX2-10GE-4-4.switch.ch (2001:620:0:c008::2)  4.178 ms
 5  swissix-glb.init7.net (2001:7f8:24::7)  4.151 ms
 6  r1fra1.core.init7.net (2001:1620:2::6)  18.958 ms
 7  *
 8  *
 9  *^C

I checked with the people at Netnod that the packets are lost on the
forward path.

I actually scanned all ports from 1024 through 65535 with dig and it's
exactly those 256 ports that share this fate.  Note that the port
range in hex is 0x8900 through 0x89ff and 0x89 is 137 in decimal.  A
wild speculation is that a filter for NetBIOS at the Tinet border
could be buggy.

I can reproduce this from our own AS559 as well as from a host in
AS2914.  To support my theory, I'd be grateful if some of you could
run these dig and traceroute tests to see if you can reproduce this.

Regards,
Alex


From marcoh at marcoh.net  Tue Jul 20 11:20:16 2010
From: marcoh at marcoh.net (Marco Hogewoning)
Date: Tue, 20 Jul 2010 11:20:16 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <19525.25484.514736.515104@hadron.switch.ch>
References: <19525.25484.514736.515104@hadron.switch.ch>
Message-ID: <14545A1A-B278-4928-920F-A7B84F32C910@marcoh.net>


On 20 jul 2010, at 10:51, Alexander Gall wrote:

> I've noticed a very peculiar problem with IPv6 traffic transitting
> through AS3257.  They did respond to a request to find the problem,
> but a week has passed and I suspect that they are not taking me very
> seriously.  I believe that this problem affects all traffic, so I'd be
> interested if some of you could verify this.  It's a bit complicated,
> but please bear with me.  Here's the story.
> I actually scanned all ports from 1024 through 65535 with dig and it's
> exactly those 256 ports that share this fate.  Note that the port
> range in hex is 0x8900 through 0x89ff and 0x89 is 137 in decimal.  A
> wild speculation is that a filter for NetBIOS at the Tinet border
> could be buggy.
> 
> I can reproduce this from our own AS559 as well as from a host in
> AS2914.  To support my theory, I'd be grateful if some of you could
> run these dig and traceroute tests to see if you can reproduce this.


I can reproduce thiis from within AS3265, both by taking a route via he.net as well as  direct via 3257.

Groet,

MarcoH


From elmi at 4ever.de  Tue Jul 20 11:22:15 2010
From: elmi at 4ever.de (Elmar K. Bins)
Date: Tue, 20 Jul 2010 11:22:15 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <14545A1A-B278-4928-920F-A7B84F32C910@marcoh.net>
References: <19525.25484.514736.515104@hadron.switch.ch>
	<14545A1A-B278-4928-920F-A7B84F32C910@marcoh.net>
Message-ID: <20100720092214.GH96953@ronin.4ever.de>

marcoh at marcoh.net (Marco Hogewoning) wrote:

> > I can reproduce this from our own AS559 as well as from a host in
> > AS2914.  To support my theory, I'd be grateful if some of you could
> > run these dig and traceroute tests to see if you can reproduce this.
> 
> 
> I can reproduce thiis from within AS3265, both by taking a route via he.net as well as  direct via 3257.

As an add-on (I wrote to Alex but not the list), I also see this
to the .de servers at l.de.net. I have notified Tinet, let's see
if they can clear up the issue.

Cheers,
	Elmi.

-- 

"Machen Sie sich erst einmal unbeliebt. Dann werden Sie auch ernstgenommen."
							     (Konrad Adenauer)

--------------------------------------------------------------[ ELMI-RIPE ]---


From gall at switch.ch  Tue Jul 20 11:27:22 2010
From: gall at switch.ch (Alexander Gall)
Date: Tue, 20 Jul 2010 11:27:22 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <20100720092214.GH96953@ronin.4ever.de>
References: <19525.25484.514736.515104@hadron.switch.ch>
	<14545A1A-B278-4928-920F-A7B84F32C910@marcoh.net>
	<20100720092214.GH96953@ronin.4ever.de>
Message-ID: <19525.27642.287222.532546@hadron.switch.ch>

On Tue, 20 Jul 2010 11:22:15 +0200, "Elmar K. Bins" <elmi at 4ever.de> said:

> marcoh at marcoh.net (Marco Hogewoning) wrote:
>> > I can reproduce this from our own AS559 as well as from a host in
>> > AS2914.  To support my theory, I'd be grateful if some of you could
>> > run these dig and traceroute tests to see if you can reproduce this.
>> 
>> 
>> I can reproduce thiis from within AS3265, both by taking a route via he.net as well as  direct via 3257.

> As an add-on (I wrote to Alex but not the list), I also see this
> to the .de servers at l.de.net. I have notified Tinet, let's see
> if they can clear up the issue.

Thanks a lot for checking and escalating this.  Much appreciated.

-- 
Alex



From daniel at bit.nl  Tue Jul 20 11:31:01 2010
From: daniel at bit.nl (Daniel Verlouw)
Date: Tue, 20 Jul 2010 11:31:01 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <19525.25484.514736.515104@hadron.switch.ch>
References: <19525.25484.514736.515104@hadron.switch.ch>
Message-ID: <1279618261.21508.10.camel@daniel>

On Tue, 2010-07-20 at 10:51 +0200, Alexander Gall wrote:
> I can reproduce this from our own AS559 as well as from a host in
> AS2914.  To support my theory, I'd be grateful if some of you could
> run these dig and traceroute tests to see if you can reproduce this.

I can reproduce from AS12859 with direct paths to 3257 in both Frankfurt
and London. Both paths show this issue.

Regards,
  Daniel.


From marcoh at marcoh.net  Tue Jul 20 11:31:58 2010
From: marcoh at marcoh.net (Marco Hogewoning)
Date: Tue, 20 Jul 2010 11:31:58 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <20100720092214.GH96953@ronin.4ever.de>
References: <19525.25484.514736.515104@hadron.switch.ch>
	<14545A1A-B278-4928-920F-A7B84F32C910@marcoh.net>
	<20100720092214.GH96953@ronin.4ever.de>
Message-ID: <BD5953E4-6C52-49FD-88C5-077EC9019B32@marcoh.net>


On 20 jul 2010, at 11:22, Elmar K. Bins wrote:

> marcoh at marcoh.net (Marco Hogewoning) wrote:
> 
>>> I can reproduce this from our own AS559 as well as from a host in
>>> AS2914.  To support my theory, I'd be grateful if some of you could
>>> run these dig and traceroute tests to see if you can reproduce this.
>> 
>> 
>> I can reproduce thiis from within AS3265, both by taking a route via he.net as well as  direct via 3257.
> 
> As an add-on (I wrote to Alex but not the list), I also see this
> to the .de servers at l.de.net. I have notified Tinet, let's see
> if they can clear up the issue.


I'll see if I can log a ticket as well with them

Groet,

MarcoH


From david.freedman at uk.clara.net  Tue Jul 20 11:52:38 2010
From: david.freedman at uk.clara.net (David Freedman)
Date: Tue, 20 Jul 2010 10:52:38 +0100
Subject: Strange source port filtering by Tinet
In-Reply-To: <BD5953E4-6C52-49FD-88C5-077EC9019B32@marcoh.net>
Message-ID: <C86B3076.37ACE%david.freedman@uk.clara.net>

Spoke to them, they believe it is a filter issue and are making changes to
rectify this.

Dave.



On 20/07/2010 10:31, "Marco Hogewoning" <marcoh at marcoh.net> wrote:

> 
> On 20 jul 2010, at 11:22, Elmar K. Bins wrote:
> 
>> marcoh at marcoh.net (Marco Hogewoning) wrote:
>> 
>>>> I can reproduce this from our own AS559 as well as from a host in
>>>> AS2914.  To support my theory, I'd be grateful if some of you could
>>>> run these dig and traceroute tests to see if you can reproduce this.
>>> 
>>> 
>>> I can reproduce thiis from within AS3265, both by taking a route via he.net
>>> as well as  direct via 3257.
>> 
>> As an add-on (I wrote to Alex but not the list), I also see this
>> to the .de servers at l.de.net. I have notified Tinet, let's see
>> if they can clear up the issue.
> 
> 
> I'll see if I can log a ticket as well with them
> 
> Groet,
> 
> MarcoH
> 

--

David Freedman
Group Network Engineering

david.freedman at uk.clara.net
Tel +44 (0) 20 7685 8000

Claranet Group
21 Southampton Row
London - WC1B 5HA - UK
http://www.claranet.com

Company Registration: 3152737 - Place of registration: England

All the information contained within this electronic message from Claranet
Ltd is covered by the disclaimer at http://www.claranet.co.uk/disclaimer



From marcoh at marcoh.net  Tue Jul 20 11:54:18 2010
From: marcoh at marcoh.net (Marco Hogewoning)
Date: Tue, 20 Jul 2010 11:54:18 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <C86B3076.37ACE%david.freedman@uk.clara.net>
References: <C86B3076.37ACE%david.freedman@uk.clara.net>
Message-ID: <C74DE2A8-2C08-489E-AA9A-12CFABC69923@marcoh.net>


On 20 jul 2010, at 11:52, David Freedman wrote:

> Spoke to them, they believe it is a filter issue and are making changes to
> rectify this.


Keep me posted, I'll hold of with the ticket to prevent another person from starting to look for the same problem.

Groet,

MarcoH


From gall at switch.ch  Tue Jul 20 14:24:09 2010
From: gall at switch.ch (Alexander Gall)
Date: Tue, 20 Jul 2010 14:24:09 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <C74DE2A8-2C08-489E-AA9A-12CFABC69923@marcoh.net>
References: <C86B3076.37ACE%david.freedman@uk.clara.net>
	<C74DE2A8-2C08-489E-AA9A-12CFABC69923@marcoh.net>
Message-ID: <19525.38249.658774.809997@hadron.switch.ch>

On Tue, 20 Jul 2010 11:54:18 +0200, Marco Hogewoning <marcoh at marcoh.net> said:

> On 20 jul 2010, at 11:52, David Freedman wrote:

>> Spoke to them, they believe it is a filter issue and are making changes to
>> rectify this.


> Keep me posted, I'll hold of with the ticket to prevent another person from starting to look for the same problem.

Thanks to all who helped me out.  It turned out that Tinet already
opened a ticket after my initial report last week but that didn't get
through to me.  Anyway, a possible fix will be deployed tomorrow
(hopefully).

-- 
Alex



From fred at cisco.com  Wed Jul 21 01:02:18 2010
From: fred at cisco.com (Fred Baker)
Date: Tue, 20 Jul 2010 16:02:18 -0700
Subject: Looking for comments
Message-ID: <D8CDFC36-85F2-4DE1-A547-C3CBFD07D9D3@cisco.com>

Hi

IETF IPv6 Operations WG is looking at this draft, and we're interested in any comments you might have as well.

http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
  "Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred
  Baker, 12-Jul-10

From martin at millnert.se  Wed Jul 21 02:16:08 2010
From: martin at millnert.se (Martin Millnert)
Date: Wed, 21 Jul 2010 02:16:08 +0200
Subject: Looking for comments
In-Reply-To: <D8CDFC36-85F2-4DE1-A547-C3CBFD07D9D3@cisco.com>
References: <D8CDFC36-85F2-4DE1-A547-C3CBFD07D9D3@cisco.com>
Message-ID: <1279671368.10444.30.camel@hsa.vpn.anti>

Hi Fred,

On Tue, 2010-07-20 at 16:02 -0700, Fred Baker wrote:
> Hi
> 
> IETF IPv6 Operations WG is looking at this draft, and we're interested
in any comments you might have as well.
> 
> http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
>   "Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred
>   Baker, 12-Jul-10
> 


I have a comment for Jari on the document (that I kindly ask not to be
turned into a very long and irrelevant thread :-) by the list):

Is it wise to either comment, or not comment on, the "short-term"
non-IPv6 readiness of residential users either privately bought, or ISP
shipped, nat44-CPEs? This has an to me unknown impact on the IPv6
transition of the Internet as a whole.
 
On one hand, when a residential customer is using something privately
managed, the device is by some measure outside the control of its ISP.
Since it is, perhaps it is then also, by some (monetary) logic, clear
that the ISP should not concern itself further.

On the other hand, this *could* amount to a sizeable number of nodes,
whose continued brokeness can have a detrimental effect on the speed of
the IPv6 transition as a whole.  Either improving or denying brokeness
to leave the ISP could then be helpful.

I don't have any real useful data myself.  Not sure how to passively
sniff that out with any accuracy here, but haven't given it any thought
either. 
  Clearly many networks are still of the opinion that there is too much
brokeness out there.

Cheers,
-- 
Martin Millnert <martin at millnert.se>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100721/80b94607/attachment.bin 

From swmike at swm.pp.se  Wed Jul 21 07:31:19 2010
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 21 Jul 2010 07:31:19 +0200 (CEST)
Subject: Looking for comments
In-Reply-To: <D8CDFC36-85F2-4DE1-A547-C3CBFD07D9D3@cisco.com>
References: <D8CDFC36-85F2-4DE1-A547-C3CBFD07D9D3@cisco.com>
Message-ID: <alpine.DEB.1.10.1007210711250.9875@uplift.swm.pp.se>

On Tue, 20 Jul 2010, Fred Baker wrote:

> Hi
>
> IETF IPv6 Operations WG is looking at this draft, and we're interested in any comments you might have as well.
>
> http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
>  "Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred
>  Baker, 12-Jul-10

The first paragraph contains a reference to 24 free /8:s. This is now 16, 
so perhaps a date should be used instead of "as of writing", and a 
quarter/year mentioned when the last /8s will be handed out according to 
current forcasts?

In 3.1, is it really the goal of growing the industry, perhaps a more 
altrusitic goal could be mentioned, like growing and evolving the Internet 
for the good of mankind (or something less high-flying :P)

"insatiable requirements", now we're talking :)

4.1

"allows applications using the two protocols to operate as ships in the 
night": As a non-english native speaker, I don't really know what that 
means. I can guess, I can look it up in websters.com, I can google, but... 
it would be nice if a more easy to understand term was used.


Apart from that I find it a valuable document to sum up what's available.

I'd like to see a mention of SAVI in there, so the document touches on 
some deployment security mechanisms as well. We don't want BCP38 to go out 
the door just because people are moving to IPv6 and for people who don't 
do BCP38 already, from reading the document they should get a notion that 
they need to start doing it when they deploy IPv6.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From mir at ripe.net  Mon Jul 26 11:06:24 2010
From: mir at ripe.net (Mirjam Kuehne)
Date: Mon, 26 Jul 2010 11:06:24 +0200
Subject: Updated IPv6 CPE Survey on RIPE Labs
Message-ID: <4C4D5010.30003@ripe.net>


[apologies for duplicates]


Dear colleagues,

Since Marco Hogewoning published the first version of the IPv6 CPE
Survey on RIPE Labs just after the RIPE Meeting in May, he got some
additional information.

The most up-to-date matrix, including data we received from some of the
vendors in the meantime is now published on RIPE Labs:

https://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated

Should you have any additional experience with some of the equipment
listed there, please leave a comment under the article or contact us at
labs at ripe.net

Kind Regards,
Mirjam K?hne
RIPE NCC



From daniel at bit.nl  Mon Jul 26 17:09:20 2010
From: daniel at bit.nl (Daniel Verlouw)
Date: Mon, 26 Jul 2010 17:09:20 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <19525.38249.658774.809997@hadron.switch.ch>
References: <C86B3076.37ACE%david.freedman@uk.clara.net>
	<C74DE2A8-2C08-489E-AA9A-12CFABC69923@marcoh.net>
	<19525.38249.658774.809997@hadron.switch.ch>
Message-ID: <1280156960.26873.26.camel@daniel>

Hi,

On Tue, 2010-07-20 at 14:24 +0200, Alexander Gall wrote:
> It turned out that Tinet already
> opened a ticket after my initial report last week but that didn't get
> through to me.  Anyway, a possible fix will be deployed tomorrow
> (hopefully).

seems this is fixed now on their Frankfurt peering router:

daniel at daniel:~$ traceroute6 -s 2001:7b8:3:1000:202:b3ff:fe1f:2a28
--sport=35072 -q1 -N1 -w1 ch1.dnsnode.net
traceroute to ch1.dnsnode.net (2001:67c:1010:2::53), 30 hops max, 80
byte packets
 1  fw1.office.bit.nl (2001:7b8:3:1000::1)  0.367 ms
 2  fw1-gw.jun1.bit-2a.network.bit.nl (2001:7b8:3:1c::3)  1.172 ms
 3  803.ge-0-1-0.jun1.fra4.network.bit.nl (2001:7b8:0:323::2)  5.742 ms
 4  de-cix.fra20.ip6.tiscali.net (2001:7f8::cb9:0:1)  19.697 ms
 5  xe-5-3-0.lon20.ip6.tinet.net (2001:668:0:2::1:1232)  35.260 ms
 6  xe-1-0-0.lon21.ip6.tinet.net (2001:668:0:2::1:142)  23.470 ms
 7  xe-5-3-0.lon10.ip6.tinet.net (2001:668:0:2::1:1642)  22.772 ms
 8  g0-0-123.tr2.tfm7.thn.linx.net (2001:668:0:3::4000:82)  20.262 ms
 9  2a01:40:1003:2::3 (2a01:40:1003:2::3)  22.757 ms
10  ch1.dnsnode.net (2001:67c:1010:2::53)  23.124 ms

but I'm still seeing issues through their London POP (which is fairly
odd because we connect directly to the same router as seen in hop 7
above):

daniel at daniel:~$ traceroute6 -s 2001:7b8:3:1000:202:b3ff:fe1f:2a28
--sport=35072 -q1 -N1 -w1 ch1.dnsnode.net
traceroute to ch1.dnsnode.net (2001:67c:1010:2::53), 30 hops max, 80
byte packets
 1  fw1.office.bit.nl (2001:7b8:3:1000::1)  0.290 ms
 2  fw1-gw.jun1.bit-2a.network.bit.nl (2001:7b8:3:1c::3)  0.402 ms
 3  806.ge-0-1-0.jun1.thn.network.bit.nl (2001:7b8:0:326::2)  22.418 ms
 4  *
 5  *
 6  *
 7  *^C

Anyone knows if they're still working on this?

  --Daniel.



From gall at switch.ch  Mon Jul 26 18:04:05 2010
From: gall at switch.ch (Alexander Gall)
Date: Mon, 26 Jul 2010 18:04:05 +0200
Subject: Strange source port filtering by Tinet
In-Reply-To: <1280156960.26873.26.camel@daniel>
References: <C86B3076.37ACE%david.freedman@uk.clara.net>
	<C74DE2A8-2C08-489E-AA9A-12CFABC69923@marcoh.net>
	<19525.38249.658774.809997@hadron.switch.ch>
	<1280156960.26873.26.camel@daniel>
Message-ID: <19533.45557.310738.764113@hadron.switch.ch>

On Mon, 26 Jul 2010 17:09:20 +0200, Daniel Verlouw <daniel at bit.nl> said:

> Hi,
> On Tue, 2010-07-20 at 14:24 +0200, Alexander Gall wrote:
>> It turned out that Tinet already
>> opened a ticket after my initial report last week but that didn't get
>> through to me.  Anyway, a possible fix will be deployed tomorrow
>> (hopefully).

> seems this is fixed now on their Frankfurt peering router:

> daniel at daniel:~$ traceroute6 -s 2001:7b8:3:1000:202:b3ff:fe1f:2a28
> --sport=35072 -q1 -N1 -w1 ch1.dnsnode.net
> traceroute to ch1.dnsnode.net (2001:67c:1010:2::53), 30 hops max, 80
> byte packets
>  1  fw1.office.bit.nl (2001:7b8:3:1000::1)  0.367 ms
>  2  fw1-gw.jun1.bit-2a.network.bit.nl (2001:7b8:3:1c::3)  1.172 ms
>  3  803.ge-0-1-0.jun1.fra4.network.bit.nl (2001:7b8:0:323::2)  5.742 ms
>  4  de-cix.fra20.ip6.tiscali.net (2001:7f8::cb9:0:1)  19.697 ms
>  5  xe-5-3-0.lon20.ip6.tinet.net (2001:668:0:2::1:1232)  35.260 ms
>  6  xe-1-0-0.lon21.ip6.tinet.net (2001:668:0:2::1:142)  23.470 ms
>  7  xe-5-3-0.lon10.ip6.tinet.net (2001:668:0:2::1:1642)  22.772 ms
>  8  g0-0-123.tr2.tfm7.thn.linx.net (2001:668:0:3::4000:82)  20.262 ms
>  9  2a01:40:1003:2::3 (2a01:40:1003:2::3)  22.757 ms
> 10  ch1.dnsnode.net (2001:67c:1010:2::53)  23.124 ms

It has been fixed this afternoon, or, rather, they verified that a
suggested fix to a Juniper bug works.

> but I'm still seeing issues through their London POP (which is fairly
> odd because we connect directly to the same router as seen in hop 7
> above):

> daniel at daniel:~$ traceroute6 -s 2001:7b8:3:1000:202:b3ff:fe1f:2a28
> --sport=35072 -q1 -N1 -w1 ch1.dnsnode.net
> traceroute to ch1.dnsnode.net (2001:67c:1010:2::53), 30 hops max, 80
> byte packets
>  1  fw1.office.bit.nl (2001:7b8:3:1000::1)  0.290 ms
>  2  fw1-gw.jun1.bit-2a.network.bit.nl (2001:7b8:3:1c::3)  0.402 ms
>  3  806.ge-0-1-0.jun1.thn.network.bit.nl (2001:7b8:0:326::2)  22.418 ms
>  4  *
>  5  *
>  6  *
>  7  *^C

> Anyone knows if they're still working on this?

Yes, the fix has probably not yet been rolled out everywhere.

-- 
Alex