Subject: mic comments on next-hop RA option and VPN/IPv6 Enterprise

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Mar 2015 17:35:27 +0100

Hello Behcet, list,

I wanted to reiterate here the comments I had at mic about next-hop RA
option and VPN/IPv6 Enterprise.

Is there any Enterprise-grade IPv6-enabled VPN tool?  Is it running
IPv4/IPv6?  IPv6/IPv6?  Because I am only aware of IPv4-only
Enterprise-grade VPN tools, to connect back to the corporate network
while travelling.

Is this VPN tool using IP tunnels?  Becuase if so, then the RA sent over
these tunnels would use src address of that tunnel ('local' address on
the VPN gateway).  This address would make little sense on the subnet
where the client receives it, but _would_ make sense _over_ that tunnel.

To re-iterate a comment from an earlier commenter: how does the VPN
gateway could ever know the address of the BNG gw, or the LTE gw? (this
is the addres that one presumably sets in the next-hop option in the RA).

If the VPN tool does IPv6, is there something in the VPN setup procedure
(IKE?) that could help to set these routes whose next-hop address you
want in the RA; should this VPN tool encode this prefix, rather than
using the RA?  Some of the VPN tools distribute an address to the
Client, so it could distribute a prefix and a next-hop as well.

Alex

---

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

> Enterprise-grade VPN tools, to connect back to the corporate network

Why is this relevant? If those tools don't support v6 today, they
will tomorrow.

> is the addres that one presumably sets in the next-hop option in the RA).

Irrelevant. The problem arises in the host, not in any router.

> Client, so it could distribute a prefix and a next-hop as well.

There's nothing magic about solving it with an RA; any container that
contains the SADR next-hop route is good enough. But RA has the virtue
of generality since every IPv6 node must support RA.

  Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Mar 2015 20:56:41 +0100

> Why is this relevant? If those tools don't support v6 today, they

Sure.

But it would be good to see today which part of VPN is considered here.

Which VPN setup protocol, which VPN software tool, encapsulated or 
source-routed (rh).

Just saying Virtual Private Network doesnt clarify much.

> Irrelevant. The problem arises in the host, not in any router.

Brian, this may indeed a problem in the host.

But in that picture in the slide, the VPN gw sets an address in a 
next-hop field in that RA; that address is the address of a router 
(presumably a DSL operator's or LTE operator's router).  How does the 
VPN gw know that address?  This question is akin to that fate-sharing 
question.

Earlier with Behcet there seemed to be agreement that the LTE operator's 
router can not know the IP address of a DSL operator's router to put in 
that next-hop field.  Similarly, a third other party (the VPN gw) could 
not set the address of the LTE or DSL router in that next-hop field in RA.

> of generality since every IPv6 node must support RA.

Right, but this RA is sent across a tunnel, not directly on a link. 
That's what the picture shows: an RA crossing multiple subnets across 
the Internet; such an RA crossing multiple subnets can only happen over 
a tunnel.

The src address of this multi-subnet spanning RA should be in the 
next-hop field of that RA, and not the address of a 4G or DSL operator's 
network.

Alex

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

---

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

Hi Alex,

On Mon, Mar 23, 2015 at 2:56 PM, Alexandru Petrescu
<[email-masked]> wrote:
> But in that picture in the slide, the VPN gw sets an address in a next-hop
> field in that RA; that address is the address of a router (presumably a DSL
> operator's or LTE operator's router).  How does the VPN gw know that
> address?  This question is akin to that fate-sharing question.
>
> router can not know the IP address of a DSL operator's router to put in that
> next-hop field.  Similarly, a third other party (the VPN gw) could not set
> the address of the LTE or DSL router in that next-hop field in RA.
>

I think you are reading too much into the picture I showed.
What I tried to convey was VPN router is assumed to know the default
router address connected to each interface of the host and it includes
them in the next hop option.

If you read my next-hop-ra draft, there it is stated that this
requires site wide configuration and the router, e.g. VPN router is
trusted and able to configure hosts.

Whether or not this is possible in a multiple operator environment of
course can be an issue but I believe it is possible in an enterprise
network.

I think you had a proposal for improvement for fate sharing issue
which can be considered.

Behcet
> Right, but this RA is sent across a tunnel, not directly on a link. That's
> what the picture shows: an RA crossing multiple subnets across the Internet;
> such an RA crossing multiple subnets can only happen over a tunnel.
>
> The src address of this multi-subnet spanning RA should be in the next-hop
> field of that RA, and not the address of a 4G or DSL operator's network.
>
> Alex
>
>
>>
>>    Brian
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Mar 2015 18:56:40 -0500

