<p><br>
On Nov 29, 2011 7:58 AM, &quot;Michael Sinatra&quot; &lt;<a href="mailto:michael@rancid.berkeley.edu">michael@rancid.berkeley.edu</a>&gt; wrote:<br>
&gt;<br>
&gt; On 11/24/11 02:56, Cameron Byrne wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Nov 24, 2011 1:36 AM, &quot;Arturo Servin&quot; &lt;<a href="mailto:arturo.servin@gmail.com">arturo.servin@gmail.com</a><br>
&gt;&gt; &lt;mailto:<a href="mailto:arturo.servin@gmail.com">arturo.servin@gmail.com</a>&gt;&gt; wrote:<br>
&gt;&gt;  &gt;<br>
&gt;&gt;  &gt;<br>
&gt;&gt;  &gt; &lt;snip&gt;<br>
&gt;&gt;  &gt;<br>
&gt;&gt;  &gt; On 24 Nov 2011, at 07:20, Eugen Leitl wrote:<br>
&gt;&gt;  &gt;<br>
&gt;&gt;  &gt;&gt;  as the<br>
&gt;&gt;  &gt;&gt; fc00::/7 addresses will not be routed beyond that, correct?<br>
&gt;&gt;  &gt;<br>
&gt;&gt;  &gt; &lt;snip&gt;<br>
&gt;&gt;  &gt;<br>
&gt;&gt;  &gt; Incorrect or not necessary.<br>
&gt;&gt;  &gt;<br>
&gt;&gt;<br>
&gt;&gt; No<br>
&gt;&gt;<br>
&gt;&gt;  &gt; ULAs are just as any other unicast addresses. As technical community<br>
&gt;&gt; we had agreed to not route it in the internet, but If you leak it and<br>
&gt;&gt; somebody else routes it, you are fried.<br>
&gt;&gt;  &gt;<br>
&gt;&gt;<br>
&gt;&gt; No, this rfc defined behavior. Please check your facts.<br>
&gt;&gt;<br>
&gt;&gt; It is the same situation as rfc 1918 leaking. Saying that it is in any<br>
&gt;&gt; way different from rfc 1918 is misleading people.  Ula is not in the dfz<br>
&gt;&gt; and if it got leaked it would be fixed , just like 10/8.<br>
&gt;<br>
&gt;<br>
&gt; Actually, RFC 4193 and RFC 1918 *are* different.  RFC 1918 specifically states in section 5 that routing between ASes is allowed, with a specific, and very strict, caveat:<br>
&gt;<br>
&gt;   &quot;It is possible for two sites, who both coordinate their private<br>
&gt;   address space, to communicate with each other over a public network.<br>
&gt;   To do so they must use some method of encapsulation at their borders<br>
&gt;   to a public network, thus keeping their private addresses private.&quot;<br>
&gt;<br>
&gt; RFC 4193 has no such requirement for encapsulation, only that routes carried in fc00::/7 must be a /48 or longer.  (See below.)<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Both ula and rfc 1918 should be part of any inter domain ingress and<br>
&gt;&gt; egress filtering.<br>
&gt;&gt;<br>
&gt;&gt; If you want to keep pushing that there is an operational difference from<br>
&gt;&gt; a routing policy perspective, cite some facts<br>
&gt;&gt;<br>
&gt;&gt;  From rfc 4193<br>
&gt;&gt;<br>
&gt;&gt; Site border routers and firewalls should be configured to not forward<br>
&gt;&gt; any packets with Local IPv6 source or destination addresses outside of<br>
&gt;&gt; the site, unless they have been explicitly configured with routing<br>
&gt;&gt; information about specific /48 or longer Local IPv6 prefixes. This will<br>
&gt;&gt; ensure that packets with Local IPv6 destination addresses will not be<br>
&gt;&gt; forwarded outside of the site via a default route. The default behavior<br>
&gt;&gt; of these devices should be to install a &quot;reject&quot; route for these prefixes.<br>
&gt;&gt;<br>
&gt;&gt; .....  And......<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; If BGP is being used at the site border with an ISP, the default BGP<br>
&gt;&gt; configuration must filter out any Local IPv6 address prefixes, both<br>
&gt;&gt; incoming and outgoing. It must be set both to keep any Local IPv6<br>
&gt;&gt; address prefixes from being advertised outside of the site as well as to<br>
&gt;&gt; keep these prefixes from being learned from another site<br>
&gt;<br>
&gt;<br>
&gt; You forgot the next sentence:<br>
&gt;<br>
&gt;   &quot;The<br>
&gt;   exception to this is if there are specific /48 or longer routes<br>
&gt;   created for one or more Local IPv6 prefixes.&quot;<br>
&gt;<br>
&gt; In both paragraphs you cite, the notion is that we don&#39;t want a large prefix in the ULA space to be announced in such a way that it gets into the DFZ.  But we don&#39;t really care if it&#39;s routed between sites.  The /48 stipulation is for easy filtering, but as Ted Hardie points out here:<br>

&gt;<br>
&gt; <a href="http://www.nanog.org/meetings/nanog40/presentations/ula-nanog.pdf">www.nanog.org/meetings/nanog40/presentations/ula-nanog.pdf</a><br>
&gt;<br>
&gt; there is a slippery slope involved.<br>
&gt;<br>
&gt; The encapsulation requirement in RFC 1918 is significant, because it allows everyone to filter both traffic _and_ routes.  RFC 4193 does not require encapsulation outside of a site, does not allow for _wholesale_ traffic filtering (because sites are allowed to exchange their individual /48s), and does not restrict the use of /48s in the ULA space in a BGP routing table.  It doesn&#39;t even specifically say that ULA prefixes cannot appear in the DFZ table, although it does require that ULA routes be leaked in such a way that they can easily be filtered.<br>

&gt;<br>
&gt; To sum up: RFC 4193 _does_ say that ULA routes and ULA traffic should not be passed by default, but specifically allows for non-default configurations to pass traffic and routes between ASes.  RFC 1918, on the other hand, provides no exceptions for route leakage (it shouldn&#39;t happen at all) and only allows traffic leakage if the private traffic is encapsulated in globally-routable packets (e.g. 4to4 GRE).<br>

&gt;<br>
&gt; I think it&#39;s very misleading to say, or imply, that RFC 4193 is the IPv6 version of RFC 1918, and I see that far too much.  (You didn&#39;t explicitly do that, but again, there&#39;s a slippery slope :)  I think ultimately, 4193 should be split into two RFCs, which which specifies the ULA addressing algorithms, and the other which specifies BCPs around ULAs (a la RFC 1918).  But that&#39;s not what RFC 4193 currently does. Brian Carpenter probably has better visibility into why that&#39;s the case than I do...<br>

&gt;<br>
&gt; michael<br></p>
<p>My read of the interdomain routing provision is that ula supports extanets where rfc1918 could not explicitly<br>
</p>