Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - kasperd

Pages: [1] 2 3
1
IPv6 Basics & Questions & General Chatter / 6in6 tunnel broker
« on: February 16, 2014, 02:34:06 AM »
Could anybody tell me, if there is a 6in6 tunnel broker around. I have found that for a laptop 6in4 doesn't quite cut it. Not all of the networks I connect to support 6in4, and using tunnelbroker.net additionally require the IPv4 address to respond to ICMP echo requests, which further reduces the number of networks through which I can use the tunnel. During my latest trip I found the ICMP check to reject every network with protocol 41 support and accept every network without protocol 41 support.

I believe 6in6 would do much better, since on every network where 6in4 could be used, I can also use 6in6 (by running it on top of 6in4, 6to4 or Teredo if need be). Plus there could be networks on which I can use 6in6, but I could not get 6in4 working.

2
Questions & Answers / Using an Update Key
« on: February 02, 2014, 05:17:56 AM »
After reading this announcement, I decided it was a good idea to switch to the new authentication mechanism for tunnels, as it does sound more secure than the old approach.

I did run into one problem though. I'd like to share, what I found out, in case anybody else has been having problems. It turns out, that the new update mechanism does not work, if you choose an Update Key, which is exactly 32 characters long. If instead you choose a longer or a shorter key, it does appear to work.

(Is it a coincidence that this announcement about security improvements came just after the problems on the Stockholm tunnel server appeared to have disappeared?)

3
I watched this video and wondered, should I start a blog where I debunk one piece of IPv6 misinformation each day?

4
IPv6 on Linux & BSD & Mac / DAD causes services to not come up during boot
« on: December 29, 2013, 04:45:36 AM »
I have found that on Ubuntu 12.04 LTS having a service configured to listen on a static IPv6 address is not working. I have a static IPv6 address configured on eth0, and I have services configured to listen on that IPv6 address. More often than not, services do not come up during boot.

As best I can tell, this problem is caused by duplicate address detection. When an IPv6 address is assigned to an interface, the kernel will start DAD in the background. The process, which configured the address will continue immediately. If you attempt to bind to the address while DAD is still in progress, the kernel will refuse to bind the socket to the address, the same as would have happened, if you had not configured the address on any interface.

This means that timing of DAD vs boot scripts causes the behaviour to be nondeterministic. The later a service is started, the more likely it is to work.

For now I can think of two possible workarounds. My question is, which workaround is best? Is there a better one?

I can disable DAD on eth0 through sysctl.conf
Code: [Select]
net.ipv6.conf.eth0.accept_dad=0Or I can configure the same static IPv6 address on a dummy interface, such that the kernel should find it on an interface, even if DAD is not yet complete.

5
IPv6 Basics & Questions & General Chatter / Protocols for a v4 frontend
« on: December 29, 2013, 01:43:31 AM »
I am working on a v4 frontend, which can be used by anybody who need to host a service on a machine which has a public IPv6 address but no public IPv4 address.

I wanted to hear what you guys think might be useful protocols to support on such a frontend. For now I have http and https support. I am thinking I should add SMTP and authoritative DNS support as well, though I am not sure which of those two would be most useful.

Are there any other protocols, which would be useful to support?

6
Questions & Answers / AS6939 announces bogons
« on: May 23, 2013, 01:09:18 PM »
I just noticed this warning
AS6939 announces bogons.
And now I am wondering, why does HE announce bogon prefixes?

7
Questions & Answers / Updating mail address
« on: March 16, 2013, 07:22:26 AM »
I tried to update the email address in my profile, but it seems to only have been updated in the forum. On tunnelbroker.net and ipv6.he.net/certification it still shows the old address. What am I missing here? Is there anything else I need to do to get the address updated in the other places?

8
Questions & Answers / How are new users supposed to pass the certification?
« on: February 08, 2013, 02:06:49 PM »
Due to an increase in email abuse, new non-BGP tunnels now have SMTP blocked by default.  If you are a Sage, you can re-enable SMTP by visiting the tunnel details page for that specific tunnel and selecting the 'Unblock SMTP' option under the Advanced tab.
Since reaching sage level in the certification requires the ability to send and receive email over IPv6, it sounds like new users are going to run into a deadlock. Maybe you have thought about this problem already, but it isn't clear from the update what new users are really supposed to be doing.

9
If I am in a situation where I'd like to host authoritative DNS servers for some domain, but I only have public IPv6 addresses to host them on, is there any existing service, which can do translation to make the domain accessible to IPv4 only recursive resolvers?

The translation I have in mind could be completely stateless with the translator embedding the IPv4 address of the recursive resolver into an IPv6 address before passing the request unmodified to an IPv6 only authoritative DNS server.

