Subject: Re: Source Address Dependent Routing and Source Address Selection for IPv6 - fate sharing

From: Ray Hunter <[email-masked]>
Date: Mon, 02 Mar 2015 22:47:21 +0100

> Alexandru Petrescu <mailto:[email-masked]>
> 27 February 2015 14:23
> Le 25/02/2015 14:06, Ray Hunter a écrit :
>>> Alexandru Petrescu <mailto:[email-masked]> 24
>>> February 2015 16:18 Le 23/02/2015 17:40, V6ops a écrit :
>>>>
>>>>
>>>>> On 23 Feb 2015, at 10:55, Alexandru Petrescu
>>>>> <[email-masked]> wrote:
>>>>>
>>>>> Le 20/02/2015 21:46, V6ops a écrit :
>>>>>>
>>>>>>
>>>>>>> On 20 Feb 2015, at 17:51, Alexandru Petrescu
>>>>>>> <[email-masked]> wrote:
>>>>>>>
>>>>>>> Le 20/02/2015 13:23, Ole Troan a écrit :
>>>>>>>>>>
>>>>>>>>>> But why would one router need to point routes with
>>>>>>>>>> the next hop pointing at another router?
>>>>>>>>>
>>>>>>>>> BEcause that's how it works when two smartphones
>>>>>>>>> (Routers) talk directly over WiFi.  A Host device
>>>>>>>>> tethered to one smartphone would need to communicate to
>>>>>>>>> another Host tethered to the other smartphone. In this
>>>>>>>>> case, one smartphone (Router) would need to point a
>>>>>>>>> route with the next hop at the other smartphone
>>>>>>>>> (Router).
>>>>>>>>>
>>>>>>>>> The smartphone Router-to-Router is just an
>>>>>>>>> instantiation use-case. Another instantiation is in
>>>>>>>>> Vehicle-to-Vehicle communications.
>>>>>>>>
>>>>>>>> that's what we have redirects for.
>>>>>>>
>>>>>>> REdirects are sent by Routers to Hosts, not to other
>>>>>>> Routers.
>>>>>>>
>>>>>>> They assume some route is already in place (the route from
>>>>>>>  a Host to a Router) and that another one should be
>>>>>>> suggested - _re_-direct.
>>>>>>>
>>>>>>> In the case of smartphone-to-smartphone, or
>>>>>>> vehicle-to-vehicle, they may not be connected to anything
>>>>>>> else prior to connecting to each other, so they wouldnt
>>>>>>> issue Redirects.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>
>>>>>> And why exactly would a router listen to an RA then?
>>>>>>
>>>>>
>>>>> Sorry, I dont understand why you ask this?  Please clarify the
>>>>> question.
>>>>>
>>>>> Until then here's an answer about what I think the question is
>>>>>  not clear.
>>>>>
>>>>> A router would need to listen for RA issued by other router,
>>>>> such as to learn the prefix of this other Router's other
>>>>> interface.
>>>>
>>>> Where is this specified in a current IETF document?
>>>
>>
>>> In individual submissions such as the 'RA-based routing'
>> I've read these drafts. Thanks for the links.
>>> draft-petrescu-autoconf-ra-based-routing
>> OK. But this has a completely different RA option set and semantic
>> space, that is clearly only going to be processed by mobile routers.
>>  [new 'm' flag from 5175]
>>
>> I may or may not disagree with the proposal, but it's not going to
>> impact older nodes or non-mobile routers.
>
> I agree, these should ignore flags not understood.  In practice we have
> seen this M bit flag does not cause harm to other routers which do not
> understand it.
>
>>> with use-cases issued from the vehicular communications world; and
>>>  other similar mechanisms described in
>>> draft-pfister-moving-net-autoconf-00
>>
>> Again an 'm' flag for mobile use only.
>
> Yes, and this draft has a new 2-bit 'R' field to be considered in the
> future.  Some implementation of it specifies the extent of the
> propagation of the prefix, and maybe to more than just one hop.
>
>>> draft-jhlee-mext-mnpp-00
>>
>> Has a new ICMP type code for MNPP Solicitation and MNPP Advertisement
>> messages. It won't affect generic nodes.
>
> Ok.  The author will be happy to learn this, especially since that
> technique forms a basis for an ISO standard.
>
>>> draft-hampel-mext-ro-without-ha-00
>>
>> contains no new options AFAICS.
>
> Right.  It illustrates a Route Optimization path of development towards
> vehicle-to-vehicle communication, which considers Binding Updates
> instead of RAs.
>
>> My point is that none of these proposed extensions will likely be
>> processed by older nodes, or wired nodes, or Homenet nodes,
>
> Well.  A Homenet node must implement this technique when an automobile
> in the garage connects to the home hotspot (Tesla does this today).
>
> Will that Homenet node run HNCP or this M bit in a Router Advertisement?
>
>> so backwards compatibility and having to update generic (wired) nodes
>> is less of an issue for me.
>
> To a large extent yes.
>
>>>> Routers ignore RA in most instances ( unless they are acting as
>>>> a host on what is clearly an upstream interface, and they need
>>>> to configure a prefix for use on the upstream interface e.g. on
>>>> an ISP link)
>>>
>>> I agree.  But even this little detail (ignore RA unless acting as a
>>> host on a clearly identified upstream interface) is not explicitely
>>> stated anywhere.
>>
>> Agreed.
>>
>>>
>>>> Even in this case why would the RA require a different next hop
>>>> (my real confusion is why this option is needed at all)
>>>
>>> No, the next-hop comes from the src address of the RA.  But the
>>> prefix contained in the RA is the prefix of other link, not the
>>> prefix of the link on which this RA is sent.
>>
>> No, in Bechet's draft draft-sarikaya-6man-next-hop-ra-04, there's an
>>  explicit Next-Hop Address option proposed.
>>
>> That option only makes sense if it contains a next-hop address that
>> is different from the src address of the RA.
>>
>> That's exactly why I'm questioning the semantics of the new option
>> (e.g. with respect to the existing semantics of 4191).
>
> I agree.
>
> Moreover, putting a different next-hop address than src is less
> fate-sharing than putting a prefix present on the other link.
>
> Because whereas the prefix is of another link it is still on the same
> machine (its fate would still be shared, although not interface's), the
> next-hop is on another machine and another link.
>
> In that sense, if looking for as much as possible fate sharing one would
> consider the use of other link (same router) in the RA, rather than
> other address (other router) in the RA.
>
>>>> Homenet is not following this path for prefix
>>>> distribution/learning between LAN interfaces of Homenet devices
>>>> (one of the use cases of the draft). Two smartphones peering
>>>> would run HNCP to learn prefixes.... Not RA based mechanisms.
>>>
>>> Well, there should be a need for the HNCP to be first agreed on,
>>> and then to find widely available and reliable software.  With an
>>> RA-based scheme one would use already available software, with very
>>> small modifications, if any at all.
>>>
>>>>>
>>>>> A smartphone Router would send an RA on its bluetooth
>>>>> interface containing the prefix of its WiFi interface.
>>>>
>>>> This was already extensively discussed when producing
>>>> 464xlat.....
>>>
>>> I didnt know that.  I guess though 464xlat does not send RAs.
>>>
>>>>> An On-Board Unit Router would send an RA on its 802.11p
>>>>> (vehicle-to-vehicle) interface containing the prefix of its
>>>>> wired-Ethernet interface.
>>>>>
>>>>> Alex
>>>>
>>>> In general, I can certainly appreciate the need for a SADR
>>>> equivalent extension to 4191. But I'm mystified by the need for
>>>> the additional complexity contained in this draft. And I'm
>>>> genuinely missing how receiving nodes would process and validate
>>>>  the new options. I.e. The conceptual host model of 4191.
>>>
>>> I personally think at this time that SADR is a concept still much
>>> in an inception phase.  There are multiple ways in which the src
>>> address could be taken into account during a forwarding process.
>>> And I think it has little to do with RFC4191, or with what to put
>>> in an RA.
>>>
>>> The reason I react on this thread is only related to having other
>>> links' prefixes in an RA.
>>>
>> I find these use cases of an RA message containing information about
>>  off-link interfaces distinctly odd.
>
> Noted, but disagreeing.
>
>> RA is strictly link local (section 6.1.1 and 6.1.2 of RFC4861).
>>
>> Quote: "A node MUST silently discard any received Router
>> Advertisement messages that do not satisfy all of the following
>> validity checks:
>>
>> - IP Source Address is a link-local address."
>
> This is still the case: the src address of the RA containing the other
> interface's prefix is still that link-local address of that interface.
>
>> How does the receiving node know that the next hop is being
>> advertised from another interface on the sending router (there's no
>> interface tag in the proposed option)? [use case given by you of a
>> smart phone advertising its wifi prefix via the bluetooth interface]
>
> Well the receiving node does not need the src address of that other
> interface, because it is not in direct contact with it.  It needs the
> src address of the interface that sends the RA: through it it will reach
> the other link (immediate next-hop).
>
>> So in my mind that is introducing a possibility of non optimal
>> routing, race conditions, or worse still, looping (imagine the two
>> routers share two links, both wifi AND bluetooth, rather than just
>> one, and they pair at different times)
>
> Such possibilities may indeed be introduced.
>
> However, the precise case you cite (two routers share two links, both
> wifi and bluetooth) does not introduce any looping.  Simply only one
> route will be chosen among two present (2 redundant routes), depending
> on which was the last introduced.  One would rather think that it's
> better to have two routing paths always.
>
> Second, looping and other undesirable situations can be avoided by
> techniques yet to be developped as we encounter them in real-world
> use-cases.
Glad you're so positive about RA.
> The current trials (simple v2v communications) don't exhibit
> such undesirable IP routing situations.
>
> What are the use-cases which may exhibit non-optimal routing, race
> conditions and looping?
>

>> How does the receiving node know that the next hop target is to be
>> found on another interface on the receiving host (again there's no
>> interface tag in the proposed option)?
>
> The receiving node receives a prefix and installs it in its routing
> table with next-hop containing the src of the RA.  The receiving node
> does not run apps.
>
And why not? Are these devices so specific that they'll never ever be 
extended?
> Another node (a laptop in the car) uses its default route towards the
> 'receiving node' that we talk above.
>
>> [use case given by Bechet of a 3gpp router advertising next hop
>> addresses for use on the wireless interface on the receiving node
>> when connected to a VPN router]
>
> That is a use-case to which I dont agree.  NEver in practice a 3gpp
> router advertises an RA about another router outside the 3gpp network.
> That is a brokeness situation.
>
>> So in my mind that is introducing a possibility of non optimal
>> routing, or route attacks where routes received on a trusted
>> interfaces point to non-trusted interfaces, or an amplification
>> attack, where the receiving node has to perform ND on all of its
>> interfaces to discover where the proposed next hop is located
>> (assuming the advertised next hop actually contains garbage, and is
>> unreachable)
>
> Non optimal routing - I am curious to see where this situation can
> occur.  Otherwise stating it just as such may make think of speculation.
>  Yes, good in general to avoid non-optimal routing, but it does not
> exist everywhere.
Well it's pretty trivial to come up with problems. RA was designed to 
work over a single link, to communicate next hop information between an 
on-link router and an on-link host.

RA contains no explicit hop count. RA contains no explicit origin 
information. RA doesn't contain explicit timing or topology versioning 
information.

So taking your use case of a smart phone advertising a route to its wifi 
interface over bluetooth.....

if you have 4 such devices (Router_A, Router_B, Router_C, Router_D) 
behaving in the same way, connected say by Ethernet or an other 
multipoint segments [E1 ..E5] and with Prefix P1 on the ISP link, you have

ISP router ---E1-P1--- Router_A --- E2 --- Router_B --- E3 --- Router_C 
--- E4 --- Router_D --- E5

Which works fine and dandy in a linear or tree architecture.

Now connect E5 to E2, either temporarily or permanently. Router_B has no 
way of differentiating between an update from Router_D or an update from 
Router_A for Prefix P1.
The "metric" in RA is simply high medium or low. And that is a local 
preference. Not inherited or determined via other RA updates.

Similarly, Prefix 1 might be learned via being directly connected, or it 
might be learned via a routing protocol.
Router_B has no way of differentiating the origin of the information: it 
just receives reachability information.

And RA timing is only used for the next hop, which means Router_D has no 
idea of the current status of E3 or E2.

Well established routing protocols contain this extra information for a 
reason. Poor man's routing protocols (like RA) will inevitably break 
down when faced with real world topologies.

Deploying RA in these scenarios will require communicating much more 
extensive information than is currently contained in RA packets, in 
which case, why not just deploy a proper routing protocol in the first 
place?
>
> Amplification attack - yes we need to avoid an exponential growth of
> routing messages or of routing table entries provoked by the dynamic
> nature of mobility patterhs of devices such as vehicles.  But a
> receiving node does not perform ND on all of its interfaces to discover
> the proposed next hop.  A receiving node does just NS/NA for the src of
> the RA it received, on the interface it received it; that src address is
> also present on that link.  I do not propose to set garbage in the
> next-hop field of an RA.
>
Of course you won't send garbage in RA messages. But attackers will send 
garbage from the WAN link if it can cause an amplification attack on the 
LAN see e.g. https://tools.ietf.org/html/rfc6583.
> Alex
>
>
>>> Alex
>>>
>>>
>>> V6ops <mailto:[email-masked]> 23 February 2015 17:40
>>>> On 23 Feb 2015, at 10:55, Alexandru
>>>> Petrescu<[email-masked]>  wrote:
>>>>
>>>> Le 20/02/2015 21:46, V6ops a écrit :
>>>>>> On 20 Feb 2015, at 17:51, Alexandru Petrescu
>>>>>> <[email-masked]>  wrote:
>>>>>>
>>>>>> Le 20/02/2015 13:23, Ole Troan a écrit :
>>>>>>>>> But why would one router need to point routes with the
>>>>>>>>>  next hop pointing at another router?
>>>>>>>> BEcause that's how it works when two smartphones
>>>>>>>> (Routers) talk directly over WiFi.  A Host device
>>>>>>>> tethered to one smartphone would need to communicate to
>>>>>>>> another Host tethered to the other smartphone. In this
>>>>>>>> case, one smartphone (Router) would need to point a route
>>>>>>>> with the next hop at the other smartphone (Router).
>>>>>>>>
>>>>>>>> The smartphone Router-to-Router is just an instantiation
>>>>>>>> use-case. Another instantiation is in Vehicle-to-Vehicle
>>>>>>>> communications.
>>>>>>> that's what we have redirects for.
>>>>>> REdirects are sent by Routers to Hosts, not to other
>>>>>> Routers.
>>>>>>
>>>>>> They assume some route is already in place (the route from a
>>>>>>  Host to a Router) and that another one should be suggested
>>>>>> - _re_-direct.
>>>>>>
>>>>>> In the case of smartphone-to-smartphone, or
>>>>>> vehicle-to-vehicle, they may not be connected to anything
>>>>>> else prior to connecting to each other, so they wouldnt issue
>>>>>> Redirects.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>> And why exactly would a router listen to an RA then?
>>>>>
>>>> Sorry, I dont understand why you ask this?  Please clarify the
>>>> question.
>>>>
>>>> Until then here's an answer about what I think the question is
>>>> not clear.
>>>>
>>>> A router would need to listen for RA issued by other router, such
>>>> as to learn the prefix of this other Router's other interface.
>>> Where is this specified in a current IETF document?
>>>
>>> Routers ignore RA in most instances ( unless they are acting as a
>>> host on what is clearly an upstream interface, and they need to
>>> configure a prefix for use on the upstream interface e.g. on an ISP
>>> link)
>>>
>>> Even in this case why would the RA require a different next hop (my
>>> real confusion is why this option is needed at all)
>>>
>>> Homenet is not following this path for prefix distribution/learning
>>> between LAN interfaces of Homenet devices (one of the use cases of
>>> the draft). Two smartphones peering would run HNCP to learn
>>> prefixes.... Not RA based mechanisms.
>>>> A smartphone Router would send an RA on its bluetooth interface
>>>> containing the prefix of its WiFi interface.
>>> This was already extensively discussed when producing 464xlat.....
>>>
>>>> An On-Board Unit Router would send an RA on its 802.11p
>>>> (vehicle-to-vehicle) interface containing the prefix of its
>>>> wired-Ethernet interface.
>>>>
>>>> Alex
>>>
>>> In general, I can certainly appreciate the need for a SADR
>>> equivalent extension to 4191. But I'm mystified by the need for the
>>> additional complexity contained in this draft. And I'm genuinely
>>> missing how receiving nodes would process and validate the new
>>> options. I.e. The conceptual host model of 4191.
>>>
>>
>

-- 
Regards,
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 3 Mar 2015 11:25:34 -0600

>> the other link (immediate next-hop).

Agreed, this is the case in VPN Router use case. Maybe there are other
use cases that Alex is interested which I am not much informed about
yet.

>> That is a brokeness situation.

I did not say that 3GPP Router or PGW advertises next hop for use on
other interfaces. That is completely wrong interpretation of Ray, Ray
please check my mail. 3GPP router comes up after the next hop is given
to the host.
How can both of you argue on such wrong terms, please, please.

> Well it's pretty trivial to come up with problems. RA was designed to work
> over a single link, to communicate next hop information between an on-link
> router and an on-link host.
>
> if you have 4 such devices (Router_A, Router_B, Router_C, Router_D) behaving
> in the same way, connected say by Ethernet or an other multipoint segments
> [E1 ..E5] and with Prefix P1 on the ISP link, you have
>
> ISP router ---E1-P1--- Router_A --- E2 --- Router_B --- E3 --- Router_C ---
> E4 --- Router_D --- E5
>
> Now connect E5 to E2, either temporarily or permanently. Router_B has no way
> of differentiating between an update from Router_D or an update from
> Router_A for Prefix P1.
> reason. Poor man's routing protocols (like RA) will inevitably break down
> when faced with real world topologies.
>
> extensive information than is currently contained in RA packets, in which
> case, why not just deploy a proper routing protocol in the first place?
>>
>>
> garbage from the WAN link if it can cause an amplification attack on the LAN
> see e.g. https://tools.ietf.org/html/rfc6583.
>
>> Alex

Regards,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2015 15:34:12 +0100

Le 02/03/2015 22:47, Ray Hunter a écrit :
[...]
>>> How does the receiving node know that the next hop target is to
>>> be found on another interface on the receiving host (again
>>> there's no interface tag in the proposed option)?
>>
>> table with next-hop containing the src of the RA.  The receiving
>> node does not run apps.
>>
> And why not? Are these devices so specific that they'll never ever
> be extended?

Ok, there may be some applications that could run on these routers.

But a solution to this problem should not rely on an application
choosing the right source address.

A router's operation is just fast forwarding based on dst, not any more
thinking about it.

>> Another node (a laptop in the car) uses its default route towards
>> the 'receiving node' that we talk above.
>>
>> router advertises an RA about another router outside the 3gpp
>> network. That is a brokeness situation.
>>
>>> (assuming the advertised next hop actually contains garbage, and
>>> is unreachable)
>>
>>  occur.  Otherwise stating it just as such may make think of
>> speculation. Yes, good in general to avoid non-optimal routing,
>> but it does not exist everywhere.
>
> Well it's pretty trivial to come up with problems. RA was designed
> to work over a single link, to communicate next hop information
> between an on-link router and an on-link host.
>
> information. RA doesn't contain explicit timing or topology
> versioning information.
>
> So taking your use case of a smart phone advertising a route to its
> wifi interface over bluetooth.....
>
> ISP router ---E1-P1--- Router_A --- E2 --- Router_B --- E3 ---
> Router_C --- E4 --- Router_D --- E5
>
> Now connect E5 to E2, either temporarily or permanently.

Whomever allows that connection to happen is making a mistake at a layer
below IP.  The subnet structure should reflect perfectly the link structure.

In vehicular networks a wrong link connection rarely happens because of
physical constraints: the range of each link is limited by the
obstructing vehicles.  One couldn't set 1000 cars in one 802.11p range
(whereas one could link 1000 computers with one single Ethernet cable).

But, I agree with you that it may appear.

> Router_B has no way of differentiating between an update from
> Router_D or an update from Router_A for Prefix P1. The "metric" in
> RA is simply high medium or low. And that is a local preference. Not
>  inherited or determined via other RA updates.

Well, at first there could be no way of differentiating, but at a second
thought there may be some: in small networks each Route Advertisement
can have its history log of propagation; a receving router may look at
an RA and decide whether it has already received this info, or whether
it is new.

This is easy to do with linear structures like in vehicular networks.
They are not arbitrary graphs needing complex algorithms like what OSPF
can do.

> Similarly, Prefix 1 might be learned via being directly connected,
> or it might be learned via a routing protocol. Router_B has no way
> of differentiating the origin of the information: it just receives
> reachability information.
>
> And RA timing is only used for the next hop, which means Router_D
> has no idea of the current status of E3 or E2.
>
> Well established routing protocols contain this extra information
> for a reason.

YEs, but they're made to deal with complex structures, not simple
structures like the linear vehicular networks.

They require additional software to be put on devices.

They're bullet-proofed against situations which may never occur.

> Poor man's routing protocols (like RA) will inevitably break down

Yes, but real-world topologies in particular domains are not as complex
as the OSPF routing protocols can deal with.  They may be much smaller
and simpler than complex campus LANs.

Even in places where full-blown routing protocols are employed, it's
sysadmins who really make sure link-layer loops do not appear.

> which case, why not just deploy a proper routing protocol in the
> first place?

The simplest structures in vehicular networks don't need more than
prefix-of-other-link in RA.

For example, current ambitious deployments of vehicle-to-vehicle
communications involve 3 _three_ vehicles: truck platooning.  The trains
(wagon-to-wagon communications, WiFi hotspot per wagon) will never
separate and never loop.

In such structures, OSPF represents more of a burden of software
deployment and maintenance, rather an advantage of dealing with loops in
complex graphs: there are no complex graphs.

>> Amplification attack - yes we need to avoid an exponential growth
>> of routing messages or of routing table entries provoked by the
>> dynamic nature of mobility patterhs of devices such as vehicles.
>> But a receiving node does not perform ND on all of its interfaces
>> to discover the proposed next hop.  A receiving node does just
>> NS/NA for the src of the RA it received, on the interface it
>> received it; that src address is also present on that link.  I do
>> not propose to set garbage in the next-hop field of an RA.
>>
> Of course you won't send garbage in RA messages. But attackers will
> send garbage from the WAN link if it can cause an amplification
> attack on the LAN see e.g. https://tools.ietf.org/html/rfc6583.

Ok, this should be secured.

Alex

>>>>>>>>> tethered to one smartphone would need to communicate
>>>>>>>>> to another Host tethered to the other smartphone. In
>>>>>>>>> this case, one smartphone (Router) would need to
>>>>>>>>> point a route with the next hop at the other
>>>>>>>>> smartphone (Router).
>>>>>>>>>
>>>>>>> They assume some route is already in place (the route
>>>>>>> from a Host to a Router) and that another one should be
>>>>>>> suggested - _re_-direct.
>>>>>>>
>>>>> Sorry, I dont understand why you ask this?  Please clarify
>>>>> the question.
>>>>>
>>>>> Until then here's an answer about what I think the question
>>>>> is not clear.
>>>>>
>>>> Routers ignore RA in most instances ( unless they are acting
>>>> as a host on what is clearly an upstream interface, and they
>>>> need to configure a prefix for use on the upstream interface
>>>> e.g. on an ISP link)
>>>>
>>>> Even in this case why would the RA require a different next
>>>> hop (my real confusion is why this option is needed at all)
>>>>
>>>> distribution/learning between LAN interfaces of Homenet
>>>> devices (one of the use cases of the draft). Two smartphones
>>>> peering would run HNCP to learn prefixes.... Not RA based
>>>> mechanisms.
>>>> equivalent extension to 4191. But I'm mystified by the need
>>>> for the additional complexity contained in this draft. And I'm
>>>>  genuinely missing how receiving nodes would process and
>>>> validate the new options. I.e. The conceptual host model of
>>>> 4191.
>>>>
>>>
>>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2015 15:57:17 +0100

Le 03/03/2015 18:25, Behcet Sarikaya a écrit :
[...]

>>>> advertised from another interface on the sending router
>>>> (there's no interface tag in the proposed option)? [use case
>>>> given by you of a smart phone advertising its wifi prefix via
>>>> the bluetooth interface]
>>>
>>>
>>> Well the receiving node does not need the src address of that
>>> other interface, because it is not in direct contact with it. It
>>> needs the src address of the interface that sends the RA: through
>>> it it will reach the other link (immediate next-hop).
>
> Agreed, this is the case in VPN Router use case. Maybe there are
> other use cases that Alex is interested which I am not much informed
>  about yet.

If this is a question, I can say that currently there are two use-cases:
smartphone-to-smartphone and vehicle-to-vehicle communications.

I can not detail the first, but I can detail the second.

[...]

>>> The receiving node receives a prefix and installs it in its
>>> routing table with next-hop containing the src of the RA.  The
>>> receiving node does not run apps.
>>>
>>>> [use case given by Bechet of a 3gpp router advertising next
>>>> hop addresses for use on the wireless interface on the
>>>> receiving node when connected to a VPN router]
>>>
>>>
>>> That is a use-case to which I dont agree.  NEver in practice a
>>> 3gpp router advertises an RA about another router outside the
>>> 3gpp network. That is a brokeness situation.
>
> please check my mail. 3GPP router comes up after the next hop is
> given to the host. How can both of you argue on such wrong terms,
> please, please.

Let me try to help clarify: do you mean that one Router will send an RA
containing a 'next-hop' address which is ifconfiged on another router?

Alex
[...]

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Mar 2015 15:53:16 -0600

Alex, it is described in the draft that I published a few days ago,
draft-sarikaya-6man-sadr-overview-05.

As I mentioned, I can add a few sentences on your use case there,
hopefully after the draft adopted as WG draft.

Regards,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2015 18:48:45 +0100

Maybe separate the use-case text away from a solution draft?

Alex