Subject: should the IPv6 "default" route really be ::/0?

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Jan 2016 11:04:03 -0500

<#secure method=pgpmime mode=sign>

I've been dog-fooding v6-over-IPsec for IPv6 access of late?
(i.e. instead of sixxs/he/aiccu/etc. on my laptop when at the legacy coffee
shop.)

Naively, this involves building a tunnel from myip/128 -> ::/0.
A stupidity of the BSD/Linux WIDE/XFRM IPsec architecture is that it has an
additional firewall in the output path that encrypts the packets.
If there is *no route* for the destination, then the packets get no-route
error, never get to the output path and never get encrypted.

Back in the day, I tried to convince Itojun that we should have a virtual
interface for IPsec tunnels, and that the IPsec policy (which is source
sensitive as well as destination sensitive) should live in the routing
table.  It's too bad we didn't go that way because it would have given us
SADR much earlier, and would have made the need for application involvement
clearer long ago.  Itojun asked me a simple question which I couldn't answer:
    What is the scope of this virtual interface?

I've never been able to adequately answer the question.

I made sure that the right route gets created; historically on Linux the
route was added out the same interface as the default pointed, towards the
same next-hop router, but in a mixed v4/v6 situation, there isn't a default
v6 route to "emulate", and I also asked my self the question:
   Why am I building a route to ::/0?

   That's not the Internet.  The Internet is at 2000::/3.
   I see no reason why I should be routing traffic in the f000::/3 range,
   which is all special use: multicast, link-local, ULA, etc.

Which lead me to ask: why does it mean when a RA says it a default route?
(Part of this email is prompted by the 2001:db8 discussion).
What prefixes should a host always have some other route for?
     i.e. filter by longest prefix-match out.

DNS64/NAT64 certainly takes advantage of ::/0 covering 0::/3,
which includes, 64::/96.  But that also covers all the v4-mapped
address spaces, and the like.

What if hosts started considering "default route" to really mean 2000::/3?
Or should we instead suggest that hosts should include blackhole routes
for things like:   f000::/3?

Now, in my tunnel case, I'm using the IPsec tunnel to get IPv6, not exactly
for security.  I'd like the tunnel to remain up, even if I have IPv6, because
it gives mobileIP-like connectivity, and if I had native IPv6, I might want
to use a binding update.  If I had native IPv6, I'd have a ::/0 route, but
that's less specific than 2000::/3, so my native traffic goes the wrong way
if I don't put my 2000::/3 route on the correct interface.

So I have to use ::/0 for my extrusion, just at a lower metric, so that the
two potentially two ::/0 can compete properly...  And that is the reason why
I started thinking that maybe it was the system that was wrong to use a ::/0
route for default.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jan 2016 08:45:24 +1300

Just getting at one sub-issue:

On 25/01/2016 05:04, Michael Richardson wrote:
...
>    That's not the Internet.  The Internet is at 2000::/3.

Well, no, and that is the crux of the problem. That's only the part
of the Internet that IANA is currently handing out prefixes for.
4000::/3 is part of the Internet too.

The Internet is ::/0 minus the prefixes that aren't the Internet.

Neatly defined in https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-01#section-2.3
as "(everything else)"

No single prefix correctly identifies "everything else".

(I had a rather useless idea many years ago called "holemaps", which would have
been data structures expressing the holes in a given prefix, i.e. invalid
sub-prefixes, and "everything else" is in fact ::/0 plus a holemap.)

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Jan 2016 05:21:29 -0300

>     What is the scope of this virtual interface?

Maybe it's too late at night, but... what do you mean by scope of the
*interface*?

> v6 route to "emulate", and I also asked my self the question:

Not sure I follow... could you elaborate a bit?

>    which is all special use: multicast, link-local, ULA, etc.

link-locals should have more specific routes. ULAs, at the end of the
day are kinda globals... so the ::/0 is a catchall..

>      i.e. filter by longest prefix-match out.

that you send it anything for which you don't have a more specific
router. You'll always have that for link-locals and loopback...

> I started thinking that maybe it was the system that was wrong to use a ::/0

Note sure what you mean. Usually, if you want your secured tunnel to
override yu default route, you include two routes: ::/1 and 8000::/1, so
that that's more specific than ::/0. Some VPN clients do this sort of thing.

 -- that said, security-wise this is APITA and a risk, since a local
node could always install more specific outes e.g. via ICMPv6 Redirects,
RAs with more specific routes, etc. Please see RFC7359.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Jan 2016 10:42:51 -0500

> 4000::/3 is part of the Internet too.

I didn't know that we had moved into the second /3 block.

The converse of what I'm asking might be:
    - should hosts have a default blackhole route for any other prefixes?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Jan 2016 11:00:40 -0500

> Maybe it's too late at night, but... what do you mean by scope of the

I agree that I was a bit confused at the question too.

If I build a virtual interface for use by an IPsec tunnel, what is the scope
of this interface? for instance, what kinds of multicast should go out through this
interface?

    > Not sure I follow... could you elaborate a bit?

In v4 land, if I had:
   0.0.0.0/0 -> dev eth0 via 192.168.1.1

and I added a tunnel from 10.0.0.1/32 to 10.0.0.0/8, then I added a route
like:
   10.0.0.0/8 -> dev eth0 via 192.168.1.1

