<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: IPv6 at home &#8211; a guide to getting started</title>
	<atom:link href="http://www.ipsidixit.net/2010/02/24/228/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.ipsidixit.net/2010/02/24/228/</link>
	<description>A far off place</description>
	<lastBuildDate>Mon, 23 Jan 2012 20:47:55 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: sgroarke</title>
		<link>http://www.ipsidixit.net/2010/02/24/228/comment-page-1/#comment-4596</link>
		<dc:creator>sgroarke</dc:creator>
		<pubDate>Thu, 08 Dec 2011 06:30:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.ipsidixit.net/2010/02/24/228/#comment-4596</guid>
		<description>Fixed. Thanks!!</description>
		<content:encoded><![CDATA[<p>Fixed. Thanks!!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew J. Leer</title>
		<link>http://www.ipsidixit.net/2010/02/24/228/comment-page-1/#comment-4595</link>
		<dc:creator>Andrew J. Leer</dc:creator>
		<pubDate>Thu, 08 Dec 2011 02:38:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.ipsidixit.net/2010/02/24/228/#comment-4595</guid>
		<description>Thanks for writing this tutorial!  I am enjoying it greatly.

There&#039;s a spelling mistake (no big deal I&#039;m sure) but if you want to correct it I&#039;m letting you know in the &quot;DHCP client I get, but what’s with DHCP server versus radvd?&quot; it reads &quot;since it dos not allocate any&quot; instead of &quot;since it does not allocate any&quot;

You can delete my comment if you like, I just wanted to let you know about it.</description>
		<content:encoded><![CDATA[<p>Thanks for writing this tutorial!  I am enjoying it greatly.</p>
<p>There&#8217;s a spelling mistake (no big deal I&#8217;m sure) but if you want to correct it I&#8217;m letting you know in the &#8220;DHCP client I get, but what’s with DHCP server versus radvd?&#8221; it reads &#8220;since it dos not allocate any&#8221; instead of &#8220;since it does not allocate any&#8221;</p>
<p>You can delete my comment if you like, I just wanted to let you know about it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Setting up a IPv6 Gateway on Hurricane Electric using Ubuntu 10.04.2 &#124; The Internet made me do it!</title>
		<link>http://www.ipsidixit.net/2010/02/24/228/comment-page-1/#comment-4539</link>
		<dc:creator>Setting up a IPv6 Gateway on Hurricane Electric using Ubuntu 10.04.2 &#124; The Internet made me do it!</dc:creator>
		<pubDate>Mon, 29 Aug 2011 11:16:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.ipsidixit.net/2010/02/24/228/#comment-4539</guid>
		<description>[...] Hurricane Electric - Tunnel Broker Easy Config for Linux Router Building a IPv6 Gateway anyweb sample configurations IPv6 - Ubuntu Wiki Ubuntu UFW Firewall Private Class B Network Address Neighbor Discovery for IP Version 6 Radvd config manpage Enabling IPv6 Privacy Extensions on Ubuntu Linux IPv6 at home - A guide to getting started [...]</description>
		<content:encoded><![CDATA[<p>[...] Hurricane Electric &#8211; Tunnel Broker Easy Config for Linux Router Building a IPv6 Gateway anyweb sample configurations IPv6 &#8211; Ubuntu Wiki Ubuntu UFW Firewall Private Class B Network Address Neighbor Discovery for IP Version 6 Radvd config manpage Enabling IPv6 Privacy Extensions on Ubuntu Linux IPv6 at home &#8211; A guide to getting started [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sgroarke</title>
		<link>http://www.ipsidixit.net/2010/02/24/228/comment-page-1/#comment-4005</link>
		<dc:creator>sgroarke</dc:creator>
		<pubDate>Sat, 04 Dec 2010 07:58:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.ipsidixit.net/2010/02/24/228/#comment-4005</guid>
		<description>Thanks for those thoughts. Absolutely good points all. However I think my omission is actually that I have not defined just *what* it is that this IPv6 box/firewall/router/VPN/younameit is actually ultimately going to be used for!!! Thus far, as this incremental project has progressed, all my IPv6 has terminated (in various manners) on the firewall box itself. (Note to purists: Yes, the firewall should NOT be the same device as the router/server/younnameit box... but it usually is!) When (if? No when, it will happen eventually...) I have this firewall actually routing traffic to/from the internal networks, then such matters as mentioned here need closer attention.

The RFC link is good for those in to RFCs.... But for those who have led an unblemished life, free from the taint of data comms RFCs, I advise caution. They drive you mad if treated without care. ;-)

Anyway, good information. One day when I write further articles about my IPv6 project, I&#039;ll be sure to refer folks back to your comment here!! Thanks!</description>
		<content:encoded><![CDATA[<p>Thanks for those thoughts. Absolutely good points all. However I think my omission is actually that I have not defined just *what* it is that this IPv6 box/firewall/router/VPN/younameit is actually ultimately going to be used for!!! Thus far, as this incremental project has progressed, all my IPv6 has terminated (in various manners) on the firewall box itself. (Note to purists: Yes, the firewall should NOT be the same device as the router/server/younnameit box&#8230; but it usually is!) When (if? No when, it will happen eventually&#8230;) I have this firewall actually routing traffic to/from the internal networks, then such matters as mentioned here need closer attention.</p>
<p>The RFC link is good for those in to RFCs&#8230;. But for those who have led an unblemished life, free from the taint of data comms RFCs, I advise caution. They drive you mad if treated without care. <img src='http://www.ipsidixit.net/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>Anyway, good information. One day when I write further articles about my IPv6 project, I&#8217;ll be sure to refer folks back to your comment here!! Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J. Grizzard</title>
		<link>http://www.ipsidixit.net/2010/02/24/228/comment-page-1/#comment-4004</link>
		<dc:creator>J. Grizzard</dc:creator>
		<pubDate>Fri, 03 Dec 2010 22:34:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.ipsidixit.net/2010/02/24/228/#comment-4004</guid>
		<description>You imply above that the only reason you allow ICMPv6 through your firewall is so that pings will work for testing (and thus could be removed after testing). This is a very bad thing to teach people, because it has the potential to be destructive in the IPv6 world. You need to let several different types of ICMPv6 messages through, for things to work correctly.

In particular, type 2 datagrams (&quot;packet too big&quot;) are used for path MTU discovery. IPv6 does not support packet fragmentation -- if your MTU is too big for something in your path, that traffic will get dropped, and the sending system will never know that it needs to back off on packet sizes. This type of problem can be *very* difficult to debug... it appears as a problem with an upstream connection, even though the problem is actually right there on your firewall.

Some type 1, type 3, and type 4 codes should also be allowed, no matter what.

RFC 4890 (http://www.ietf.org/rfc/rfc4890.txt) has a more thorough discussion of ICMPv6 filtering requirements and recommendations.</description>
		<content:encoded><![CDATA[<p>You imply above that the only reason you allow ICMPv6 through your firewall is so that pings will work for testing (and thus could be removed after testing). This is a very bad thing to teach people, because it has the potential to be destructive in the IPv6 world. You need to let several different types of ICMPv6 messages through, for things to work correctly.</p>
<p>In particular, type 2 datagrams (&#8220;packet too big&#8221;) are used for path MTU discovery. IPv6 does not support packet fragmentation &#8212; if your MTU is too big for something in your path, that traffic will get dropped, and the sending system will never know that it needs to back off on packet sizes. This type of problem can be *very* difficult to debug&#8230; it appears as a problem with an upstream connection, even though the problem is actually right there on your firewall.</p>
<p>Some type 1, type 3, and type 4 codes should also be allowed, no matter what.</p>
<p>RFC 4890 (<a href="http://www.ietf.org/rfc/rfc4890.txt" rel="nofollow">http://www.ietf.org/rfc/rfc4890.txt</a>) has a more thorough discussion of ICMPv6 filtering requirements and recommendations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sgroarke</title>
		<link>http://www.ipsidixit.net/2010/02/24/228/comment-page-1/#comment-3947</link>
		<dc:creator>sgroarke</dc:creator>
		<pubDate>Tue, 23 Mar 2010 14:02:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.ipsidixit.net/2010/02/24/228/#comment-3947</guid>
		<description>I&#039;ve rather glossed over the whole question of DNS... Since we&#039;re choosing to not implement IPv6 DHCP server, how do clients machine pick up the DNS? Sure, they get the address prefix from RADVD, but what about anything else?

In the first instance all my client will be dual-stack IPv4 &amp; IPv6. They already have the IPv4 DNS known and active so we will let them continue to use that. Of course if IPv4 does one day disappear, and we run as single-stack IPv6, this would need to be addressed.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve rather glossed over the whole question of DNS&#8230; Since we&#8217;re choosing to not implement IPv6 DHCP server, how do clients machine pick up the DNS? Sure, they get the address prefix from RADVD, but what about anything else?</p>
<p>In the first instance all my client will be dual-stack IPv4 &#038; IPv6. They already have the IPv4 DNS known and active so we will let them continue to use that. Of course if IPv4 does one day disappear, and we run as single-stack IPv6, this would need to be addressed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sgroarke</title>
		<link>http://www.ipsidixit.net/2010/02/24/228/comment-page-1/#comment-3928</link>
		<dc:creator>sgroarke</dc:creator>
		<pubDate>Fri, 05 Mar 2010 14:09:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.ipsidixit.net/2010/02/24/228/#comment-3928</guid>
		<description>Once IPv6 is set up and working, prior to us becoming a fully-fledged router we need to enable &lt;i&gt;forwarding&lt;/i&gt;. This is covered, along with the problems it then brings, &lt;a href=&quot;http://www.ipsidixit.net/2010/03/05/ipv6-and-default-routes&quot; rel=&quot;nofollow&quot;&gt;in this post here.&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p>Once IPv6 is set up and working, prior to us becoming a fully-fledged router we need to enable <i>forwarding</i>. This is covered, along with the problems it then brings, <a href="http://www.ipsidixit.net/2010/03/05/ipv6-and-default-routes" rel="nofollow">in this post here.</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sgroarke</title>
		<link>http://www.ipsidixit.net/2010/02/24/228/comment-page-1/#comment-3927</link>
		<dc:creator>sgroarke</dc:creator>
		<pubDate>Thu, 25 Feb 2010 13:05:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.ipsidixit.net/2010/02/24/228/#comment-3927</guid>
		<description>Here&#039;s another article where I tackle the issue of IPv6 firewall logging: http://www.ipsidixit.net/2010/02/25/231/</description>
		<content:encoded><![CDATA[<p>Here&#8217;s another article where I tackle the issue of IPv6 firewall logging: <a href="http://www.ipsidixit.net/2010/02/25/231/" rel="nofollow">http://www.ipsidixit.net/2010/02/25/231/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