Does such a service exist already?

10
IPv6 Basics & Questions & General Chatter / VPS with routed IPv6 prefix
« on: December 10, 2012, 03:28:00 AM »
I am wondering if anybody here can recommend a VPS provider who provides a routed IPv6 prefix (/62 or shorter), preferably cheap and hosted in Europe. The provider I am currently using only provides a /64 for the link to my virtual server, and no routed prefix. Routed prefixes are only available on physical servers, which costs quite a bit more.

11
IPv6 Basics & Questions & General Chatter / Question about routing header
« on: November 13, 2012, 01:37:26 PM »
RFC 4620 states:
Quote
   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.
Is this supposed to apply even to if the router currently processing the packet isn't the node in the destination IPv6 address? I have a problem where I am sending packets with routing headers, and I know the node whose IPv6 address is in the destination field is capable of handling this routing header. But the packet never reaches the destination. I also don't see any ICMP errors indicating what happened.

Are there any routers known to silently drop packets with routing headers they don't understand, even when they are not the destination of the packet, and were just supposed to forward it?

12
Questions & Answers / bgp.he.net lacking 32-bit ASN support
« on: October 27, 2012, 03:15:57 AM »
I came across AS23456 when browsing through peerings on bgp.he.net. I interpret this as bgp.he.net lacking support for 32-bit ASNs. Is that interpretation correct?

13
I started wondering about how 6to4 deals with certain MTU issues. In particular I am wondering about this scenario:

  • 1500 bytes packet is sent from 2001:db8::1 to 2002:c000:22a::1
  • Packet arrives at 6to4 relay, which sends too-big error message back to 2001:db8::1
  • 2001:db8::1 receives error message and retransmits packet in two fragments of 1480 and 76 bytes
  • Both packets arrive at some 6to4 relay, likely the same as before.
  • 6to4 relay encapsulates both packets in IPv4 packets from 192.88.99.1 to 192.0.2.42 of 1500 and 86 bytes
  • Both IPv4 packets makes it most of the way, but link from 192.0.2.1 to 192.0.2.42 has an MTU of only 1492 bytes.
  • 192.0.2.1 sends fragmentation-needed error to 192.88.99.1 for the first packet.
  • ICMP error arrives at a different 6to4 relay, which never saw the first packet to 192.0.2.42
  • This 6to4 relay remembers that packets to 192.0.2.42 must not be larger than 1492
  • 2002:c000:22a::1 receives second fragment and discards it after timeout. (No error message is sent because first fragment is missing.)
  • 2001:db8::1 retries after a retransmission timeout.
  • Packet is received by 6to4 relay, but this relay did not see the ICMP error and sends a 1500 bytes packet again.

Can somebody explain to me, which of the parties involved in above communication is supposed to do something differently? And what exactly can they do to find the proper MTU?

14
I am considering a setup with NAT64, in which I would like to force clients to use IPv6 by making all domains be IPv6 only.

I installed bind9 and downloaded the BIND 9 Administrator Reference Manual. Finding instructions in the manual on how to setup DNS64 was easy. I managed to get DNS64 working after just a few minutes.

But in that configuration clients can still lookup A records. I'd like to configure the server such that for any domain, which has an A record, it will reply with no record.

First I tried deny-answer-addresses { 0.0.0.0/0; }. That did stop it from responding with A records. But instead of giving no record in the reply, it would give SERVFAIL. Even worse, it also broke DNS64. It appears it filters the responses it gets from authoritative servers and not the replies it sends to clients. So even though the reply would be permitted after conversion, it is not send because it is invalid before conversion.

Next I looked at Response Policy Zone Rewriting. But the format appears to only allow me to specify one policy per domain and not per record type.

Is there a better solution than setting up two instances where the first does DNS64, and the second uses the first as forwarder and uses deny-answer-addresses?

15
IPv6 on Windows / Using IPv6 by default with Teredo
« on: September 04, 2012, 02:58:40 AM »
I have a Teredo server with some extra features. It works fine with Ubuntu clients, but is a bit problematic with Windows. So far none of my users have managed to get any browser under Windows to do AAAA lookups while using Teredo.

I have done a few searches on Google and pointed the users to pages mentioning an AddrConfigControl setting, that supposedly works. But nobody got it working yet. Did that setting only apply to some Windows versions, or is it supposed to still be working on the newest Windows versions?

Also, is there a way to get a browser under Windows to prefer IPv6 over IPv4 even when it is connected using Teredo? I am aware of the reliability implications of such a configuration, and I'll be sure to mention that to users wanting to test it.

Pages: [1] 2 3