Le 23/03/2015 18:32, Behcet Sarikaya a écrit :
>>>> I wanted to reiterate here the comments I had at mic about
>>>> next-hop RA option and VPN/IPv6 Enterprise.
>>>>
>>>> Is there any Enterprise-grade IPv6-enabled VPN tool?  Is it
>>>> running IPv4/IPv6?  IPv6/IPv6?  Because I am only aware of
>>>> IPv4-only Enterprise-grade VPN tools, to connect back to the
>>>> corporate network while travelling.
>>>
>>>
>>> Why is this relevant? If those tools don't support v6 today,
>>> they will tomorrow.
>>
>>
>> Sure.
>>
>>>> Is this VPN tool using IP tunnels?  Becuase if so, then the RA
>>>>  sent over these tunnels would use src address of that tunnel
>>>> ('local' address on the VPN gateway).  This address would make
>>>>  little sense on the subnet where the client receives it, but
>>>> _would_ make sense _over_ that tunnel.
>>>>
>>>> To re-iterate a comment from an earlier commenter: how does the
>>>> VPN gateway could ever know the address of the BNG gw, or the
>>>> LTE gw? (this is the addres that one presumably sets in the
>>>> next-hop option in the RA).
>>>
>>>
>>  (presumably a DSL operator's or LTE operator's router).  How does
>>  the VPN gw know that address?  This question is akin to that
>> fate-sharing question.
>>
>> Earlier with Behcet there seemed to be agreement that the LTE
>> operator's router can not know the IP address of a DSL operator's
>> router to put in that next-hop field.  Similarly, a third other
>> party (the VPN gw) could not set the address of the LTE or DSL
>> router in that next-hop field in RA.
>>
>
> I think you are reading too much into the picture I showed. What I
> tried to convey was VPN router is assumed to know the default router
>  address connected to each interface of the host and it includes them
>  in the next hop option.

How about including that info in the VPN setup process? (openvpn/ike
instead of RA).

> Whether or not this is possible in a multiple operator environment
> of course can be an issue but I believe it is possible in an
> enterprise network.

By this Enterprise you mean an Enterprise that manages a VPN gw, an
LTE network and a DSL network?

Where is the Internet in the picture?

> I think you had a proposal for improvement for fate sharing issue

My proposal was the following: make the next-hop option optional: maybe
qualified by a single bit indicating its presence.  In this way,
fate-sharing would be present when the next-hop option is absent.

I am happy you consider this proposal, but I am doubtful about the
feasibility of conveying information with an RA over a tunnel _after_
the VPN tunnel setup process - that process would be better adapted to
convey that info; especially since that process already conveys much info.

Alex

>
> Behcet
>>
>>>> If the VPN tool does IPv6, is there something in the VPN setup
>>>>  procedure (IKE?) that could help to set these routes whose
>>>> next-hop address you want in the RA; should this VPN tool
>>>> encode this prefix, rather than using the RA?  Some of the VPN
>>>>  tools distribute an address to the Client, so it could
>>>> distribute a prefix and a next-hop as well.
>>>
>>>
>>> There's nothing magic about solving it with an RA; any container
>>>  that contains the SADR next-hop route is good enough. But RA has
>>>  the virtue of generality since every IPv6 node must support RA.
>>
>>
>> That's what the picture shows: an RA crossing multiple subnets
>> across the Internet; such an RA crossing multiple subnets can only
>> happen over a tunnel.
>>
>> next-hop field of that RA, and not the address of a 4G or DSL
>> operator's network.
>>
>> Alex
>>
>>
>>>
>>> Brian
>>>
>>> [email-masked] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Mar 2015 14:19:46 -0500

Hello,

I wanted to follow up on this with a temporary conclusion.  Thanks Tim,
Ole, Pierre, Behcet who helped experiment this.

Most Enterprise VPN  clients are IPv4-only.  These are Nortel's
Contivity and Fortinet's FortiClient.  An IPv6-enabled VPN client is
from another particular company for their employees to securely access
their corporate network.

This particular VPN setup does not send RAs over the tunnel.  The
various parameters (IP address, routes) are set by some application
involving TLS, not by RA.

OpenVPN's documentation mentions IPv6 but only recently; we dont know
whether OpenVPN IPv6 version sends RA over the tunnel.

Under this circumstances it is hard to make the VPN use-case be relevant
for a need for next-hop option in RA.

Either the VPN use-case is digged further to expose RA presence
(openvpn?) or another use-case should be found for a next-hop in RA.

Alex

