Subject: 6man-sadr-overview - next-hop option and VPN use-case clarifications

From: Pierre Pfister <[email-masked]>
Date: Mon, 23 Mar 2015 11:22:18 -0500

Hello Behcet,

Since I could not ask you this question at the mike, here it is.

Following your presentation, I did not really understood the VPN use-case you presented.

Is the host the VPN end-point ? Or is it the CPE ?
Why do you need to specify a different next-hop address than the one from the router sending the RA ?
Because right now, all the cases I can imagine do not require a next-hop option. 

Of course it may just be me not getting what you meant.

Could you provide a slightly more precise topology, and specify who would send what option to who ?

Thanks, 

- Pierre

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2015 07:13:56 +1300

What I have seen in enterprise VPN solutions is that when the VPN client
code starts up, it installs a long list of host routes, one for each
disjoint prefix in the corporate network.

All of these could be replaced by a single SADR next-hop route to the
VPN router.

The reason this *matters* is that whenever a prefix is added or removed
inside the corporate network, the list of host routes built into
the VPN client becomes obsolete and needs to be updated on every
host where that client is installed. That is painful for everyone
involved.

Regards
   Brian

On 24/03/2015 05:22, Pierre Pfister wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 23 Mar 2015 14:05:45 -0500

Brian,

> All of these could be replaced by a single SADR next-hop route to the

why wouldn’t the VPN router advertise that route?

> host where that client is installed. That is painful for everyone

the confusion here is why router A needs to advertise to a host that prefix X is reachable via router B, interface Y.
why can’t router B do that.

cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2015 15:27:26 -0400

> disjoint prefix in the corporate network.

Or, it installs a /32 route pointing at the normal next-hop, and a default
route into the VPN.  The /32 route is needed so that the encapsulated traffic
can get to the VPN end point.  The 0/0 route is often "implemented" as a
0.0.0.0/1 route plus a 128.0.0.0/1 route, so as not to mess with the DHCP
maintained 0.0.0.0/0 route.

All of this because in IPv4, we don't have SADR, which would otherwise say:
    vpnsourceip/128 -> ::/0 via vpn

    > host where that client is installed. That is painful for everyone

It's a really good point.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2015 15:29:19 -0400

> the confusion here is why router A needs to advertise to a host that
    > prefix X is reachable via router B, interface Y. 

In the IPv4, non-SADR case, we need this so that the VPN traffic can get to
the VPN end-point.  The VPN clients knows this, and it doesn't need to be
told.  Given SADR, we don't need this.

But, maybe we are not understanding what is really being proposed.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2015 08:37:35 +1300

> why wouldn’t the VPN router advertise that route?

You're assuming that the host would understand such an advertisement.
It seems to me that we're in a space where hosts don't understand
routing protocols. And where draft-troan-homenet-sadr-01 hasn't
been implemented either.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 23 Mar 2015 14:42:28 -0500

Brian,

> routing protocols. And where draft-troan-homenet-sadr-01 hasn't

now I’m utterly confused.
aren’t we talking about Behcet’s proposal for new RA options conveying reachability information.
and why there is a need to convey a 3rd party next-hop.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2015 08:56:47 +1300

> and why there is a need to convey a 3rd party next-hop.

Well, we've been jumping around the scenarios, and iirc the VPN scenario
isn't even discussed in the draft-sarikaya-6man-sadr-overview-05. So yes,
I think we've all confused each other. I'm thinking about the case
where it's the VPN router itself that wants to convey the source route
to the host, so it isn't a 3rd party next-hop.

    Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Mar 2015 21:02:03 +0100

> disjoint prefix in the corporate network.

That is one way of doing it.  I guess it would not scale to many routes.

Another one (by one particular VPN client) is to set a single default 
route towards that VPN tunnel interface.

> All of these could be replaced by a single SADR next-hop route to the

It would not scale either.  It would end to using a single 'default src' 
route.

> host where that client is installed. That is painful for everyone

