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

[Ray Hunter <[e-mail]>]

> 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.
>
> 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.
> draft-jhlee-mext-mnpp-00
Has a new ICMP type code for MNPP Solicitation and MNPP Advertisement 
messages. It won't affect generic nodes.
> draft-hampel-mext-ro-without-ha-00
contains no new options AFAICS.

My point is that none of these proposed extensions will likely be 
processed by older nodes, or wired nodes, or Homenet nodes, so backwards 
compatibility and having to update generic (wired) nodes is less of an 
issue for me.

>
>> 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).
>
>> 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.

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."

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]

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)

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)?
[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]

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)
> 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.
>

-- 
Regards,
RayH