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

><br>
> <a href="http://www.nanog.org/meetings/nanog40/presentations/ula-nanog.pdf">www.nanog.org/meetings/nanog40/presentations/ula-nanog.pdf</a><br>
><br>
> there is a slippery slope involved.<br>
><br>
> 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'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>

><br>
> 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't happen at all) and only allows traffic leakage if the private traffic is encapsulated in globally-routable packets (e.g. 4to4 GRE).<br>

><br>
> I think it'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't explicitly do that, but again, there'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's not what RFC 4193 currently does. Brian Carpenter probably has better visibility into why that's the case than I do...<br>

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