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

[Alexandru Petrescu <[e-mail]>]

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'
draft-petrescu-autoconf-ra-based-routing
with use-cases issued from the vehicular communications world;
and other similar mechanisms described in
draft-pfister-moving-net-autoconf-00
draft-jhlee-mext-mnpp-00
draft-hampel-mext-ro-without-ha-00

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

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

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

Alex