Congratulations!

[Valid Atom 1.0] This is a valid Atom 1.0 feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

Source: https://www.sixxs.net/forum/atom/?setup

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <!-- ATOM generated by SixXS (https://www.sixxs.net) on -->
  3. <feed xmlns="http://www.w3.org/2005/Atom">
  4. <id>tag:forum.sixxs.net,2001:atom</id>
  5. <title>SixXS Forum - setup</title>
  6. <subtitle>SixXS Forum (ATOM 1.0)</subtitle>
  7. <link rel="self" type="application/atom+xml" href="https://www.sixxs.net/forum/atom/setup.atom" />
  8. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/" />
  9. <updated>2017-06-05T18:00:00-00:00</updated>
  10. <author>
  11. <name>SixXS Forum</name>
  12. <email>info@sixxs.net</email>
  13. </author>
  14. <entry>
  15. <title>How can I see raw AYIYA traffic at the IPv4 layer?</title>
  16. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-16027557-16057225&amp;from=atom" />
  17. <id>tag:forum.sixxs.net,2017-05-09:setup.16027557.16057225</id>
  18. <published>2017-05-09T12:05:30-00:00</published>
  19. <updated>2017-05-09T12:05:30-00:00</updated>
  20. <author><name>Pim  Zandbergen</name><email>PZ1453-RIPE@whois.sixxs.net</email></author>
  21. <content type="html">
  22. For the record:
  23.  
  24. It appears all the problems I was seeing with 6in4 tunnels are related to protocol 41 packets being throttled (Ziggo NL) or dropped (Vodafone NL).
  25.  
  26. My solution was to get myself a VPS, use that as the endpoint for the 6in4 tunnel, and tunnel the routed /48 subnet to home and work using Wireguard. Wireguard uses UDP, supports NAT and dynamic endpoints just like AYIYA and as a bonus encrypts the traffic.
  27.  
  28. That works just fine. Fast and reliable.
  29.  
  30. This will help me while waiting for native IPv6 hopefully before the end of this year.
  31.  
  32. </content>
  33. </entry>
  34. <entry>
  35. <title>How can I see raw AYIYA traffic at the IPv4 layer?</title>
  36. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-16027557-16027565-16029193-16029201-16029217-16029221&amp;from=atom" />
  37. <id>tag:forum.sixxs.net,2017-04-20:setup.16027557.16027565.16029193.16029201.16029217.16029221</id>
  38. <published>2017-04-20T13:04:11-00:00</published>
  39. <updated>2017-04-20T13:04:11-00:00</updated>
  40. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  41. <content type="html">
  42. &#60;div class=&#34;quote&#34;&#62;Oh but I have, extensively. I have negotiated native IPv6 within a year, or break an otherwise three year contract. I/they just need some more time. I need to give them (FTB Nederland) a break, they are a new small ISP that took over a fiber network previously run by Vodafone NL, which they abandoned, deemed unprofitable. FTB are about to invest more in IPv6 then they will ever earn from my contract. And they are actively helping me to find the cause of current tunneling issues&#60;/div&#62;
  43. Not too unreasonable to give them a wee bit of time in that case.
  44.  
  45. Their shortest path: setup a 6rd box and voila, all customers that want it can do IPv6.
  46. Then, the longer path: go native IPv6.
  47.  
  48. Though as it is &#38;quot;fiber&#38;quot;, it is very likely Ethernet based and thus enabling IPv6 should not be too complicated.
  49.  
  50. &#60;div class=&#34;quote&#34;&#62;Downloading 100GB over HTTP (wget to apache) stalls at around 30 GB.&#60;/div&#62;&#60;div class=&#34;quote&#34;&#62;rsync over ssh stalls almost immediately.&#60;/div&#62;
  51. A &#38;quot;stall&#38;quot; definitely sounds like a PathMTU issue.
  52.  
  53. Though, if TCP loses packets weird effects that are similar can happen though.
  54.  
  55. &#60;div class=&#34;quote&#34;&#62;... consumer cable network (300/30 mbit).&#60;/div&#62;
  56. Note that those are MAXimum speeds, they are not what you will always get, especially at peak time.
  57.  
  58. &#60;div class=&#34;quote&#34;&#62;With 6in4 it is slow to anywhere.&#60;/div&#62;
  59. Ziggo/LibertyGlobal are known to do QoS style packet prioritization. They have never admitted it publicaly but it is seen all over the place.
  60.  
  61. Also, LibertyGlobal has a nasty peering policy, which means that the transit port you are going over might just be full and they are not bothering to upgrade it, instead letting the remote ISP pay for buying transit from them. That is what you get with monopoly companies unfortunately.
  62.  
  63. &#60;div class=&#34;quote&#34;&#62;5  bol.macroscoop.nl (80.69.71.122)  22.208 ms !X  24.885 ms !X  24.623 ms !X&#60;/div&#62;
  64. Note that traceroutes are one-way, you do not see the return path with them which might take a completely different route.
  65.  
  66. But as there is an !X there, it also shows that some kind of packet filtering is happening, which can also cause problems for tunnels.
  67.  
  68. &#60;div class=&#34;quote&#34;&#62;We both are suspecting a change in the Vodafone infrastructure between FTB and AMS-IX.&#60;/div&#62;
  69. AMS-IX only provides a switch. But those ports on the switch might be 'full'. That can happen on both sides of the link though. That said, IX'es should not be used for transit, that is what private peering is for.
  70.  
  71. &#60;div class=&#34;quote&#34;&#62;I particularly suspect the hop with the private IPv4 address. Would that hop be able to send an ICMP message?&#60;/div&#62;
  72. Obvious it is sending a ICMP (most traceroute implementions use that method) or another packet type. Nevertheless that packet is being sourced from a RFC1918 address and being returned without issues to your host. RFC1918 should never exist on the public Internet.
  73.  
  74. Which shows that the networks you are on are susceptible to spoofing.
  75.  
  76. Time to teach your ISP some &#60;a href=&#34;https://www.routingmanifesto.org/manrs/&#34;&#62;MANRS&#60;/a&#62;!
  77.  
  78. Note that that indeed can cause all kind of weird issues, as packets originating from such a host will be dropped by properly configured networks.
  79.  
  80. &#60;div class=&#34;quote&#34;&#62;it would be sufficient that _my_ endpoints handle ICMPv6 PTB.&#60;/div&#62;
  81. No. Because that is just the first hop of a traceroute. All nodes between the source and destination need to properly support ICMPv6 PTB, and the rest of the IPv6 Node Requirements (there are quite a few more).
  82.  
  83. But you are forgetting that if a too-large IPv4 packet is send that the IPv4 network might silently drop that packet too. IPv4 might fragment, but maybe the node that is uncompliant does not properly do that, the fun with unknown nodes.
  84.  
  85. </content>
  86. </entry>
  87. <entry>
  88. <title>How can I see raw AYIYA traffic at the IPv4 layer?</title>
  89. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-16027557-16027565-16029193-16029201&amp;from=atom" />
  90. <id>tag:forum.sixxs.net,2017-04-20:setup.16027557.16027565.16029193.16029201</id>
  91. <published>2017-04-20T11:04:46-00:00</published>
  92. <updated>2017-04-20T11:04:46-00:00</updated>
  93. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  94. <content type="html">
  95. &#60;div class=&#34;quote&#34;&#62;In case you have not guessed, this is about migrating tunnels away from SixXS to other tunnelbrokers.&#60;/div&#62;
  96. Instead of asking your ISP for Native IPv6.... or moving to an ISP that does provide what you actually want.
  97.  
  98. &#60;div class=&#34;quote&#34;&#62;... suddenly is showing stalled transfers when loads are high&#60;/div&#62;
  99. You state &#38;quot;load&#38;quot;, what do you mean with &#38;quot;load&#38;quot;?
  100.  
  101. &#60;div class=&#34;quote&#34;&#62;Another tunnel that used to run AYIYA to SixXS is now runs at 10% of the IPv4 speed using 6in4 to elsewhere.&#60;/div&#62;
  102. From where to where? See the &#60;a href=&#34;https://www.sixxs.net/faq/connectivity/?faq=slow&#34;&#62;FAQ: The tunnel is slow&#60;/a&#62; which mostly also applies to any other tunnel in the world...
  103.  
  104. &#60;div class=&#34;quote&#34;&#62;I can replicate the problems I see over a 6in4 tunnel to a colocation Linux server under my control&#60;/div&#62;
  105. That partially only excludes the common path, but that might just be an indicator. Remember that your source node is still the same. There are CPEs which have issues with non-TCP/UDP packets for instance.
  106.  
  107. &#60;div class=&#34;quote&#34;&#62;In the case of the &#38;quot;stalled&#38;quot; network, I guess AYIYA is less prone to MTU and fragmentation issues&#60;/div&#62;
  108. AYIYA does nothing magical for fragmentation. Just a correctly configured MTU and properly configured endpoints that do proper ICMPv6 PTB sending, nothing else.
  109.  
  110. You will &#38;quot;just&#38;quot; (as it is far from that easy) need to verify if your setup is correct and that the nodes you are talking to properly handle ICMPv6 PTB.
  111.  
  112. &#60;div class=&#34;quote&#34;&#62;The (business oriented) ISP for the &#38;quot;stalled&#38;quot; network has promised me native IPv6 within a year, but not before 6-6-2017.&#60;/div&#62;
  113. Did you ask them what they have been doing for the last 20 years? IPv6 is very old by now....
  114.  
  115. &#60;div class=&#34;quote&#34;&#62;The ISP for the &#38;quot;slow&#38;quot; network offers me either DS Lite or an expensive upgrade from a consumer to a business subscription. I guess I will have to opt for one of them. Or prove and complain that they are not net-neutral.&#60;/div&#62;
  116. Sounds like the standard monopoly that is plaguing most of Europe, better to complain to your government for unfair business practices.
  117.  
  118. </content>
  119. </entry>
  120. <entry>
  121. <title>How can I see raw AYIYA traffic at the IPv4 layer?</title>
  122. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-16027557-16027565-16029193&amp;from=atom" />
  123. <id>tag:forum.sixxs.net,2017-04-20:setup.16027557.16027565.16029193</id>
  124. <published>2017-04-20T10:04:27-00:00</published>
  125. <updated>2017-04-20T10:04:27-00:00</updated>
  126. <author><name>Pim  Zandbergen</name><email>PZ1453-RIPE@whois.sixxs.net</email></author>
  127. <content type="html">
  128. Jeroen Massar wrote:
  129. &#60;div class=&#34;quote&#34;&#62;Dump the correct interface: the IPv4 interface, not the tunnel.
  130. [...]
  131. Wireshark has an AYIYA dissector, and thus will show you Ethernet -&#38;gt; IPv4 -&#38;gt; UDP -&#38;gt; AYIYA -&#38;gt; IPv6.
  132. &#60;/div&#62;
  133. Wireshark always dissects AYIYA and IPv6, regardless of the interface. Searching for &#38;quot;disable dissector&#38;quot; helped, I needed to disable IPv6 and/or AYIYA in &#38;quot;enabled protocols&#38;quot;.
  134.  
  135. &#60;div class=&#34;quote&#34;&#62;&#38;quot;slowness, stalled traffic&#38;quot; can be caused by many many factors. Though, most very likely, due to the latter &#38;quot;stalled&#38;quot; part: you are having MTU issues. See the FAQ for more details.
  136. &#60;/div&#62;
  137.  
  138. In case you have not guessed, this is about migrating tunnels away from SixXS to other tunnelbrokers. One tunnel that used to work fine as a static 6in4 tunnel, first at SixXS, later elsewhere (also fine), suddenly is showing stalled transfers when loads are high. Another tunnel that used to run AYIYA to SixXS is now runs at 10% of the IPv4 speed using 6in4 to elsewhere.
  139.  
  140. For both networks, I can replicate the problems I see over a 6in4 tunnel to a colocation Linux server under my control, using private IPv6 tunnel addresses. So the other tunnelbroker is not to blame. But notably, for both these IPv4 networks, an AYIYA tunnel works just fine, fast and reliable.
  141.  
  142. In the case of the &#38;quot;stalled&#38;quot; network, I guess AYIYA is less prone to MTU and fragmentation issues. For the &#38;quot;slow&#38;quot; network, it could be the ISP is throttling proto 41 but not AYIYA's UDP.
  143.  
  144. The (business oriented) ISP for the &#38;quot;stalled&#38;quot; network has promised me native IPv6 within a year, but not before 6-6-2017. They are willing to help me with my current tunneling issues, though, but do not appear to be able to find the cause. Tracepath and ping tests (with DF bit and large packet sizes) do not show problems. I will need to dig deep.
  145.  
  146. The ISP for the &#38;quot;slow&#38;quot; network offers me either DS Lite or an expensive upgrade from a consumer to a business subscription. I guess I will have to opt for one of them. Or prove and complain that they are not net-neutral.
  147.  
  148. </content>
  149. </entry>
  150. <entry>
  151. <title>How can I see raw AYIYA traffic at the IPv4 layer?</title>
  152. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-16027557-16027565&amp;from=atom" />
  153. <id>tag:forum.sixxs.net,2017-04-19:setup.16027557.16027565</id>
  154. <published>2017-04-19T16:04:18-00:00</published>
  155. <updated>2017-04-19T16:04:18-00:00</updated>
  156. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  157. <content type="html">
  158. &#60;div class=&#34;quote&#34;&#62;Wireshark always seems to show the IPv6 payload.&#60;/div&#62;
  159. Dump the correct interface: the IPv4 interface, not the tunnel.
  160.  
  161. &#60;div class=&#34;quote&#34;&#62;I'd like to see exactly how AYIYA is encapsulating the payload, so I may figure out why I am seeing problems with 6in4 (slowness, stalled traffic) not present with AYIYA.&#60;/div&#62;
  162. Wireshark has an AYIYA dissector, and thus will show you Ethernet -&#38;gt; IPv4 -&#38;gt; UDP -&#38;gt; AYIYA -&#38;gt; IPv6.
  163.  
  164. &#38;quot;slowness, stalled traffic&#38;quot; can be caused by many many factors. Though, most very likely, due to the latter &#38;quot;stalled&#38;quot; part: you are having MTU issues. See the FAQ for more details.
  165.  
  166. </content>
  167. </entry>
  168. <entry>
  169. <title>How can I see raw AYIYA traffic at the IPv4 layer?</title>
  170. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-16027557&amp;from=atom" />
  171. <id>tag:forum.sixxs.net,2017-04-19:setup.16027557</id>
  172. <published>2017-04-19T16:04:22-00:00</published>
  173. <updated>2017-04-19T16:04:22-00:00</updated>
  174. <author><name>Pim  Zandbergen</name><email>PZ1453-RIPE@whois.sixxs.net</email></author>
  175. <content type="html">
  176. How can use Wireshark or other tools to see what AYIYA is doing over my IPv4 connection? Wireshark always seems to show the IPv6 payload.
  177.  
  178. I'd like to see exactly how AYIYA is encapsulating the payload, so I may figure out why I am seeing problems with 6in4 (slowness, stalled traffic) not present with AYIYA.
  179.  
  180. </content>
  181. </entry>
  182. <entry>
  183. <title>Debugging MTU on &quot;native&quot; 6rd / OpenWRT [Sunset]</title>
  184. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-16027437-16027477&amp;from=atom" />
  185. <id>tag:forum.sixxs.net,2017-04-19:setup.16027437.16027477</id>
  186. <published>2017-04-19T09:04:48-00:00</published>
  187. <updated>2017-04-19T09:04:48-00:00</updated>
  188. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  189. <content type="html">
  190. &#60;div class=&#34;quote&#34;&#62;Since aiccu handled MTU issues rather well, there hasn't really been any need for me to read ipv6 tcpdumps concerning MTU issues.&#60;/div&#62;
  191. aiccu has no special handling of MTU. It just configures the default of 1280 (or what is configured in the webinterface) on both sides of the tunnel.
  192.  
  193. The PoP properly sends back ICMPv6 Packet Too Big if an inbound packet does not fit, and so does the client end. That is thus simply a case of a properly configured network and a stack that properly sends out and handles ICMPv6 PTBs.
  194.  
  195. &#60;div class=&#34;quote&#34;&#62;Any hints on how to interpret the following dump?&#60;/div&#62;&#60;div class=&#34;quote&#34;&#62;AFAIK ayiya and pinger1 should handle things correctly.&#60;/div&#62;&#60;div class=&#34;quote&#34;&#62;Earlier the same openwrt box used aiccu with static tunnel / mtu 1480 without issues,&#60;/div&#62;&#60;div class=&#34;quote&#34;&#62;but with 6rd it appears to get that default/minimum mtu from somewhere?&#60;/div&#62;
  196. It seems you might be configuring multiple address spaces on a host with multiple default routes etc. Do note that you need to have proper source selection for that to properly work.
  197.  
  198.  
  199. You need to ask the operator of the tunneling service what their MTU is configured to.
  200.  
  201. There is no guessing there.
  202.  
  203.  
  204. Noting though that the MTU here is only the link MTU. The moment you go a hop further the MTU might be bigger or smaller (if not the minimum of 1280 already).
  205.  
  206. Also note that there are a bunch of &#38;quot;hosts&#38;quot;, especially CDNs like used by Google that are actually loadbalanced IPs that do not properly handle ICMPv6 Packet Too Big and fake things (Google for instance just fakes the TCP MSS, which indeed means that large packets in UDP do not work, which is fun with QUIC which is UDP based; oh and on top of that QUIC does not support non-1500 MTU sizes.... great &#38;quot;protocol&#38;quot; yes they have been made aware, no they do not care...)
  207.  
  208. Hence, when you are testing test against know hosts, otherwise you might be debugging the unknown which is not useful.
  209.  
  210.  
  211. Also read up on &#60;a href=&#34;https://blog.cloudflare.com/path-mtu-discovery-in-practice/&#34;&#62;CloudFlare's Path MTU discovery in practice&#60;/a&#62; for some more details.
  212.  
  213. </content>
  214. </entry>
  215. <entry>
  216. <title>Debugging MTU on &quot;native&quot; 6rd / OpenWRT [Sunset]</title>
  217. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-16027437&amp;from=atom" />
  218. <id>tag:forum.sixxs.net,2017-04-19:setup.16027437</id>
  219. <published>2017-04-19T07:04:52-00:00</published>
  220. <updated>2017-04-19T07:04:52-00:00</updated>
  221. <author><name>Tuomas Heino</name><email>TH28-6BONE@whois.sixxs.net</email></author>
  222. <content type="html">
  223. Since aiccu handled MTU issues rather well, there hasn't really been any need for me to read ipv6 tcpdumps concerning MTU issues.
  224.  
  225. Any hints on how to interpret the following dump?
  226. AFAIK ayiya and pinger1 should handle things correctly.
  227. Earlier the same openwrt box used aiccu with static tunnel / mtu 1480 without issues,
  228. but with 6rd it appears to get that default/minimum mtu from somewhere?
  229.  
  230. openwrt 2001:db8:f:b00::1/56, 2001:db8:f:bc0::1/64 6rd
  231. landest 2001:db8:f:bc0::33/64
  232. ayiya 2001:db8:5:71::1/48
  233. pinger1 2001:db8:5:59::1/64, 2001:db8:5:71::21/64
  234.  
  235. $ ping6 -c 1 -M do -s 1380 2001:db8:f:bc0::33
  236. PING 2001:db8:f:bc0::33(2001:db8:f:bc0::33) 1380 data bytes
  237. From 2001:db8:f:b00::1 icmp_seq=1 Packet too big: mtu=1280
  238.  
  239. --- 2001:db8:f:bc0::33 ping statistics ---
  240. 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
  241.  
  242. $ ping6 -M do -s 1380 2001:db8:5:71::1
  243. PING 2001:db8:5:71::1(2001:db8:5:71::1) 1380 data bytes
  244. 1388 bytes from 2001:db8:5:71::1: icmp_seq=2 ttl=54 time=176 ms
  245. 1388 bytes from 2001:db8:5:71::1: icmp_seq=3 ttl=54 time=164 ms
  246. ^C
  247. --- 2001:db8:185:5d71::1 ping statistics ---
  248. 3 packets transmitted, 2 received, 33% packet loss, time 2008ms
  249. rtt min/avg/max/mdev = 164.182/170.336/176.490/6.154 ms
  250.  
  251. root@OpenWrt:~# tcpdump -nettti 6rd-rd6 icmp6
  252. tcpdump: WARNING: 6rd-rd6: no IPv4 address assigned
  253. tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  254. listening on 6rd-rd6, link-type RAW (Raw IP), capture size 65535 bytes
  255. 00:00:00.000000 ip: 2001:db8:5:59::1 &#38;gt; 2001:db8:f:bc0::33: ICMP6, echo request, seq 1, length 1388
  256. 00:00:48.433027 ip: 2001:db8:f:bc0::33 &#38;gt; 2001:db8:5:71::1: ICMP6, echo request, seq 1, length 1388
  257. 00:00:00.252362 ip: 2001:db8:5:71::1 &#38;gt; 2001:db8:f:bc0::33: ICMP6, echo reply, seq 1, length 1388
  258. 00:00:00.000247 ip: 2001:db8:f:b00::1 &#38;gt; 2001:db8:5:71::1: ICMP6, packet too big, mtu 1280, length 1240
  259. 00:00:00.755739 ip: 2001:db8:f:bc0::33 &#38;gt; 2001:db8:5:71::1: ICMP6, echo request, seq 2, length 1388
  260. 00:00:00.174998 ip: 2001:db8:5:71::1 &#38;gt; 2001:db8:f:bc0::33: frag (0|1232) ICMP6, echo reply, seq 2, length 1232
  261. 00:00:00.001118 ip: 2001:db8:5:71::1 &#38;gt; 2001:db8:f:bc0::33: frag (1232|156)
  262. 00:00:00.824260 ip: 2001:db8:f:bc0::33 &#38;gt; 2001:db8:5:71::1: ICMP6, echo request, seq 3, length 1388
  263. 00:00:00.162697 ip: 2001:db8:5:71::1 &#38;gt; 2001:db8:f:bc0::33: frag (0|1232) ICMP6, echo reply, seq 3, length 1232
  264. 00:00:00.001141 ip: 2001:db8:5:71::1 &#38;gt; 2001:db8:f:bc0::33: frag (1232|156)
  265.  
  266. </content>
  267. </entry>
  268. <entry>
  269. <title>Multiple IPv6 static addresses on one interface?</title>
  270. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15922681-15922693&amp;from=atom" />
  271. <id>tag:forum.sixxs.net,2017-02-23:setup.15922681.15922693</id>
  272. <published>2017-02-23T17:02:42-00:00</published>
  273. <updated>2017-02-23T17:02:42-00:00</updated>
  274. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  275. <content type="html">
  276. You might want to read &#60;a href=&#34;https://wiki.debian.org/NetworkConfiguration&#34;&#62;Debian interfaces&#60;/a&#62; see the bottom section for the details.
  277.  
  278. In summary, just add multiple 'interface' sections with static addresses and skip the gateway definition.
  279.  
  280. Typically defining them as /128 is a good idea btw even though the real interface is a /64.
  281.  
  282. Note that you will run into a lot of fun with outbound addresses, as a random one more or less is chosen... (depends typically on the order of add and/or on the deprecate flag if code is good).
  283.  
  284. </content>
  285. </entry>
  286. <entry>
  287. <title>Multiple IPv6 static addresses on one interface?</title>
  288. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15922681&amp;from=atom" />
  289. <id>tag:forum.sixxs.net,2017-02-23:setup.15922681</id>
  290. <published>2017-02-23T16:02:39-00:00</published>
  291. <updated>2017-02-23T16:02:39-00:00</updated>
  292. <author><name>Andre-John Mas</name><email>AME4-SIXXS@whois.sixxs.net</email></author>
  293. <content type="html">
  294. On a Linux based host how can I assign multiple IPv6 addresses to one interface? I had tried adding two 'address' lines under an interface in the /etc/network/interfaces file, but that did not seem to work. Any ideas?
  295.  
  296. </content>
  297. </entry>
  298. <entry>
  299. <title>Find where packet is dropped</title>
  300. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15908505-15908513&amp;from=atom" />
  301. <id>tag:forum.sixxs.net,2017-02-16:setup.15908505.15908513</id>
  302. <published>2017-02-16T10:02:27-00:00</published>
  303. <updated>2017-02-16T10:02:27-00:00</updated>
  304. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  305. <content type="html">
  306. &#60;div class=&#34;quote&#34;&#62;When I route to the 4G, nothing comes back&#60;/div&#62;
  307. Quite likely they filter certain ports.
  308.  
  309. Call Your ISP...
  310.  
  311. Or try one of the many &#38;quot;Am I being filtered&#38;quot; kind of websites that are out there.
  312.  
  313. </content>
  314. </entry>
  315. <entry>
  316. <title>Find where packet is dropped</title>
  317. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15908505&amp;from=atom" />
  318. <id>tag:forum.sixxs.net,2017-02-16:setup.15908505</id>
  319. <published>2017-02-16T10:02:49-00:00</published>
  320. <updated>2017-02-16T10:02:49-00:00</updated>
  321. <author><name>Leif Neland</name><email>LNR4-SIXXS@whois.sixxs.net</email></author>
  322. <content type="html">
  323. &#60;b&#62;Is my router or my ISP dropping packets to/from POP?&#60;/b&#62;
  324.  
  325. I have a 4G router and a ADSL-router, the latter only 1Mb/s
  326.  
  327. When I route to the pop over ADSL, the connection works fine
  328.  
  329. &#60;code&#62;10:36:53.881855 IP 192.168.1.254.44928 &#38;gt; dkcph01.sixxs.net.5072: UDP, length 104
  330. 10:36:53.927412 IP dkcph01.sixxs.net.5072 &#38;gt; 192.168.1.254.44928: UDP, length 104
  331.  
  332. traceroute to dkcph01.sixxs.net (93.158.77.42), 30 hops max, 60 byte packets
  333. 1  192.168.1.3 (192.168.1.3)  17.898 ms  17.604 ms  17.264 ms  &#38;lt;- MY ADSL ROUTER
  334. 2  xe-2-1-1-1103.ronnqe10.dk.ip.tdc.net (87.58.0.130)  30.039 ms  34.716 ms  42.157 ms
  335. 3  xe-1-0-0-0.bgt-peer1.mmx.se.ip.tdc.net (88.131.143.115)  49.252 ms  55.641 ms  60.560 ms
  336. 4  netnod-ix-ge-b-mmo-1500.ip-only.net (195.69.117.92)  68.463 ms  73.828 ms  79.806 ms
  337. 5  83.145.2.46 (83.145.2.46)  119.284 ms  113.858 ms  114.203 ms
  338. 6  212.112.188.66 (212.112.188.66)  103.168 ms  46.887 ms  31.330 ms
  339. 7  83.140.255.70 (83.140.255.70)  44.473 ms  50.255 ms *
  340. 8  dkcph01.sixxs.net (93.158.77.42)  56.382 ms  62.972 ms  68.178 ms
  341.  
  342. &#60;/code&#62;
  343.  
  344. When I route to the 4G, nothing comes back
  345.  
  346. &#60;code&#62;10:41:54.166050 IP 192.168.1.254.44928 &#38;gt; dkcph01.sixxs.net.5072: UDP, length 105
  347. 10:41:57.861203 IP 192.168.1.254.44928 &#38;gt; dkcph01.sixxs.net.5072: UDP, length 105
  348. 10:41:58.443125 IP 192.168.1.254.44928 &#38;gt; dkcph01.sixxs.net.5072: UDP, length 105
  349.  
  350. traceroute to dkcph01.sixxs.net (93.158.77.42), 30 hops max, 60 byte packets
  351. 1  192.168.1.1 (192.168.1.1)  1.431 ms  0.832 ms  1.402 ms &#38;lt;- MY 4G ROUTER
  352. 2  192.168.225.1 (192.168.225.1)  1.099 ms  1.391 ms  1.778 ms
  353. 3  62.44.164.245 (62.44.164.245)  31.055 ms  31.322 ms  31.740 ms
  354. 4  62.44.166.184 (62.44.166.184)  30.979 ms  30.626 ms  30.724 ms
  355. 5  212.97.200.65 (212.97.200.65)  31.132 ms  31.472 ms  30.727 ms
  356. 6  kbn-b3-link.telia.net (80.239.132.1)  33.178 ms  19.937 ms  20.330 ms
  357. 7  iponly-ic-319310-kbn-b3.c.telia.net (62.115.151.47)  24.211 ms  20.568 ms  21.012 ms
  358. 8  213.80.86.252 (213.80.86.252)  33.367 ms  21.022 ms  31.120 ms
  359. 9  83.145.2.46 (83.145.2.46)  55.067 ms  58.371 ms  57.875 ms
  360. 10  212.112.188.66 (212.112.188.66)  31.118 ms  31.405 ms  32.348 ms
  361. 11  83.140.255.70 (83.140.255.70)  34.017 ms  33.506 ms  32.858 ms
  362. 12  dkcph01.sixxs.net (93.158.77.42)  28.164 ms  30.134 ms  29.727 ms
  363.  
  364. &#60;/code&#62;
  365.  
  366. Where do I find what is dropping the packets; my router or my 4G provider, Telia.dk?
  367. (&#60;i&#62;Which does not yet run IPv6 on 4G; I have asked repeatedly&#60;/i&#62;)
  368.  
  369. The router is a TP-Link Archer MR200
  370.  
  371. I can ping the pop nicely:
  372. &#60;code&#62;10:47:19.760772 IP 192.168.1.254 &#38;gt; dkcph01.sixxs.net: ICMP echo request, id 8775, seq 1, length 64
  373. 10:47:19.787280 IP dkcph01.sixxs.net &#38;gt; 192.168.1.254: ICMP echo reply, id 8775, seq 1, length 64
  374. &#60;/code&#62;
  375.  
  376. Can the tunnel be set to use other ports or protocols?
  377.  
  378. I have a VPS (at OVH France I think) with true ipv6-connectivity, I could use to debug the connection, if I knew what to look for.
  379.  
  380. I have tried to get a /64 routed to the VPS, so I could VPN this network to my home network, but this is not yet possible.
  381. Is it possible to NAT all my machines at home through a single IPv6 address at the VPS?
  382. I'd rather not, as defeats the purpose of having some home automation Raspberry's reachable from outside over separate ipv6-addresses.
  383.  
  384. </content>
  385. </entry>
  386. <entry>
  387. <title>ping6 -  Time exceeded: Hop limit</title>
  388. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15904569-15904573-15906505-15906561&amp;from=atom" />
  389. <id>tag:forum.sixxs.net,2017-02-15:setup.15904569.15904573.15906505.15906561</id>
  390. <published>2017-02-15T06:02:13-00:00</published>
  391. <updated>2017-02-15T06:02:13-00:00</updated>
  392. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  393. <content type="html">
  394. &#60;div class=&#34;quote&#34;&#62;Playing around indicates the issue only happens if wlan0 is up.&#60;/div&#62;
  395. Check 'ip -6 ro show' likely you see that your Wireless is bridged to your Ethernet.
  396.  
  397. Hence, eth0 on your device, announces connectivity to wlan0 through your Access Point which bridges Ethernet and Wireless.
  398.  
  399. Thus, bringing up eth0 and wlan0 at the same time is a bad idea in this configuration unless you apply a lot of extra configuration.
  400.  
  401. &#60;div class=&#34;quote&#34;&#62;While only impacting radvd and not the base connectivity I also noticed that 2001:4978:15d:feed::1 wasn't being assigned and instead I needed to do this manually:&#60;/div&#62;&#60;div class=&#34;quote&#34;&#62;&#60;/div&#62;&#60;div class=&#34;quote&#34;&#62;&#60;code&#62;sudo /sbin/ip -6 addr add 2001:4978:15d:feed::1/64 dev eth0&#60;/code&#62;&#60;/div&#62;
  402. That is because forwarding is enabled on the interface, you should put that in /etc/network/interfaces.
  403.  
  404. Also, you might be missing a 'auto eth0' line there.
  405.  
  406. Instead of 'pre-up modprobe ipv6' stuff that in /etc/modules and it will load way before your networking comes up. That might resolve it too.
  407.  
  408. Running a Debian based image will resolve all that, as they got IPv6 built in per default for a long long time already.
  409.  
  410. </content>
  411. </entry>
  412. <entry>
  413. <title>ping6 -  Time exceeded: Hop limit</title>
  414. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15904569-15904573-15906505&amp;from=atom" />
  415. <id>tag:forum.sixxs.net,2017-02-15:setup.15904569.15904573.15906505</id>
  416. <published>2017-02-15T04:02:23-00:00</published>
  417. <updated>2017-02-15T04:02:23-00:00</updated>
  418. <author><name>Andre-John Mas</name><email>AME4-SIXXS@whois.sixxs.net</email></author>
  419. <content type="html">
  420. The Raspberry Pi is a model 3 and both eth0 and wlan0 are connected to the local network.
  421.  
  422. Output of uname:
  423.  
  424. &#60;code&#62;Linux balsa 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l GNU/Linux&#60;/code&#62;
  425.  
  426. Playing around indicates the issue only happens if wlan0 is up.
  427.  
  428. When both interfaces are up:
  429.  
  430. &#60;code&#62;eth0      Link encap:Ethernet  HWaddr b8:27:eb:40:7e:e5  
  431.          inet addr:192.168.2.28  Bcast:192.168.2.255  Mask:255.255.255.0
  432.          inet6 addr: 2001:4978:15d:feed::1/64 Scope:Global
  433.          inet6 addr: fe80::57d6:1d7:8c17:6b2b/64 Scope:Link
  434.          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  435.          RX packets:65719 errors:0 dropped:1 overruns:0 frame:0
  436.          TX packets:46200 errors:0 dropped:0 overruns:0 carrier:0
  437.          collisions:0 txqueuelen:1000
  438.          RX bytes:50720760 (48.3 MiB)  TX bytes:45893098 (43.7 MiB)
  439.  
  440. lo        Link encap:Local Loopback  
  441.          inet addr:127.0.0.1  Mask:255.0.0.0
  442.          inet6 addr: ::1/128 Scope:Host
  443.          UP LOOPBACK RUNNING  MTU:65536  Metric:1
  444.          RX packets:204 errors:0 dropped:0 overruns:0 frame:0
  445.          TX packets:204 errors:0 dropped:0 overruns:0 carrier:0
  446.          collisions:0 txqueuelen:1
  447.          RX bytes:17264 (16.8 KiB)  TX bytes:17264 (16.8 KiB)
  448.  
  449. sit0      Link encap:IPv6-in-IPv4  
  450.          NOARP  MTU:1480  Metric:1
  451.          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  452.          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  453.          collisions:0 txqueuelen:1
  454.          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  455.  
  456. sixxs     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  457.          inet6 addr: fe80::4878:f:48:2/64 Scope:Link
  458.          inet6 addr: 2001:4978:f:48::2/64 Scope:Global
  459.          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1280  Metric:1
  460.          RX packets:34810 errors:0 dropped:0 overruns:0 frame:0
  461.          TX packets:10494 errors:0 dropped:0 overruns:0 carrier:0
  462.          collisions:0 txqueuelen:500
  463.          RX bytes:42924095 (40.9 MiB)  TX bytes:999427 (976.0 KiB)
  464.  
  465. wlan0     Link encap:Ethernet  HWaddr b8:27:eb:15:2b:b0  
  466.          inet addr:192.168.2.29  Bcast:192.168.2.255  Mask:255.255.255.0
  467.          inet6 addr: fe80::e659:fc06:d4cd:230a/64 Scope:Link
  468.          inet6 addr: 2001:4978:15d:feed:d3b9:b0d3:9598:655/64 Scope:Global
  469.          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  470.          RX packets:631 errors:0 dropped:313 overruns:0 frame:0
  471.          TX packets:18082 errors:0 dropped:0 overruns:0 carrier:0
  472.          collisions:0 txqueuelen:1000
  473.          RX bytes:128977 (125.9 KiB)  TX bytes:4659397 (4.4 MiB)
  474. &#60;/code&#62;
  475.  
  476. /etc/network/interfaces:
  477.  
  478. &#60;code&#62;source-directory /etc/network/interfaces.d
  479.  
  480. auto lo
  481. iface lo inet loopback
  482.  
  483. iface eth0 inet manual
  484.  
  485. iface eth0 inet6 static
  486.   pre-up modprobe ipv6
  487.   address 2001:4978:15d:feed::1
  488.   netmask 64
  489.  
  490. allow-hotplug wlan0
  491. iface wlan0 inet manual
  492.    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
  493.  
  494. allow-hotplug wlan1
  495. iface wlan1 inet manual
  496.    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
  497.  
  498. # IPv6
  499. iface wlan0 inet6 static
  500. #   pre-up modprobe ipv6
  501. #   address 2001:4978:15d:feed::1
  502. #   netmask 64
  503. &#60;/code&#62;
  504.  
  505. While only impacting radvd and not the base connectivity I also noticed that 2001:4978:15d:feed::1 wasn't being assigned and instead I needed to do this manually:
  506.  
  507. &#60;code&#62;sudo /sbin/ip -6 addr add 2001:4978:15d:feed::1/64 dev eth0&#60;/code&#62;
  508.  
  509. </content>
  510. </entry>
  511. <entry>
  512. <title>ping6 -  Time exceeded: Hop limit</title>
  513. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15904569-15904573&amp;from=atom" />
  514. <id>tag:forum.sixxs.net,2017-02-14:setup.15904569.15904573</id>
  515. <published>2017-02-14T16:02:13-00:00</published>
  516. <updated>2017-02-14T16:02:13-00:00</updated>
  517. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  518. <content type="html">
  519. &#60;div class=&#34;quote&#34;&#62;I get a timeout. I then try a ping6 to the same address, but get:&#60;/div&#62;
  520. Instead of ping, try traceroute, it will tell you what route is being taken for those packets.
  521.  
  522. Do note that Google is a bad network to test connectivity towards as they use all kinds of tricks to make their performance the way it is (amongst others ignored ICMPv6 Packet Too Big, as their load balancers do not support it, and thus they guess TCP MSS instead, yes, UDP is SoL), thus misdiagnosis as one does not see their end is very possible.
  523.  
  524. &#60;div class=&#34;quote&#34;&#62;The settings in my /etc/aiccu.conf (masking sensitive info):&#60;/div&#62;
  525. AICCU configuration has very little to do: when the system is misconfigured before AICCU runs, it can't magically fix it.
  526.  
  527. And of course, it can't fix any routing issues either.
  528.  
  529. Hence, why there is a &#38;quot;Problems Checklist&#38;quot; on the contact page which is what the big yellow/orange boxes when posting point too.
  530.  
  531. </content>
  532. </entry>
  533. <entry>
  534. <title>ping6 -  Time exceeded: Hop limit</title>
  535. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15904569&amp;from=atom" />
  536. <id>tag:forum.sixxs.net,2017-02-14:setup.15904569</id>
  537. <published>2017-02-14T16:02:39-00:00</published>
  538. <updated>2017-02-14T16:02:39-00:00</updated>
  539. <author><name>Andre-John Mas</name><email>AME4-SIXXS@whois.sixxs.net</email></author>
  540. <content type="html">
  541. I am trying to set up my new Raspberry Pi up as my IPv6 gateway, using aiccu, but when I try a test connection via:
  542.  
  543. &#60;code&#62; telnet ipv6.google.com 443&#60;/code&#62;
  544. I get a timeout. I then try a ping6 to the same address, but get:
  545.  
  546. &#60;code&#62;$ ping6 ipv6.google.com
  547. PING ipv6.google.com(yyz08s10-in-x0e.1e100.net) 56 data bytes
  548. From yyz08s10-in-x0e.1e100.net icmp_seq=1 Time exceeded: Hop limit
  549. From yyz08s10-in-x0e.1e100.net icmp_seq=2 Time exceeded: Hop limit
  550. ^C
  551. --- ipv6.google.com ping statistics ---
  552. 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms
  553. &#60;/code&#62;
  554. I am not sure whether the issue is at my end or at the PoP side. What should I be examining?
  555.  
  556. The settings in my /etc/aiccu.conf (masking sensitive info):
  557.  
  558. &#60;code&#62;username XXXXX
  559. password XXXXX
  560. protocol tic
  561. ipv6_interface sixxs
  562. tunnel_id XXXXX
  563. verbose false
  564. daemonize true
  565. automatic true
  566. requiretls false
  567. behindnat true
  568. &#60;/code&#62;
  569. When I set daemonize false and verbose true, I see no errors in the startup sequence.
  570.  
  571. My PoP is uschi02.
  572.  
  573. </content>
  574. </entry>
  575. <entry>
  576. <title>Routing problem, once more</title>
  577. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15842189-15904277&amp;from=atom" />
  578. <id>tag:forum.sixxs.net,2017-02-14:setup.15842189.15904277</id>
  579. <published>2017-02-14T10:02:52-00:00</published>
  580. <updated>2017-02-14T10:02:52-00:00</updated>
  581. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  582. <content type="html">
  583. Risto Virtanen wrote:
  584. &#60;div class=&#34;quote&#34;&#62;eth0      Link encap:Ethernet  HWaddr 00:e0:00:5a:04:36  
  585.          inet addr:192.168.144.112  Bcast:192.168.144.255  Mask:255.255.255.0
  586.          inet6 addr: 2001:14b8:100:8345:2e0:ff:fe5a:436/64 Scope:Global
  587. &#60;/div&#62;
  588.  
  589. You might want to check with &#38;quot;ip -6 addr show&#38;quot; and &#38;quot;ip -6 ro show&#38;quot;.
  590. &#38;quot;ifconfig&#38;quot; should be avoided on Linux as much as possible btw.
  591.  
  592. You are missing a fe80::/ style address there. Though likely it is there and it is  fe80::2e0:ff:fe5a:436 that is mentioned below on the client.
  593.  
  594. &#60;div class=&#34;quote&#34;&#62;* route ipv6:
  595. 2001:14b8:100:8345::/64 dev eth0  proto kernel  metric 256  expires 86386sec
  596. fe80::/64 dev eth0  proto kernel  metric 256
  597. default via fe80::8eeb:c6ff:fec7:eb0c dev eth0  proto ra  metric 1024  expires 1508sec hoplimit 64
  598. default via fe80::2e0:ff:fe5a:436 dev eth0  proto ra  metric 1024  expires 76sec hoplimit 64
  599. &#60;/div&#62;
  600.  
  601. You have two defaults routes from two different hosts. The last one matches your host above, the other though is a magic one come elsewhere that is also advertising routes (hence 'proto ra').
  602.  
  603.  
  604. &#60;div class=&#34;quote&#34;&#62;* pinging ipv6.google.com:&#60;/div&#62;
  605. Try 'ip -6 ro get &#38;lt;address&#38;gt;' instead, that will show you where the packets are supposed to go.
  606.  
  607. Then use 'traceroute6 &#38;lt;address&#38;gt;' to see if they really go there.
  608.  
  609.  
  610. Also, do check your firewall and all other properties in the list on the contact page.
  611.  
  612. </content>
  613. </entry>
  614. <entry>
  615. <title>Own / Company pop</title>
  616. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15879345-15879349-15904109&amp;from=atom" />
  617. <id>tag:forum.sixxs.net,2017-02-14:setup.15879345.15879349.15904109</id>
  618. <published>2017-02-14T10:02:12-00:00</published>
  619. <updated>2017-02-14T10:02:12-00:00</updated>
  620. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  621. <content type="html">
  622. Leif Neland wrote:
  623. &#60;div class=&#34;quote&#34;&#62;Why is this thread marked private?
  624. &#60;/div&#62;
  625.  
  626. Because unfortunately in times when people want more than they pay for they demand in rather nasty ways, and thus all posts are screened instead of us getting indexed on Google with vulgarity.
  627.  
  628. </content>
  629. </entry>
  630. <entry>
  631. <title>Own / Company pop</title>
  632. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15879345-15904097&amp;from=atom" />
  633. <id>tag:forum.sixxs.net,2017-02-14:setup.15879345.15904097</id>
  634. <published>2017-02-14T09:02:26-00:00</published>
  635. <updated>2017-02-14T09:02:26-00:00</updated>
  636. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  637. <content type="html">
  638. Sounds like you want a VPN.
  639.  
  640. That thus has little to do with SixXS, which is a Tunnel Broker for getting global IPv6 connectivity and playing with IPv6.
  641.  
  642. </content>
  643. </entry>
  644. <entry>
  645. <title>How to re-enable?</title>
  646. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15894873-15904061&amp;from=atom" />
  647. <id>tag:forum.sixxs.net,2017-02-14:setup.15894873.15904061</id>
  648. <published>2017-02-14T09:02:35-00:00</published>
  649. <updated>2017-02-14T09:02:35-00:00</updated>
  650. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  651. <content type="html">
  652. &#60;div class=&#34;quote&#34;&#62;My tunnel detail page has the Enable button grayed out, along with the button to change the tunnel type or endpoint&#60;/div&#62;
  653. Did you Call Your ISP and ask for Native IPv6?
  654.  
  655. </content>
  656. </entry>
  657. <entry>
  658. <title>How to re-enable?</title>
  659. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15894873&amp;from=atom" />
  660. <id>tag:forum.sixxs.net,2017-02-09:setup.15894873</id>
  661. <published>2017-02-09T06:02:03-00:00</published>
  662. <updated>2017-02-09T06:02:03-00:00</updated>
  663. <author><name>Pradeep Sanders</name><email>PSI8-SIXXS@whois.sixxs.net</email></author>
  664. <content type="html">
  665. My server was down for 11 days, and I lost all my ISK since I foolishly hoped it would come up quicker than it did and thus didn't pause it.
  666.  
  667. My tunnel detail page has the Enable button grayed out, along with the button to change the tunnel type or endpoint. I've not found a way to re-enable my tunnel despite checking about 30 pages of forum posts and all the FAQs. Either I missed something, or the instructions don't reflect what I'm seeing.
  668.  
  669. How can I re-enable my tunnel now that my static address is reachable again?
  670.  
  671. Thanks,
  672.  
  673. -Pradeep
  674.  
  675. </content>
  676. </entry>
  677. <entry>
  678. <title>Own / Company pop</title>
  679. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15879345&amp;from=atom" />
  680. <id>tag:forum.sixxs.net,2017-02-01:setup.15879345</id>
  681. <published>2017-02-01T08:02:21-00:00</published>
  682. <updated>2017-02-01T08:02:21-00:00</updated>
  683. <author><name>Leif Neland</name><email>LNR4-SIXXS@whois.sixxs.net</email></author>
  684. <content type="html">
  685. Home and office does not have IPv6, but our webserver (and intranet webserver) is hosted at a site with IPv6
  686.  
  687. Because of the ease of setting up aiccu, and for not abusing a public, free PoP for business use,, I'd like to set up a PoP at our hosting site.
  688.  
  689. Servers are running Linux (of cause ;-) ); which software to use for pop?
  690.  
  691. </content>
  692. </entry>
  693. <entry>
  694. <title>aiccu on centos7</title>
  695. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15869489-15870753&amp;from=atom" />
  696. <id>tag:forum.sixxs.net,2017-01-28:setup.15869489.15870753</id>
  697. <published>2017-01-28T07:01:55-00:00</published>
  698. <updated>2017-01-28T07:01:55-00:00</updated>
  699. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  700. <content type="html">
  701. Triantafyllos Tsakidis wrote:
  702. &#60;div class=&#34;quote&#34;&#62;Hello
  703.  
  704. I found out that aiccu is not available in &#60;a href=&#34;https://dl.fedoraproject.org/pub/epel/7/x86_64/a/&#34;&#62;epel repository for Centos 7&#60;/a&#62;
  705. I also tried to download the rpm for centos 6 but it did not install on centos 7 due to missing dependencies
  706.  
  707. So currently the only way to setup a tunnel on centos7 is to use a 6in4-static tunnel?
  708. Or is there any other way to use aiccu on centos 7?
  709. &#60;/div&#62;
  710.  
  711. Contacting your ISP and asking them for Native IPv6 is a good step. It is 2017 afterall...
  712.  
  713. As for the package, contact your vendor, and one can always use the source ;)
  714.  
  715. Though, if you are trying to do tunnels now, I suggest really going for the ISP option. See the news pages for more details.
  716.  
  717. </content>
  718. </entry>
  719. <entry>
  720. <title>aiccu on centos7</title>
  721. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15869489&amp;from=atom" />
  722. <id>tag:forum.sixxs.net,2017-01-27:setup.15869489</id>
  723. <published>2017-01-27T23:01:36-00:00</published>
  724. <updated>2017-01-27T23:01:36-00:00</updated>
  725. <author><name>Triantafyllos Tsakidis</name><email>TTU3-SIXXS@whois.sixxs.net</email></author>
  726. <content type="html">
  727. Hello
  728.  
  729. I found out that aiccu is not available in &#60;a href=&#34;https://dl.fedoraproject.org/pub/epel/7/x86_64/a/&#34;&#62;epel repository for Centos 7&#60;/a&#62;
  730. I also tried to download the rpm for centos 6 but it did not install on centos 7 due to missing dependencies
  731.  
  732. So currently the only way to setup a tunnel on centos7 is to use a 6in4-static tunnel?
  733. Or is there any other way to use aiccu on centos 7?
  734.  
  735. </content>
  736. </entry>
  737. <entry>
  738. <title>Routing problem, once more</title>
  739. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15842189&amp;from=atom" />
  740. <id>tag:forum.sixxs.net,2017-01-13:setup.15842189</id>
  741. <published>2017-01-13T15:01:49-00:00</published>
  742. <updated>2017-01-13T15:01:49-00:00</updated>
  743. <author><name>Risto Virtanen</name><email>RVH9-SIXXS@whois.sixxs.net</email></author>
  744. <content type="html">
  745. Hi all,
  746. I apologize opening a new thread in spite of that the problem has been discussed in the forum several times over and over. Just didn't find an adequate response...
  747.  
  748. In my home network I have a server (an old laptop) running Debian 6.0.10 (kernel 2.6.32-5-686) and  among others  aiccu installed. The tunnel seems to work just fine and I can reach other ipv6 hosts in the internet from this server.
  749. I also have radvd installed and it seems to advertise as configured and my clients get there ipv6 addresses. But for some reason the connections from the clients to the internet do not work. I'm probably missing some really simple error in config, but anyway I'm stuck. Any hints what to do and change are appreciated!
  750.  
  751. Settings on he server:
  752. * aiccu/sixxs:
  753. Tunnel T119958 - endpoint 2001:14b8:100:345::2 - enabled
  754. Subnet R217502 - prefix 2001:14b8:100:8345::/64 - enabled
  755.  
  756. * ifconfig
  757. eth0      Link encap:Ethernet  HWaddr 00:e0:00:5a:04:36  
  758.          inet addr:192.168.144.112  Bcast:192.168.144.255  Mask:255.255.255.0
  759.          inet6 addr: 2001:14b8:100:8345:2e0:ff:fe5a:436/64 Scope:Global
  760.          inet6 addr: fe80::2e0:ff:fe5a:436/64 Scope:Link
  761.          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  762. lo        Link encap:Local Loopback  
  763.          inet addr:127.0.0.1  Mask:255.0.0.0
  764.          inet6 addr: ::1/128 Scope:Host
  765.          UP LOOPBACK RUNNING  MTU:16436  Metric:1
  766. sixxs     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  767.          inet6 addr: 2001:14b8:100:345::2/64 Scope:Global
  768.          inet6 addr: fe80::14b8:100:345:2/64 Scope:Link
  769.          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1280  Metric:1
  770. tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  771.          inet addr:10.144.112.1  P-t-P:10.144.112.2  Mask:255.255.255.255
  772.          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  773.  
  774. (I've omitted the RX/TX lines from the output; the tun0 device is for openvpn, currently not working as my ISP is not giving any public ipv4 address anymore, neither ipv6)
  775.  
  776. * route ipv4:
  777. 10.144.112.2 dev tun0  proto kernel  scope link  src 10.144.112.1
  778. 10.144.112.0/24 via 10.144.112.2 dev tun0
  779. 192.168.144.0/24 dev eth0  proto kernel  scope link  src 192.168.144.112
  780. default via 192.168.144.1 dev eth0
  781. * route ipv6:
  782. 2001:14b8:100:345::/64 dev sixxs  proto kernel  metric 256  mtu 1280 advmss 1220 hoplimit 0
  783. 2001:14b8:100:8345::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
  784. fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
  785. fe80::/64 dev sixxs  proto kernel  metric 256  mtu 1280 advmss 1220 hoplimit 0
  786. default via 2001:14b8:100:345::1 dev sixxs  metric 1024  mtu 1280 advmss 1220 hoplimit 0
  787.  
  788. * forwarding
  789. /proc/sys/net/ipv6/conf/eth0/forwarding : 1
  790.  
  791. * pinging:
  792. PING ipv6.google.com(arn09s05-in-x0e.1e100.net) 56 data bytes
  793. 64 bytes from arn09s05-in-x0e.1e100.net: icmp_seq=1 ttl=54 time=37.5 ms
  794. --- ipv6.google.com ping statistics ---
  795. 1 packets transmitted, 1 received, 0% packet loss, time 0ms
  796.  
  797. * /etc/radvd.conf:
  798. interface eth0 {
  799.      AdvSendAdvert on ;
  800.      # Advertise at least every 30 seconds
  801.      MaxRtrAdvInterval 30;
  802.      # in order to force non RFC 6106 compliant clients to get a dns address
  803.      AdvOtherConfigFlag on ;
  804.      prefix 2001:14b8:100:8345::/64 {
  805.        AdvOnLink on;#      RDNSS 2001:14b8:100:345::1  2001:14b8:100:345::2 {
  806. #      };
  807.  
  808.        AdvAutonomous on;
  809.        AdvRouterAddr on;
  810.      };
  811. };
  812.  
  813.  
  814. Settings on the client #1:
  815. * Xubuntu 14.04 with kernel 3.13.0-107-generic
  816. * no manual configuration done for ipv6
  817. * ifconfig (fresh after recent reboot)
  818. eth0      Link encap:Ethernet  HWaddr 48:5b:39:c6:42:1b  
  819.          inet addr:192.168.144.77  Bcast:192.168.144.255  Mask:255.255.255.0
  820.          inet6 addr: 2001:14b8:100:8345:4a5b:39ff:fec6:421b/64 Scope:Global
  821.          inet6 addr: fe80::4a5b:39ff:fec6:421b/64 Scope:Link
  822.          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  823. lo        Link encap:Local Loopback  
  824.          inet addr:127.0.0.1  Mask:255.0.0.0
  825.          inet6 addr: ::1/128 Scope:Host
  826.          UP LOOPBACK RUNNING  MTU:65536  Metric:1
  827.  
  828. * route ipv4:
  829. default via 192.168.144.1 dev eth0
  830. 169.254.0.0/16 dev eth0  scope link  metric 1000
  831. 192.168.144.0/24 dev eth0  proto kernel  scope link  src 192.168.144.77
  832.  
  833. * route ipv6:
  834. 2001:14b8:100:8345::/64 dev eth0  proto kernel  metric 256  expires 86386sec
  835. fe80::/64 dev eth0  proto kernel  metric 256
  836. default via fe80::8eeb:c6ff:fec7:eb0c dev eth0  proto ra  metric 1024  expires 1508sec hoplimit 64
  837. default via fe80::2e0:ff:fe5a:436 dev eth0  proto ra  metric 1024  expires 76sec hoplimit 64
  838.  
  839. * forwarding:
  840. /proc/sys/net/ipv6/conf/eth0/forwarding: 0
  841.  
  842. * neighbours
  843. fe80::8eeb:c6ff:fec7:eb0c dev eth0 lladdr 8c:eb:c6:c7:eb:0c router DELAY
  844. fe80::2e0:ff:fe5a:436 dev eth0 lladdr 00:e0:00:5a:04:36 router STALE
  845.  
  846. * pinging the server:
  847. PING 2001:14b8:100:8345:2e0:ff:fe5a:436(2001:14b8:100:8345:2e0:ff:fe5a:436) 56 data bytes
  848. 64 bytes from 2001:14b8:100:8345:2e0:ff:fe5a:436: icmp_seq=1 ttl=64 time=0.388 ms
  849. --- 2001:14b8:100:8345:2e0:ff:fe5a:436 ping statistics ---
  850. 1 packets transmitted, 1 received, 0% packet loss, time 0ms
  851.  
  852. * pinging ipv6.google.com:
  853. PING ipv6.google.com(arn06s07-in-x0e.1e100.net) 56 data bytes
  854. --- ipv6.google.com ping statistics ---
  855. 1 packets transmitted, 0 received, 100% packet loss, time 0ms
  856.  
  857. * traceroute6 ipv6.google.com:
  858. traceroute to ipv6.l.google.com (2a00:1450:400f:805::200e) from 2001:14b8:100:8345:4a5b:39ff:fec6:421b, 30 hops max, 24 byte packets
  859. 1  * * *
  860.  
  861. Similar results with another client running Debian Jessie.
  862.  
  863. Most of the problems discussed in the forum seemed to be related to missing ipv6 address on the server interface from the sixxs offered subnet, but that is not the problem here. The server eth0 interface has address 2001:14b8:100:8345:2e0:ff:fe5a:436 that belongs to the subnet given, although not being the recommended 2001:14b8:100:8345::1 or 2, so this time the problem must elsewhere. But where?
  864.  
  865. //rkv
  866. Risto Virtanen
  867.  
  868. </content>
  869. </entry>
  870. <entry>
  871. <title>systemd too optimistic about network</title>
  872. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15793629-15793669&amp;from=atom" />
  873. <id>tag:forum.sixxs.net,2016-12-19:setup.15793629.15793669</id>
  874. <published>2016-12-19T18:12:07-00:00</published>
  875. <updated>2016-12-19T18:12:07-00:00</updated>
  876. <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author>
  877. <content type="html">
  878. Please file a bug report with your distribution directly, as apparently as the original coder of the project one has little to say when a package is maintained by some downstream.
  879.  
  880.  
  881. In the end though, your real solution is to get NATIVE IPv6 from your ISP. You did Call Your ISP we hope?
  882.  
  883. </content>
  884. </entry>
  885. <entry>
  886. <title>systemd too optimistic about network</title>
  887. <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=setup-15793629&amp;from=atom" />
  888. <id>tag:forum.sixxs.net,2016-12-19:setup.15793629</id>
  889. <published>2016-12-19T16:12:55-00:00</published>
  890. <updated>2016-12-19T16:12:55-00:00</updated>
  891. <author><name>Bernd Stramm</name><email>BST5-SIXXS@whois.sixxs.net</email></author>
  892. <content type="html">
  893. My system won't start aiccu at boot time, because the network is not ready enough.
  894. This system uses systemd, with a dependency like so:
  895. &#60;code&#62;[Unit]
  896. Description=AICCU (Automatic IPv6 Connectivity Configuration Utility)
  897. Wants=network.target network-online.target
  898. After=network.target network-online.target time-sync.target
  899. &#60;/code&#62;
  900.  
  901. When it starts aiccu, the host side of the network is good, but the network is not connected.
  902. Immediately after boot, starting aiccu manually does work correctly.
  903. So I believe that systemd is being optimistic about the network being up, especially
  904. if I connect through wifi (which I do usually).
  905.  
  906. How else can I set this up, to get a reliable, more conservative target to wait for?
  907.  
  908. </content>
  909. </entry>
  910. </feed>
  911.  

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

  1. Download the "valid Atom 1.0" banner.

  2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

  3. Add this HTML to your page (change the image src attribute if necessary):

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=https%3A//www.sixxs.net/forum/atom/%3Fsetup

Home · About · News · Docs · Terms

 
Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda