mapping public to private IPv6 networks when firewalling

Cameron Byrne cb.list6 at gmail.com
Tue Nov 29 17:06:19 CET 2011


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

My read of the interdomain routing provision is that ula supports extanets
where rfc1918 could not explicitly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20111129/223730c7/attachment-0001.html 


More information about the ipv6-ops mailing list