Le 23/03/2015 18:56, Alexandru Petrescu a écrit :
>>> Which VPN setup protocol, which VPN software tool, encapsulated
>>> or source-routed (rh).
>>>
>>>>> Is this VPN tool using IP tunnels?  Becuase if so, then the
>>>>> RA sent over these tunnels would use src address of that
>>>>> tunnel ('local' address on the VPN gateway).  This address
>>>>> would make little sense on the subnet where the client
>>>>> receives it, but _would_ make sense _over_ that tunnel.
>>>>>
>>>>> To re-iterate a comment from an earlier commenter: how does
>>>>> the VPN gateway could ever know the address of the BNG gw, or
>>>>> the LTE gw? (this is the addres that one presumably sets in
>>>>> the next-hop option in the RA).
>>>>
>>>>
>>> But in that picture in the slide, the VPN gw sets an address in
>>> a next-hop field in that RA; that address is the address of a
>>> router (presumably a DSL operator's or LTE operator's router).
>>> How does the VPN gw know that address?  This question is akin to
>>> that fate-sharing question.
>>>
>>> operator's router can not know the IP address of a DSL
>>> operator's router to put in that next-hop field.  Similarly, a
>>> third other party (the VPN gw) could not set the address of the
>>> LTE or DSL router in that next-hop field in RA.
>>>
>>
>> tried to convey was VPN router is assumed to know the default
>> router address connected to each interface of the host and it
>> includes them in the next hop option.
>
>> requires site wide configuration and the router, e.g. VPN router
>> is trusted and able to configure hosts.
>>
> My proposal was the following: make the next-hop option optional:
> maybe qualified by a single bit indicating its presence.  In this
> way, fate-sharing would be present when the next-hop option is
> absent.
>
> feasibility of conveying information with an RA over a tunnel
> _after_ the VPN tunnel setup process - that process would be better
> adapted to convey that info; especially since that process already
> conveys much info.
>
> Alex
>
>>
>> Behcet
>>>
>>>>> If the VPN tool does IPv6, is there something in the VPN
>>>>> setup procedure (IKE?) that could help to set these routes
>>>>> whose next-hop address you want in the RA; should this VPN
>>>>> tool encode this prefix, rather than using the RA?  Some of
>>>>> the VPN tools distribute an address to the Client, so it
>>>>> could distribute a prefix and a next-hop as well.
>>>>
>>>>
>>>> There's nothing magic about solving it with an RA; any
>>>> container that contains the SADR next-hop route is good enough.
>>>> But RA has the virtue of generality since every IPv6 node must
>>>> support RA.
>>>
>>>
>>> Right, but this RA is sent across a tunnel, not directly on a
>>> link. That's what the picture shows: an RA crossing multiple
>>> subnets across the Internet; such an RA crossing multiple subnets
>>> can only happen over a tunnel.
>>>
>>> The src address of this multi-subnet spanning RA should be in
>>> the next-hop field of that RA, and not the address of a 4G or
>>> DSL operator's network.
>>>
>>> Alex
>>>
>>>
>>>>
>>>> Brian
>>>>
>>> IETF IPv6 working group mailing list [email-masked]
>>> Administrative Requests:

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Mar 2015 11:13:29 -0500

On Tue, Mar 24, 2015 at 2:19 PM, Alexandru Petrescu
<[email-masked]> wrote:
> Hello,
>
> I wanted to follow up on this with a temporary conclusion.

I am not sure if there is any conclusion per se.

> Thanks Tim,

These could all be because of the assumption that only one interface
on the host is assumed?

> for a need for next-hop option in RA.

If there are not doing it now does not mean that they won't do it in the future?

> (openvpn?) or another use-case should be found for a next-hop in RA.

Agree.

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Mar 2015 17:56:38 -0500

> I am not sure if there is any conclusion per se.

A follow-up then.

>> Thanks Tim, Ole, Pierre, Behcet who helped experiment this.
>>
>> Contivity and Fortinet's FortiClient.  An IPv6-enabled VPN client
>> is from another particular company for their employees to securely
>> access their corporate network.
>>
>> various parameters (IP address, routes) are set by some
>> application involving TLS, not by RA.
>>
>> OpenVPN's documentation mentions IPv6 but only recently; we dont
>> know whether OpenVPN IPv6 version sends RA over the tunnel.
>>
>

I dont think so.  I think these implementations all consider there are
multiple virtual and physical interfaces in the Host.

I think that if two physical interfaces are up, each of these tools is
able to establish two different VPN tunnels over each one of the
interfaces.  It suffices to switch the default route from the 1st VPN
tunnel to the 2nd physical interface, prior to establishing the 2nd VPN
tunnel.

>> Under this circumstances it is hard to make the VPN use-case be
>> relevant for a need for next-hop option in RA.
>>
>

Yes and no.

The only IPv6-enabled Enterprise VPN tool will prefer to enhance the 
existing TLS-based application with new parameters such as next-hop, 
instead of programming these new parameters in RAs.  They have a 
protocol, it works for them, there would be no reason to use another 
protocol.

Unless of course you persuade these developpers to use RAs.  I dont know 
what arguments could you use to persuade them to do RA-over-tunnel 
instead of TLS.