and a policy on eth0 that said:
   src:10.0.0.1/32 dst:10.0.0.0/8 -> ENCRYPT

Note how the nexthop for the inside route came from the nexthop from the outside.
If you follow the same logic with v6 inside, you wind up trying to do:
route:
   dst:2001:db8::1/16 -> dev eth0 via 192.168.1.1

which is totally wrong.  Fortunately on Linux, one can now omit the "via
xxxx" part, and wind up with:
   dst:2001:db8::/16 -> dev eth0

which routes it to the interface, which along with the policy:
   src:2001:db8::1 dst: 2001:db8::/16  -> ENCRYPT via 192.0.2.1

does the trick, at the cost of having slightly locked you to the state of the
eth0.  It ought to work with "dev lo", but on Linux this seems to fail, so
I have to route to "dummy0"... at which point I have a virtual interface
again.

    > day are kinda globals... so the ::/0 is a catchall..

Yes, but link-locals are /64 routes, and we have no /10 route to blackhole
the rest of them.

I rather wonder if we should have a blackhole for ULA space, at the option
of a router.  Or rather, a router might list a prefix in an anti-PIO, to say,
"and never route traffic to prefix X to me".  I guess that's getting too much into a
routing protocol...

    > that that's more specific than ::/0. Some VPN clients do this sort of thing.

Yes, FreeS/WAN first did this in 1998.

It's a hack, and it was done because you couldn't change the default route
without pulling the rug out from you.   If you aren't using the tunnel for
security, but rather, connectivity, then having it as a ::/0 route with a
higher or lower metric makes more sense.

---

From: David Farmer <[email-masked]>
Date: Mon, 25 Jan 2016 10:23:32 -0600

> On Jan 25, 2016, at 09:42, Michael Richardson <[email-masked]> wrote:
> 

NO!!  

While not released for allocation 4000::/3 is explicitly intended for global unicast allocation and nothing should be done that interferes with that.  We do not want a situation where addresses become unusable in the future when we need them, like IPv4 with 248.0.0.0/4.

I think it could be reasonable to filter routing and traffic at administrative boundaries for unallocated IPv6 blocks.  However, doing something statically on a host level is asking to make problems for the future.  That said, if there was an automated way for a host to update its policy from a well-known source, like maybe Team-Cymru, something like that might be workable.  But, if it's happening at administrative boundaries, is it really necessary to do it at the host level too?  

Personally, I think this should be done at administrative boundaries, not at the host level, especially considering the difficulty and the many ways the necessary automation could go wrong at a host level.

But, YMMV!

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Jan 2016 12:34:28 -0500

> While not released for allocation 4000::/3 is explicitly intended for
    > global unicast allocation and nothing should be done that interferes
    > with that.  We do not want a situation where addresses become unusable
    > in the future when we need them, like IPv4 with 248.0.0.0/4.

Well, I was thinking about f000:/3 and parts of 0::/3, not 4000::/3.
So I definitely take your point.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 25 Jan 2016 12:58:00 -0500

Hi Michael,

> of this interface? for instance, what kinds of multicast should go out through this

Not all interfaces have explicit scopes and that is discussed in RFC 4007.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jan 2016 07:39:57 +1300

> So I definitely take your point.

And that was my point too - the Internet (including the future Internet)
is ::/0 with holes in it. Given the tools we have, ::/0 seems to be the
best approximation.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Jan 2016 13:57:23 -0500

> Not all interfaces have explicit scopes and that is discussed in RFC

I think that 4007 is after the conversation with Itojun, by perhaps 10 years.

I guess you refer to section 5, last paragraph (wish we had anchors to link
directly..) and I guess the question of virtual interfaces and IPsec could be
examined again.

(There is a lot of "but that's not how XYZ did it" in the Linux and BSD
stacks, often forming a loop of arrows.)

---

From: Brian Haberman <[email-masked]>
Date: Mon, 25 Jan 2016 14:27:21 -0500

> directly..) and I guess the question of virtual interfaces and IPsec could be

My point is that there has been thought put into the scope of interfaces
and that is captured in 4007.  At this point, I am not sure we should be
trying to figure out what Itojun meant given that we have 4007 as a tool.

> stacks, often forming a loop of arrows.)

There are times where I wish the IETF had a way to give code developers
a rap on the knuckles [1]. The IETF cannot, but individual contributors
can push on those entities to do the right thing.

Regards,
Brian

[1]
http://dictionary.cambridge.org/us/dictionary/english/a-rap-on-over-the-knuckles

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 25 Jan 2016 13:06:40 -0800

Michael,

> On Jan 25, 2016, at 7:42 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

We have not started allocating prefixes out of 4000::/3.

See: https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jan 2016 10:17:18 +1300

> We have not started allocating prefixes out of 4000::/3.

No. But that isn't the point. The point is to burn ROMs that will
still work when prefixes in 4000::/3 *are* allocated.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 25 Jan 2016 13:30:56 -0800

Brian,

> On Jan 25, 2016, at 1:17 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Yes, I wasn’t suggesting otherwise.  As you pointed out RFC4291 (and bis) makes it clear these are all global unicast.

Bob