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

[Alexandru Petrescu <[e-mail]>]

Le 25/02/2015 14:06, Ray Hunter a écrit :
>> Alexandru Petrescu <mailto:[e-mail]> 24
>> February 2015 16:18 Le 23/02/2015 17:40, V6ops a écrit :
>>>
>>>
>>>> On 23 Feb 2015, at 10:55, Alexandru Petrescu
>>>> <[e-mail]> wrote:
>>>>
>>>> Le 20/02/2015 21:46, V6ops a écrit :
>>>>>
>>>>>
>>>>>> On 20 Feb 2015, at 17:51, Alexandru Petrescu
>>>>>> <[e-mail]> 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.  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.

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.

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.

Alex


>> Alex
>>
>>
>> V6ops <mailto:[e-mail]> 23 February 2015 17:40
>>> On 23 Feb 2015, at 10:55, Alexandru
>>> Petrescu<[e-mail]>  wrote:
>>>
>>> Le 20/02/2015 21:46, V6ops a écrit :
>>>>> On 20 Feb 2015, at 17:51, Alexandru Petrescu
>>>>> <[e-mail]>  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.
>>
>