>> (openvpn?) or another use-case should be found for a next-hop in

Do you think there is somewhere an IPv6-enabled Enterprise tool based on 
OpenVPN?  The kind of tool used to connect back to corporate network 
while travelling.

Alex

>>>>>>> I wanted to reiterate here the comments I had at mic
>>>>>>> about next-hop RA option and VPN/IPv6 Enterprise.
>>>>>>>
>>>>>>> Is there any Enterprise-grade IPv6-enabled VPN tool?  Is
>>>>>>> it running IPv4/IPv6?  IPv6/IPv6?  Because I am only
>>>>>>> aware of IPv4-only Enterprise-grade VPN tools, to connect
>>>>>>> back to the corporate network while travelling.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Why is this relevant? If those tools don't support v6
>>>>>> today, they will tomorrow.
>>>>>
>>>>>
>>>>>
>>>>> Sure.
>>>>>
>>>>> Which VPN setup protocol, which VPN software tool,
>>>>> encapsulated or source-routed (rh).
>>>>>
>>>>>>> Is this VPN tool using IP tunnels?  Becuase if so, then
>>>>>>> the RA sent over these tunnels would use src address of
>>>>>>> that tunnel ('local' address on the VPN gateway).  This
>>>>>>> address would make little sense on the subnet where the
>>>>>>> client receives it, but _would_ make sense _over_ that
>>>>>>> tunnel.
>>>>>>>
>>>>>>> To re-iterate a comment from an earlier commenter: how
>>>>>>> does the VPN gateway could ever know the address of the
>>>>>>> BNG gw, or the LTE gw? (this is the addres that one
>>>>>>> presumably sets in the next-hop option in the RA).
>>>>>>
>>>>>>
>>>>>>
>>>>> But in that picture in the slide, the VPN gw sets an address
>>>>> in a next-hop field in that RA; that address is the address
>>>>> of a router (presumably a DSL operator's or LTE operator's
>>>>> router). How does the VPN gw know that address?  This
>>>>> question is akin to that fate-sharing question.
>>>>>
>>>>> Earlier with Behcet there seemed to be agreement that the
>>>>> LTE operator's router can not know the IP address of a DSL
>>>>> operator's router to put in that next-hop field.  Similarly,
>>>>> a third other party (the VPN gw) could not set the address of
>>>>> the LTE or DSL router in that next-hop field in RA.
>>>>>
>>>>
>>>> What I tried to convey was VPN router is assumed to know the
>>>> default router address connected to each interface of the host
>>>> and it includes them in the next hop option.
>>>
>>>
>>> How about including that info in the VPN setup process?
>>> (openvpn/ike instead of RA).
>>>
>>>> requires site wide configuration and the router, e.g. VPN
>>>> router is trusted and able to configure hosts.
>>>>
>>>> Whether or not this is possible in a multiple operator
>>>> environment of course can be an issue but I believe it is
>>>> possible in an enterprise network.
>>>
>>>
>>> By this Enterprise you mean an Enterprise that manages a VPN gw,
>>> an LTE network and a DSL network?
>>>
>>>> I think you had a proposal for improvement for fate sharing
>>>> issue which can be considered.
>>>
>>>
>>> My proposal was the following: make the next-hop option
>>> optional: maybe qualified by a single bit indicating its
>>> presence.  In this way, fate-sharing would be present when the
>>> next-hop option is absent.
>>>
>>> I am happy you consider this proposal, but I am doubtful about
>>> the feasibility of conveying information with an RA over a
>>> tunnel _after_ the VPN tunnel setup process - that process would
>>> be better adapted to convey that info; especially since that
>>> process already conveys much info.
>>>
>>> Alex
>>>
>>>>
>>>> Behcet
>>>>>
>>>>>
>>>>>>> setup procedure (IKE?) that could help to set these
>>>>>>> routes whose next-hop address you want in the RA; should
>>>>>>> this VPN tool encode this prefix, rather than using the
>>>>>>> RA?  Some of the VPN tools distribute an address to the
>>>>>> container that contains the SADR next-hop route is good
>>>>>> enough. But RA has the virtue of generality since every
>>>>>> IPv6 node must support RA.
>>>>>
>>>>>
>>>>>
>>>>> Right, but this RA is sent across a tunnel, not directly on
>>>>> a link. That's what the picture shows: an RA crossing
>>>>> multiple subnets across the Internet; such an RA crossing
>>>>> multiple subnets can only happen over a tunnel.
>>>>>
>>>>> The src address of this multi-subnet spanning RA should be
>>>>> in the next-hop field of that RA, and not the address of a 4G
>>>>> or DSL operator's network.
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>>
>>>>>> Brian
>>>>>>