Re: Microsoft: Give Xbox One users IPv6 connectivity
Le 2014-03-13 15:12, Eric Vyncke (evyncke) a écrit : What annoys me more if the fact that AVM (and they are not the only one -- see Technicolor others) naively believes that NAT44 offered some security by preventing inbound connections... This means that there is NO open connectivity between two X/Box behind a closed AVM CPE... Hence X/Box has no choice and is smart enough to fall back in the legacy NAT44 mode with a TURN (or in this case Teredo) to bypass NAT. A very nice opportunity to run man-in-the-middle attack on a foreign ground. I still wonder why people REALLY believe in the security of NAT (in the sense of blocking inbound connections) in 2014 while most of the botnet members are behind a NAT... Christopher and others = you are RIGHT! Do not change your mind -éric (see also http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-01 for my point of view :-)) +1000 Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: Poll on SMTP over IPv6 Usage
Postfix + Spamassassin
Browsers and link-local IPv6 address literals
Am I becoming crazy or do URIs such as these no longer work? http://[fe80::1%em0]/ http://[fe80::1%25em0]/ http://[fe80::1%em0]:80/ http://[fe80::1%25em0]:80/ I tested Firefox 26.0 and Chrome 32.0.1700.102 on Fedora 20. The browsers just pass the whole string to Google. There seems to be no attempt at connecting: no ND, no SYN, nothing. Just straight to Google. Did we completely fail with RFC 6874? Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: Browsers and link-local IPv6 address literals
Wow. IE 11 implements RFC 6874 perfectly. This is a shame. Simon Le 2014-02-05 10:43, Simon Perreault a écrit : Am I becoming crazy or do URIs such as these no longer work? http://[fe80::1%em0]/ http://[fe80::1%25em0]/ http://[fe80::1%em0]:80/ http://[fe80::1%25em0]:80/ I tested Firefox 26.0 and Chrome 32.0.1700.102 on Fedora 20. The browsers just pass the whole string to Google. There seems to be no attempt at connecting: no ND, no SYN, nothing. Just straight to Google. Did we completely fail with RFC 6874? Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Le 2014-01-22 11:54, Francis Dupont a écrit : On 20/01/2014 17:12, Simon Perreault wrote: IIRC, recent versions of Bind open a socket per address on IPv4 = not it is not by choice, just: - DNS requires to answer from the address the request was received - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) Exactly what I had guessed. Thanks for confirming. = BIND polls from time to time interfaces to bind() to new addresses (again, there is no standard/portable way to be notified. BTW we (ISC) know this is a point which can be improved so if you know a generic simple solution...) Listening on a routing socket doesn't qualify as generic nor simple, does it? ;) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Le 2014-01-20 09:00, Gert Doering a écrit : I've run into this sort of problems a few years ago, but I used a different solution: I didn't use mapped addresses but two separate sockets, one for IPv4 and another for IPv6. This *is* a long-term goal, though, to enable OpenVPN to listen on multiple sockets in parallel (including udp and tcp in the same server), but this part of the code is *old*, has way too many options, and runs on way too many systems with their own specific surprises. rant In my experience, this is the single most difficult thing about migrating a code base to dual-stack. Code bases that already deal with multiple IPv4-only sockets are *much* easier to migrate to dual-stack than those that expect only a single socket. An example of this is Asterisk, which used only a single socket (I'm talking about SIP here). We considered the alternatives, and eventually decided not to change the whole architecture and instead use IPv4-mapped addresses on a single socket to support dual-stack. And it sucked, of course. But at least it was feasible (with a few tens of thousands line diff). Eventually the whole SIP stuff was ripped out of Asterisk and replaced with a third-party SIP stack that correctly dealt with multiple sockets and thus didn't need IPv4-mappeed addresses to support IPv6. /rant Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Le 2014-01-20 12:00, Gert Doering a écrit : Anyway, if you really want to make your life miserable, open sockets bound to the individual IP addresses found on the machine---and then also listen on a routing socket so you know you have to look for new addresses coming in... (Last time I checked that was pretty much the only option you had with Java.) *That* is where we will *not* go. It's what bind and ntpd do, and it's a large can of different worms we do not like either :-) IIRC, recent versions of Bind open a socket per address on IPv4, and on IPv6 they open a single socket. Seems like the IPv6 extended API has everything they need to do their thing and they no longer need to play socket tricks. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
IPv6 broken on Fedora 20?
Is there any other Fedora user on this list that could confirm this? I filed a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1045118 Thanks, Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: IPv6 broken on Fedora 20?
Le 2013-12-19 11:16, Jeroen Massar a écrit : On 2013-12-19 17:09 , Simon Perreault wrote: Is there any other Fedora user on this list that could confirm this? I filed a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1045118 net.ipv6.conf.em1.accept_ra = 0 How do you expect that to work? NetworkManager is supposed to adjust the kernel parameters to something that works. I, the dumb user, am just supposed to click on buttons. If I disable NetworkManager and just do it manually, everything works. It's not the kernel that's broken, obviously. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: 'Upgrading' NAT64 to 464XLAT?
Le 2013-11-25 08:20, Dick Visser a écrit : I'd like to 'upgrade' out existing NAT64/DNS64 setup to do 464XLAT, but there aren't many docs about how to set 464XLAT to begin with. FYI, our OpenBSD implementation of NAT64 also does NAT46. It's been part of regular OpenBSD releases since 5.1. But I haven't been able to make it do NAT46 on the local host: it only works on a separate gateway because the translation is done on packet input, and locally-generated packets are not evaluated against input rules, only output. Maybe with a clever arrangement of bridge/tunnel/loopback interfaces one could manage it. Anyway, it should be as simple as: NAT46: pass in inet af-to inet6 from ($wan_if) to 64:ff9b::/96 NAT64: pass in inet6 to 64::ff9b::/96 af-to inet from ($wan_if) That effectively gives you 464XLAT with the CLAT sitting on the IPv4 LAN's gateway. I haven't tried our Linux implementation, but just from looking at the code it seems like it should work even on the local host. If anyone wants to investigate any of this, let me know! Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: interesting about OSX, NAT64 prefix discovery
Le 2013-10-14 08:30, Mikael Abrahamsson a écrit : 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. Did they implement the NAT64 prefix discovery heuristic? That would be great! http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-17 I don't have OS X available to me right now so I can't verify... Simon
