mapping public to private IPv6 networks when firewalling

Michael Sinatra michael at
Tue Nov 29 16:58:22 CET 2011

On 11/24/11 02:56, Cameron Byrne wrote:
> On Nov 24, 2011 1:36 AM, "Arturo Servin" <arturo.servin at
> <mailto:arturo.servin at>> 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:

    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:

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...


More information about the ipv6-ops mailing list