![[Valid Atom 1.0]](images/valid-atom.png "Valid Atom 1.0")
This is a valid Atom 1.0 feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<?xml version="1.0" encoding="utf-8"?><!-- ATOM generated by SixXS (https://www.sixxs.net) on --><feed xmlns="http://www.w3.org/2005/Atom"> <id>tag:forum.sixxs.net,2001:atom</id> <title>SixXS Forum - devel</title> <subtitle>SixXS Forum (ATOM 1.0)</subtitle> <link rel="self" type="application/atom+xml" href="https://www.sixxs.net/forum/atom/devel.atom" /> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/" /> <updated>2017-06-05T18:00:00-00:00</updated> <author> <name>SixXS Forum</name> <email>info@sixxs.net</email> </author> <entry> <title>BT Consumer division in the UK</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-15054577-15214641&from=atom" /> <id>tag:forum.sixxs.net,2016-04-29:devel.15054577.15214641</id> <published>2016-04-29T15:04:40-00:00</published> <updated>2016-04-29T15:04:40-00:00</updated> <author><name>Andre-John Mas</name><email>AME4-SIXXS@whois.sixxs.net</email></author> <content type="html">Alan Hicks wrote:<div class="quote">BT, one of the main providers of connectivity in the UK appear to have confirmed that they intend to deploy IPv6 across their entire network by December 2016.<a href="http://www.ispreview.co.uk/index.php/2015/09/uk-isp-bt-to-deploy-ipv6-to-entire-network-by-december-2016.html">http://www.ispreview.co.uk/index.php/2015/09/uk-isp-bt-to-deploy-ipv6-to-entire-network-by-december-2016.html</a>This is significant as ISPs such as PlusNet only sell the products available to them and as their support struggles with anything non standard is likely to be ignored/not fed back.</div> If you contact them and get them to confirm this, could you update the following wiki page, as appropriate: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 Thank you </content> </entry> <entry> <title>BT Consumer division in the UK</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-15054577&from=atom" /> <id>tag:forum.sixxs.net,2016-04-01:devel.15054577</id> <published>2016-04-01T16:04:39-00:00</published> <updated>2016-04-01T16:04:39-00:00</updated> <author><name>Alan Hicks</name><email>AHR14-SIXXS@whois.sixxs.net</email></author> <content type="html">BT, one of the main providers of connectivity in the UK appear to have confirmed that they intend to deploy IPv6 across their entire network by December 2016.<a href="http://www.ispreview.co.uk/index.php/2015/09/uk-isp-bt-to-deploy-ipv6-to-entire-network-by-december-2016.html">http://www.ispreview.co.uk/index.php/2015/09/uk-isp-bt-to-deploy-ipv6-to-entire-network-by-december-2016.html</a>This is significant as ISPs such as PlusNet only sell the products available to them and as their support struggles with anything non standard is likely to be ignored/not fed back. </content> </entry> <entry> <title>Dual IPv4/IPv6 health check</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-14781941-14884093-14891217&from=atom" /> <id>tag:forum.sixxs.net,2016-02-09:devel.14781941.14884093.14891217</id> <published>2016-02-09T16:02:42-00:00</published> <updated>2016-02-09T16:02:42-00:00</updated> <author><name>Andre-John Mas</name><email>AME4-SIXXS@whois.sixxs.net</email></author> <content type="html">Stefan Gebhardt wrote:<div class="quote">Andre-John Mas wrote:<div class="quote">I put together the following simple script to check the host health, for http request, but first checking to see if the host has an IPv4 or an IPv6 address (some may have both, some may have either). Does anyone have any improvements or a better one they could suggest? https://gist.github.com/ajmas/b02bac6437b307e52a2b Thanks</div>Nice Script, but not everyone uses ksh, maybe provide bash version??</div> I'll look into that when I have a few moments. If anyone provides improvements, I'll update the Gist. One of the things I still mean to do is add a response time indicator, since I have seen in some cases I observed the http traffic being slower in either the IPv4 or IPv6 stack. </content> </entry> <entry> <title>Dual IPv4/IPv6 health check</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-14781941-14884093&from=atom" /> <id>tag:forum.sixxs.net,2016-02-07:devel.14781941.14884093</id> <published>2016-02-07T03:02:57-00:00</published> <updated>2016-02-07T03:02:57-00:00</updated> <author><name>Stefan Gebhardt</name><email>SGE1-SIXXS@whois.sixxs.net</email></author> <content type="html">Andre-John Mas wrote:<div class="quote">I put together the following simple script to check the host health, for http request, but first checking to see if the host has an IPv4 or an IPv6 address (some may have both, some may have either). Does anyone have any improvements or a better one they could suggest? https://gist.github.com/ajmas/b02bac6437b307e52a2b Thanks</div>Nice Script, but not everyone uses ksh, maybe provide bash version?? </content> </entry> <entry> <title>Dual IPv4/IPv6 health check</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-14781941&from=atom" /> <id>tag:forum.sixxs.net,2016-01-06:devel.14781941</id> <published>2016-01-06T22:01:54-00:00</published> <updated>2016-01-06T22:01:54-00:00</updated> <author><name>Andre-John Mas</name><email>AME4-SIXXS@whois.sixxs.net</email></author> <content type="html">I put together the following simple script to check the host health, for http request, but first checking to see if the host has an IPv4 or an IPv6 address (some may have both, some may have either). Does anyone have any improvements or a better one they could suggest? https://gist.github.com/ajmas/b02bac6437b307e52a2b Thanks </content> </entry> <entry> <title>Measuring IPv6 and IPv4 traffic separately</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-871639-13127833-13127993&from=atom" /> <id>tag:forum.sixxs.net,2015-02-06:devel.871639.13127833.13127993</id> <published>2015-02-06T18:02:04-00:00</published> <updated>2015-02-06T18:02:04-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html">Jason lewis wrote:<div class="quote">The quickest way I have found is just to analyze web server logs. If your web server supports IPv6, then you should be able to tell by the connecting IP address.</div> That would only measure web*server* traffic, not what is happening in your network though. </content> </entry> <entry> <title>Measuring IPv6 and IPv4 traffic separately</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-871639-13127833&from=atom" /> <id>tag:forum.sixxs.net,2015-02-06:devel.871639.13127833</id> <published>2015-02-06T17:02:08-00:00</published> <updated>2015-02-06T17:02:08-00:00</updated> <author><name>Jason lewis</name><email>JLE14-SIXXS@whois.sixxs.net</email></author> <content type="html">The quickest way I have found is just to analyze web server logs. If your web server supports IPv6, then you should be able to tell by the connecting IP address. </content> </entry> <entry> <title>dhcp6s and dnsupdate -> is there a solution?</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-731298-13114509&from=atom" /> <id>tag:forum.sixxs.net,2015-02-04:devel.731298.13114509</id> <published>2015-02-04T01:02:58-00:00</published> <updated>2015-02-04T01:02:58-00:00</updated> <author><name>Jason lewis</name><email>JLE14-SIXXS@whois.sixxs.net</email></author> <content type="html">Stefan Jensen wrote:<div class="quote">Hi,... is there a working solution out there for giving dhcp6s the ability to update dns entries? (somehow like dhcpd does it) best regards Stefan--</div>One of those issues that has delayed IPv6 in my opinion. It appears that ISC has put this functionality in a few years after your post. Below is what I have been using in my dhcpd6.conf for over a year now. It seems to be working find for now. Some of the variable names are different between versions, but this should help anyone figure it out if they need other items in their conf. option domain-name &quot;example.org&quot;;option dhcp6.name-servers 2001:db8::1;option dhcp6.sntp-servers 2001:db8::1;default-lease-time 86400;max-lease-time 87000;authoritative; log-facility local7; #ddns-update-style ad-hoc;ddns-update-style interim;ddns-ttl 600;#ignore client-updates;deny client-updates; </content> </entry> <entry> <title>OpenEmbedded bitbake recipe for aiccu</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-10553546&from=atom" /> <id>tag:forum.sixxs.net,2013-11-24:devel.10553546</id> <published>2013-11-24T19:11:00-00:00</published> <updated>2013-11-24T19:11:00-00:00</updated> <author><name>Ole Wolf</name><email>OWF1-SIXXS@whois.sixxs.net</email></author> <content type="html">I wasn't able to find an OpenEmbedded recipe for aiccu enabling it to run in an embedded system constructed with the OpenEmbedded environment, so I put one together myself. In case anyone else needs it, you may find it here: <a href="https://github.com/olewolf/meta-olewolf/tree/master/recipes-connectivity/aiccu">Github</a>. </content> </entry> <entry> <title>MacOS X - System Preferences & aiccu?</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-1139578-9501654&from=atom" /> <id>tag:forum.sixxs.net,2013-06-03:devel.1139578.9501654</id> <published>2013-06-03T22:06:02-00:00</published> <updated>2013-06-03T22:06:02-00:00</updated> <author><name>Kristof Hannemann</name><email>KHF6-SIXXS@whois.sixxs.net</email></author> <content type="html">Hey mac users, I have started to write an IPv6 tunnel client for Mac called Maiccu. You can get it from <a href="http://apps.twikz.com/maiccu/">http://apps.twikz.com/maiccu/</a>. It is currently still in development stage. </content> </entry> <entry> <title>Preconditions for TPROXY within ip6tables</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-9258890-9285546-9285574&from=atom" /> <id>tag:forum.sixxs.net,2013-04-29:devel.9258890.9285546.9285574</id> <published>2013-04-29T20:04:33-00:00</published> <updated>2013-04-29T20:04:33-00:00</updated> <author><name>Michael Saxl</name><email>MSK12-SIXXS@whois.sixxs.net</email></author> <content type="html">Of corse I mean ports lower than 1024. See also man capabilities for other possible options </content> </entry> <entry> <title>Preconditions for TPROXY within ip6tables</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-9258890-9285546&from=atom" /> <id>tag:forum.sixxs.net,2013-04-29:devel.9258890.9285546</id> <published>2013-04-29T20:04:04-00:00</published> <updated>2013-04-29T20:04:04-00:00</updated> <author><name>Michael Saxl</name><email>MSK12-SIXXS@whois.sixxs.net</email></author> <content type="html">I don't know exactly what you are trying, but do note that TPROXY is not the same as REDIRECT in short: The application on port 8080 must understand tproxy. see http://www.mjmwired.net/kernel/Documentation/networking/tproxy.txt the nice thing about tproxy is that for both sites the ip/port combinations do not change. (If you use squid with tproxy, you will see the public ipv6 address of the client in the logs of the webserver) If all that you want to do is running some application as unprivileged user listening on port 80, you can also grant your application to bind on ports &lt; 1024 <div class="code">sudo setcap cap_net_bind_service+ep /path/to/your/app</div> then, your &quot;/path/to/your/app&quot; will be allowed to bind on ports lower than 80, even if you do not run it as root. </content> </entry> <entry> <title>Preconditions for TPROXY within ip6tables</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-9258890&from=atom" /> <id>tag:forum.sixxs.net,2013-04-25:devel.9258890</id> <published>2013-04-25T09:04:50-00:00</published> <updated>2013-04-25T09:04:50-00:00</updated> <author><name>Achim Scheidl</name><email>ASS19-SIXXS@whois.sixxs.net</email></author> <content type="html">Hi all,I try to use TPROXY to forward a port to another, but it is simly not working. If all ip6tables chains are empty (I know, it's a security risk, it's only for testing on private network), and I make the following: <div class="code">ip6tables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -j TPROXY --on-port 8080</div> I assume accessing port 80 will be forwarded to an application listening to port 8080, but there is no traffic. I've done:- modprobe xt_TPROXY- echo 1 &gt; /proc/sys/net/ipv6/conf/all/forwarding- tried in new Debian Wheezy and in Ubuntu 12.04 LTS What id I forgot? Thanks Achim </content> </entry> <entry> <title>Neighbor Unreachability Detection in 6in4 Tunnels</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-8081558-8081802-8094238&from=atom" /> <id>tag:forum.sixxs.net,2012-10-25:devel.8081558.8081802.8094238</id> <published>2012-10-25T14:10:53-00:00</published> <updated>2012-10-25T14:10:53-00:00</updated> <author><name>David Henriksson</name><email>DHC8-SIXXS@whois.sixxs.net</email></author> <content type="html">Thanks for your quick reply. I managed to get NUD enabled in my tunnel and had a chance to get a look at the packets so now I understand. My mistake were that I though it would not be possible to send a Neighbor Advertisements in response to a solicitation since there would not be any link <u>layer</u> (MAC) address associated with the inner IP of the tunnel. I realized that it is possible to send &quot;empty&quot; Neighbor Advertisments, as response to a Neighbor Solicitations. These advertisements do no contain any information about the link <u>layer</u> address (MAC address) - perfect for a tunnel encapsulated packet. </content> </entry> <entry> <title>Neighbor Unreachability Detection in 6in4 Tunnels</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-8081558-8081802&from=atom" /> <id>tag:forum.sixxs.net,2012-10-23:devel.8081558.8081802</id> <published>2012-10-23T19:10:21-00:00</published> <updated>2012-10-23T19:10:21-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html">There is a link-local address. Every single interface that is IPv6 enabled has to have one. For AYIYA we use a good portion of the IPv6 address on that link to generate a link-local address.Other implementations use the IPv4 address etc. </content> </entry> <entry> <title>Neighbor Unreachability Detection in 6in4 Tunnels</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-8081558&from=atom" /> <id>tag:forum.sixxs.net,2012-10-23:devel.8081558</id> <published>2012-10-23T18:10:56-00:00</published> <updated>2012-10-23T18:10:56-00:00</updated> <author><name>David Henriksson</name><email>DHC8-SIXXS@whois.sixxs.net</email></author> <content type="html">Hello, I'm working with implementing 6in4 tunnel according to RFC 4213. What puzzles me is section 3.8 Neighbor Discovery over Tunnels. How are Neighbor Unreachability Detection probes sent and replied to? Shall a tunnel endpoint encapsulate IPv6 neighbor discovery packets to resolve the other node's inner IPv6 address? This is odd since there is no link-layer address to resolve since the packets are tunneled in IPv4. What is the reply? Thanks in advance.David </content> </entry> <entry> <title>BIND IPv6 reverse generator</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-1187384-6264546-7322994&from=atom" /> <id>tag:forum.sixxs.net,2012-06-28:devel.1187384.6264546.7322994</id> <published>2012-06-28T23:06:23-00:00</published> <updated>2012-06-28T23:06:23-00:00</updated> <author><name>Matt Smith</name><email>MSK13-SIXXS@whois.sixxs.net</email></author> <content type="html"><div class="quote">Are dynamically variants an option?</div> I have recently been playing with dhcpv6 to assign IP's on my network at home rather than using stateless router advertisements and as part of this found out that you can use the $GENERATE directive with bind for IPv6 addressing. The documentation on it is a bit thin on the ground and there don't appear to be any examples found in google but I came up with this. Forward zone:<div class="code">$GENERATE 32-41 dhcp-${0,0,x} IN AAAA 2001:db8:1234:0::${0,0,x}</div> Reverse zone:<div class="code">$GENERATE 32-41 ${0,31,n} PTR dhcp-${0,0,x}.example.com.</div> This generates addresses between 20 and 29 with the format dhcp-??.example.com and 2001:db8:1234:0::??. It's a little more complicated to do than the equivalent for IPv4 addressing as you are dealing with hexadecimal and nibbles. The 32-41 is decimal for 20-29 in hex. The 0,31,n means output 31 characters in nibble format and the 0,0,x means output in hex format. You could also change that to d for decimal. The 31 character nibble size is designed to populate a /48 sized zone file where I've just used the origin as &quot;4.3.2.1.3.8.b.d.0.1.0.0.2.ip6.arpa&quot;. Obviously addresses have been altered to protect the innocent! </content> </entry> <entry> <title>BIND IPv6 reverse generator</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-1187384-6264546-7322994-7323218-7323330-7323922&from=atom" /> <id>tag:forum.sixxs.net,2012-06-28:devel.1187384.6264546.7322994.7323218.7323330.7323922</id> <published>2012-06-28T23:06:52-00:00</published> <updated>2012-06-28T23:06:52-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html">Indeed, fixed too ;) </content> </entry> <entry> <title>BIND IPv6 reverse generator</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-1187384-6264546-7322994-7323218-7323330&from=atom" /> <id>tag:forum.sixxs.net,2012-06-28:devel.1187384.6264546.7322994.7323218.7323330</id> <published>2012-06-28T16:06:43-00:00</published> <updated>2012-06-28T16:06:43-00:00</updated> <author><name>Matt Smith</name><email>MSK13-SIXXS@whois.sixxs.net</email></author> <content type="html">Thanks! But you missed one. The last line then should be 4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa I think if I've expanded the 0 in the right place. </content> </entry> <entry> <title>BIND IPv6 reverse generator</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-1187384-6264546-7322994-7323218&from=atom" /> <id>tag:forum.sixxs.net,2012-06-28:devel.1187384.6264546.7322994.7323218</id> <published>2012-06-28T15:06:31-00:00</published> <updated>2012-06-28T15:06:31-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html">I've fixed the &quot;innocent&quot; addresses by using the IPv6 Documentation Prefix (2001:db8::/32) which is meant for that purpose. </content> </entry> <entry> <title>IPv6 Protocol Number 0x2b (IPv6-Route) Not Supported</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-7310462-7315834-7316726-7316730-7316734-7316754&from=atom" /> <id>tag:forum.sixxs.net,2012-06-27:devel.7310462.7315834.7316726.7316730.7316734.7316754</id> <published>2012-06-27T20:06:03-00:00</published> <updated>2012-06-27T20:06:03-00:00</updated> <author><name>Yan Zou</name><email>YZQ1-SIXXS@whois.sixxs.net</email></author> <content type="html">Yeah, I just thought of this method and have provided more information. I am using sendip which could do that :) </content> </entry> <entry> <title>IPv6 Protocol Number 0x2b (IPv6-Route) Not Supported</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-7310462-7315834-7316750&from=atom" /> <id>tag:forum.sixxs.net,2012-06-27:devel.7310462.7315834.7316750</id> <published>2012-06-27T20:06:24-00:00</published> <updated>2012-06-27T20:06:24-00:00</updated> <author><name>Yan Zou</name><email>YZQ1-SIXXS@whois.sixxs.net</email></author> <content type="html">I manually set the hop limit to trace the original packet, and found that the packet is lost without any icmpv6 returned at the hop from (3) 2001:470:0:36::1 to (4) 2001:504:0:2:0:3:71:1. I further did the trace backforwards from destination to source, and found the packet lost at the hop from (6) 2001:4830:ff:b101::1 to (5) 2001:4830:ff:f150::2. Any idea what would happen at these routers? Thanks! </content> </entry> <entry> <title>IPv6 Protocol Number 0x2b (IPv6-Route) Not Supported</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-7310462-7315834-7316726-7316730-7316734&from=atom" /> <id>tag:forum.sixxs.net,2012-06-27:devel.7310462.7315834.7316726.7316730.7316734</id> <published>2012-06-27T20:06:31-00:00</published> <updated>2012-06-27T20:06:31-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html">Hmmm which might not work as hping3 is not very able to do IPv6... ;( </content> </entry> <entry> <title>IPv6 Protocol Number 0x2b (IPv6-Route) Not Supported</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-7310462-7315834-7316726-7316730&from=atom" /> <id>tag:forum.sixxs.net,2012-06-27:devel.7310462.7315834.7316726.7316730</id> <published>2012-06-27T20:06:21-00:00</published> <updated>2012-06-27T20:06:21-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html">You might want to try using 'hping3 -0 -H 43 -T &lt;destination&gt;' that gives you a traceroute with protocol 43 packets, which should show which hop is dropping them. </content> </entry> <entry> <title>IPv6 Protocol Number 0x2b (IPv6-Route) Not Supported</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-7310462-7315834-7316726&from=atom" /> <id>tag:forum.sixxs.net,2012-06-27:devel.7310462.7315834.7316726</id> <published>2012-06-27T20:06:45-00:00</published> <updated>2012-06-27T20:06:45-00:00</updated> <author><name>Yan Zou</name><email>YZQ1-SIXXS@whois.sixxs.net</email></author> <content type="html">Thank you very much for your reply! Yes, the source address is valid. I've tried other packets without the 0x2b ipv6-routing header, while other fields remain the same, and those packets can be transmitted successfully. Actually, 2001:470:1f07:20c::1 is an IPv6 address provided by Hurricane Electric. If I traceroute6 from the source to the destination, it would go through:traceroute to 2001:4830:1100:1ef::2 (2001:4830:1100:1ef::2) from 2001:470:1f06:20c::2, port 33434, from port 35929, 30 hops max, 60 byte packets 1 rsquirrel-1.tunnel.tserv4.nyc4.ipv6.he.net (2001:470:1f06:20c::1) 6.636 ms 5.273 ms 5.132 ms 2 gige-g3-8.core1.nyc4.he.net (2001:470:0:5d::1) 6.335 ms 1.554 ms 8.917 ms 3 10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1) 9.237 ms 15.964 ms 6.995 ms 4 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 7.455 ms 7.368 ms 7.116 ms 5 bbr01-p2-1.nwrk01.occaid.net (2001:4830:ff:f150::1) 14.536 ms 14.718 ms 13.689 ms 6 bbr01-g1-0.bstn01.occaid.net (2001:4830:ff:b101::2) 20.591 ms 20.387 ms 20.192 ms 7 dcr01-g0-1.bstn01.occaid.net (2001:4830:ff:b100::2) 20.785 ms 21.948 ms 20.643 ms 8 sixxs-ic-1139-bos.customer.occaid.net (2001:4830:e1:b::2) 21.394 ms 20.598 ms 21.104 ms 9 gw-496.bos-01.us.sixxs.net (2001:4830:1100:1ef::1) 20.546 ms 21.099 ms 20.862 ms10 cl-496.bos-01.us.sixxs.net (2001:4830:1100:1ef::2) 115.745 ms 115.786 ms 105.314 ms Also, I've received no ICMPv6 packets when the packet is lost. </content> </entry> <entry> <title>IPv6 Protocol Number 0x2b (IPv6-Route) Not Supported</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-7310462-7315834&from=atom" /> <id>tag:forum.sixxs.net,2012-06-27:devel.7310462.7315834</id> <published>2012-06-27T17:06:50-00:00</published> <updated>2012-06-27T17:06:50-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html"><div class="quote">It turns out that all packets with protocol number 0x2b (IPv6-Route) in the Next Header field of IPv6 header are dropped inside the tunnel,</div>For SixXS I can state that we do not drop anything except what is specified in the FAQ.This should thus travel through quite fine. Also, I do not see why any other network would be dropping this. <div class="quote">Source: 2001:470:1f07:20c::1</div><div class="quote">Destination: 2001:4830:1100:1ef::2 (the address of &quot;sixxs&quot; interface on Mobile Node)</div>Is the source address valid for that packet? What path does it take and which intermediates does it cross?Do you receive any ICMPv6 packets back indicating issues with the packet? </content> </entry> <entry> <title>IPv6 Protocol Number 0x2b (IPv6-Route) Not Supported</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-7310462&from=atom" /> <id>tag:forum.sixxs.net,2012-06-26:devel.7310462</id> <published>2012-06-26T20:06:04-00:00</published> <updated>2012-06-26T20:06:04-00:00</updated> <author><name>Yan Zou</name><email>YZQ1-SIXXS@whois.sixxs.net</email></author> <content type="html">Hi I found this issue in Mobile IPv6 experiments. When the Mobile Node switches interface from &quot;wlan0&quot; (Wi-Fi) to &quot;sixxs&quot; (AYIYA tunnel), it sends Binding Update to Home Agent and Home Agent replies Bind Acknowledgement. The acknowledgement packet has been sent to Internet (confirmed by Wireshark) but the Mobile Node could not receive that packet. I tried ping from Home Agent to Mobile Node and it worked perfectly. So I tested with the tool sendip which could generate arbitrary IPv6 packets. It turns out that all packets with protocol number 0x2b (IPv6-Route) in the Next Header field of IPv6 header are dropped inside the tunnel, while all other packets can successfully reach the other end of the tunnel. I wonder why it happens. The details of one of the dropped packets is shown below (from Wireshark): IPv6 Header:Version: 6Traffic class: 0Flowlabel: 0Payload length: 40Next header: Ipv6 routing (0x2b)Hop limit: 64Source: 2001:470:1f07:20c::1Destination: 2001:4830:1100:1ef::2 (the address of &quot;sixxs&quot; interface on Mobile Node) Routing Header:Type: Mobile IP (2)Next header: Mobile IPv6 (0x87)Length: 2 (24 bytes)Type: Mobile IP (2)Left Segments: 1Home Address: 2001:4830:1100:1ef::2 Mobile IPv6 Header:... (irrelevant) </content> </entry> <entry> <title>BIND IPv6 reverse generator</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-1187384-6264546-6268286&from=atom" /> <id>tag:forum.sixxs.net,2012-01-12:devel.1187384.6264546.6268286</id> <published>2012-01-12T13:01:45-00:00</published> <updated>2012-01-12T13:01:45-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html">One can easily serve these kinds of zones with a mixture of PowerDNS and a custom backend which generates the records on the fly. </content> </entry> <entry> <title>BIND IPv6 reverse generator</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-1187384-6264546&from=atom" /> <id>tag:forum.sixxs.net,2012-01-12:devel.1187384.6264546</id> <published>2012-01-12T00:01:33-00:00</published> <updated>2012-01-12T00:01:33-00:00</updated> <author><name>Anders Asperheim</name><email>AA21-SIXXS@whois.sixxs.net</email></author> <content type="html">I must ask if you really want to go down this road. The sizes of these tables, statically assigned, would be gigantic. Are dynamically variants an option? </content> </entry> <entry> <title>Mobile IPv6</title> <link rel="alternate" type="text/html" href="https://www.sixxs.net/forum/?msg=devel-1529105-4008073-6122170-6122242&from=atom" /> <id>tag:forum.sixxs.net,2011-12-20:devel.1529105.4008073.6122170.6122242</id> <published>2011-12-20T17:12:05-00:00</published> <updated>2011-12-20T17:12:05-00:00</updated> <author><name>Jeroen Massar</name><email>JRM1-RIPE@whois.sixxs.net</email></author> <content type="html">Not quite. TSP is a combined configuration and tunneling protocol.This while for SixXS TIC is the configuration protocol and AYIYA (or heartbeat/proto-41) are the tunneling protocols. They are this similar but behave quite different. There is a huge advantage in AYIYA in that it signs every packet, as such when your local IP address changes, the next packet going out updates it. For TSP that would mean that you need to redo the full TSP negotiation, thus you will be missing several packets being sent before that transaction is complete.As these parameters do not change that is not needed. The only thing that changes is the local IP:port combination. Note that this can also be a port change on the NAT side because the NAT decided to change it, which might quite often happen in a massive NAT environment like a 3G setup. YMMV of course, and as long as things work, that is what you need. </content> </entry></feed> If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
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/%3Fdevel