I agree.  Just that another way would be that default.

Alex

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 23 Mar 2015 15:36:47 -0500

+1 to Ole,

The VPN end point should send RAs through the tunnel.
This is the correct way of doing it.

I have an OpenVPN service on my server. OpenVPN does not handle IPv6 configuration.
So when my client connects, OpenVPN fires an radvd instance over the tunnel which will send RAs with a PIO, which will be used for client's configuration.

And it works fine !

You could use RIOs as well (And SADRIOs). And it would just work I think.

- Pierre

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2015 10:09:41 +1300

> This is the correct way of doing it.

Yes. And the RA needs to convey SADR information. So
I'm not sure what we're arguing about.

    Brian

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 23 Mar 2015 16:13:47 -0500

Brian,

> I'm not sure what we're arguing about.

I started this thread to discuss the necessity of the next-hop RA option, allowing a router to create a route in hosts pointing to a different router.
This is part of what Behcet is proposing (sarikaya-6man-sadr-ra-00).

Right now, I still don’t see any use case where this is necessary.

- Pierre

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2015 17:33:56 -0400

> This is the correct way of doing it.

No, not really.
The tunnel would then be some kind of layer-2 thing.
The tunnel is really a point to point link, and both end points are routers.
So the VPN end point, being a router, should emit it's own RAs.

The tunnel itself needs policy, which the tunnel protocol (whether OpenVPN,
or IKEv2) communicates and sets up.

    > So when my client connects, OpenVPN fires an radvd instance over the
    > tunnel which will send RAs with a PIO, which will be used for client's
    > configuration.

Really... does it run this radvd on the local end point, or does it really
transmit across the tunnel?  How does it multicast to your LAN on that side?
Or does you OpenVPN only terminate on a single node (your laptop).

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 23 Mar 2015 16:52:45 -0500

Michael,

> Or does you OpenVPN only terminate on a single node (your laptop).

Yeah. My setup is actually using layer 2 tunnel.

But wouldn’t it work with layer 3 ? I mean, I see how this whole thing is kind of unspecified. 
But it *could* work on point-to-point links.

If you receive a RA from a default router on such a link, shouldn’t you just consider that ‘the other guy’ is the default router ? And that you should add a default route pointing to the tunnel ?

In any case, this is shifting from the discussion topic. The ‘next-hop option’ would not help I think.

- Pierre

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2015 18:51:11 -0400

> But it *could* work on point-to-point links.

If the radvd was on the gateway, it would have to do a directed multicast to
get the packet across.  And it would have to direct it to a link-local
address, which I think is not permitted.

    > If you receive a RA from a default router on such a link, shouldn’t you
    > just consider that ‘the other guy’ is the default router ? And that you
    > should add a default route pointing to the tunnel ?

Sure, that works great if it's just your host.
But, if the box is a gateway machine, then it doesn't work because it can't
be transmitted.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 23 Mar 2015 18:44:10 -0500

> Is the host the VPN end-point ? Or is it the CPE ?

The host could be CPE.
But CPEs usually don't have multiple interfaces, unless the new thing
called hybrid access is used.

> Why do you need to specify a different next-hop address than the one from the router sending the RA ?

This is inherent in the case, i.e. the host initially only talks to VPN router.

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Mar 2015 19:03:05 -0500

>> Is the host the VPN end-point ? Or is it the CPE ?

That would be a Router.

A Router, like most Routers, would have very little knowledge of the 
validity of source addresses issued by Hosts connected to it.

It would be hard to specify source-based routing on a Router, because 
there will be exceptions in the source addresses of the packets.  If 
that source-based routing fails for some reason, one ends up with a CPE 
which performs ingress filtering.  This ingress filtering is not a good 
thing.

> called hybrid access is used.

I agree.

In addition, even if that Enterprise's CPE has only one egress 
interface, there may be other CPE in house; this brings again the multi 
sourced packets and the risk of ingress filtering.

Alex