Subject: Re: Source Address Dependent Routing and Source Address Selection for IPv6

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 3 Feb 2015 11:28:27 -0600

Hi Ray,

On Sat, Jan 31, 2015 at 9:57 AM, Ray Hunter <[email-masked]> wrote:
>> Behcet Sarikaya <mailto:[email-masked]>
>> 31 January 2015 00:28
>> Folks,
>> Mobility in home network is out of scope with this draft.
>> Maybe also that should be discussed in homenet.
>>
>> Regards,
>>
>> Behcet
>>
>> On Fri, Jan 30, 2015 at 2:55 PM, Manfredi, Albert E
>
>
> RFC7084 only covers the situation of a single ISP customer edge router, so
> the described situation cannot occur in any existing IETF-standardised set
> ups. Only Homenet covers multiple ISP routers connected to one user LAN
> shared with end hosts.

Agreed.

>
> So you seem to be suggesting creating a new RA or DHCPv6 option that has to
> be implemented in every single end-host operating system for the solution to
> be able to work, and it won't even solve the real operational problems that
> will occur in Homenet?

The homenet scenario was suggested by Pierre, please check his mail in
the archive
http://www.ietf.org/mail-archive/web/ipv6/current/msg21632.html

>
> IMVHO a better solution to the problem described in this draft is that when
> a "mis-directed packet" arrives at a router performing BCP38 filtering, if
> the router is SADR capable, and the device has learned a SADR route via
> another SADR router that includes the relevant source prefix, the receiving
> device should prefer the SADR route over the destination-based-only route
> and forward the packet to the other ISP router rather than via its own
> default route, and SADR-aware routers SHOULD NOT send an ICMPv6 redirect if
> that ICMPv6 redirect would only be triggered by the presence of SADR.
>
> This to avoid filtering the packet on the egress interface to the ISP not
> delegating the source prefix, or causing incorrect ICMP redirection entries
> in end hosts. That may mean forwarding a packet back out on the inbound
> interface to another ISP router, but so what? This advised behaviour would
> only require an update to SADR aware routers to perform a form of policy
> based routing on ingress (nothing dramatically new here AFAICs),

I can add some text to cover the above, please suggest your text.

Regards,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Feb 2015 18:52:09 +0100

Le 22/01/2015 03:13, Lorenzo Colitti a écrit :
> On Thu, Jan 22, 2015 at 6:42 AM, Behcet Sarikaya
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Referring to Section 5, which solution approach WG prefers? RA
> options as in Section 5.2? Section 5.3?
>
>
> I feel strongly that configuration option that allows a router to
> specify another on-link next hop (or, even worse, a next hop on
> another interface) is a bad idea because it breaks the fate-sharing
> properties provided by RAs.

Fate-sharing principle is old and good in some context.  For RA, the sad
fate means when router fails its route will so too, to share the same
fate; the happy fate is  when route is present it's because the router
is up.  According to the principle one couldnt have a route present but
the router absent, or vice-versa.  This makes network debuggin easy,
among others.

But, one of course may doubt how does this apply beyond just one Router?
  The advertised prefix may be up, the Router as well, yet the whole path
to the DFZ may fail - where is fate sharing in this case?

In related contexts, many Redirection semantics were added which
dissolve this fate-sharing effects on the targets (ICMP, DNS, HTTP,
others) yet prove successful in deployment.

For these reasons I don't understand why fate-sharing is still invoked
as an argument against using DHCP for Routing, or against RA for
printers for that matter.

I wonder whether invoking this principle does not go beyond a form of
unreasonable belief.

Alex

>
> If all that is necessary is a means to tell the host what source
> address to prefer for what prefixes, then we already have a DHCP
> option for that.
>
> Looking at the scenarios, I don't see anything that requires any new
>  work to solve.
>
> Figure 1: Case 1: rtr1 and rtr2 are connected to different interfaces
> on the host (e.g., wifi and 3G), This is solved by rule 5 in RFC
> 6724. Case 2: rtr1 and rtr2 are connected to the same interface on
> the host. This is solved by SADR forwarding between rtr1 and rtr2
> with no host changes.
>
> Figure 2: solved by implementing SADR in the router. The router
> already has the information it needs. In the case of specialized
> address routing, that's solved using the DHCPv6 address selection
> policy option (RFC 7078).
>
> Figure 3: Same as case 2 in Figure 1; solved by rule 5 in RFC 6724.
>
> Figure 4: Same as case 1 in Figure 1; solved by SADR forwarding
> between rtr1 and rtr2. Better performance if the host implements rule
> 5.5 in RFC 6724.
>
> Figure 5: Solved by SADR forwarding between rtr, rtrE and rtrF.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Feb 2015 09:57:47 +0900

On Wed, Feb 4, 2015 at 2:52 AM, Alexandru Petrescu <
[email-masked]> wrote:

> as an argument against using DHCP for Routing
>

The reason it is invoked is because experience in IPv4 shows that the lack
of this fate-sharing property forces network operators to provide
reliability using other means such as VRRP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2015 13:03:12 +0100

Le 04/02/2015 01:57, Lorenzo Colitti a écrit :
> On Wed, Feb 4, 2015 at 2:52 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> The reason it is invoked is because experience in IPv4 shows that the
> lack of this fate-sharing property forces network operators to provide

And is there anything wrong with VRRP?

VRRP exists for IPv6 as well, despite the fate sharing property of RAs.

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Feb 2015 13:06:07 +0100

Alex,

> VRRP exists for IPv6 as well, despite the fate sharing property of RAs.

can I turn this around slightly?
what are the benefits of being able to, in an RA, to advertise a route on behalf of another router?
what problems does it solve?

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Feb 2015 17:34:24 +0100

Le 04/02/2015 13:06, Ole Troan a écrit :
> Alex,
>
>>> <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>> For these reasons I don't understand why fate-sharing is still
>>> invoked as an argument against using DHCP for Routing
>>>
>>>
>>> The reason it is invoked is because experience in IPv4 shows
>>> that the lack of this fate-sharing property forces network
>>> operators to provide reliability using other means such as VRRP.
>>
> can I turn this around slightly? what are the benefits of being able
> to, in an RA, to advertise a route on behalf of another router? what
> problems does it solve?

In a simplest form an RA could advertise a route on behalf of another
interface of same router (not of another router).  The two interfaces
would not share their fate - if one dies the other still advertises its
prefix.

This would solve a number of simple problems with simple IP networks.

A simple network is e.g. two smartphones and their tethered IP devices
exchanging business cards.  Or a smartphone entering an automobile and
sharing its data plan.  Or an entire automobile talking directly to
another automobile, which is still a very simple IP topology needing to
exchange IP routes.

(this is not about DHCP and routing, for which there are other problems
solved like dhcp-only machine-class devices; if only fate-sharing was
not a showstopper).

Alex

An RA advertising a route on behalf of its other interface

> cheers, Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Feb 2015 19:34:28 +0100

Alex,

> solved like dhcp-only machine-class devices; if only fate-sharing was

R1 ----- L1 ----- R2
 |                        |
L2                    L3
 |                        |
H1                    H2

R1/R2 routers (smartphones)
L1/L2/L3 ipv6 links
H1/H2 tethered hosts

R1 should advertise a route for the prefix on L2 on L1 for router R2. R2 should learn the route advertised by R1 and advertise that on L3. then vice versa for the reverse direction.

did I understand you correctly?

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Feb 2015 17:34:09 +0100

> R1/R2 routers (smartphones)

Yes, that topology above is precisely what I tried to describe with the 
problem above.

> R1 should advertise a route for the prefix on L2 on L1 for router
> R2.

Yes.

> R2 should learn the route advertised by R1

Yes

> and advertise that on L3.

No.  It does not need to, because H2 uses R2 as default router.

> then vice versa for the reverse direction.

Yes, simultaneously if possible.

Alex

> did I understand you correctly? >
> cheers,
> Ole
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Feb 2015 17:42:04 +0100

Alex,

> Yes, that topology above is precisely what I tried to describe with the problem above.
> 

right.

> Yes, simultaneously if possible.

R1 and R2 would have to exchange routes.
I don't understand how and where the "3rd party nexthop" attribute would be used in this example?

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Feb 2015 18:12:38 +0100

Le 05/02/2015 17:42, Ole Troan a écrit :
> Alex,
>
>>>>> can I turn this around slightly? what are the benefits of
>>>>> being able to, in an RA, to advertise a route on behalf of
>>>>> another router? what problems does it solve?
>>>>
>>>> In a simplest form an RA could advertise a route on behalf of
>>>> another interface of same router (not of another router).  The
>>>> two interfaces would not share their fate - if one dies the
>>>> other still advertises its prefix.
>>>>
>>>> A simple network is e.g. two smartphones and their tethered IP
>>>> devices exchanging business cards.  Or a smartphone entering an
>>>> automobile and sharing its data plan.  Or an entire automobile
>>>> talking directly to another automobile, which is still a very
>>>> simple IP topology needing to exchange IP routes.
>>>>
>>>> (this is not about DHCP and routing, for which there are other
>>>> problems solved like dhcp-only machine-class devices; if only
>>>> fate-sharing was not a showstopper).
>>>
>>> R1 ----- L1 ----- R2 |                | L2               L3 |
>>> | H1                H2
>>>
>>> R1/R2 routers (smartphones) L1/L2/L3 ipv6 links H1/H2 tethered
>>> hosts
>>
>>> R1 should advertise a route for the prefix on L2 on L1 for
>>> router R2.
>>
>> Yes.
>>

I do not understand either.

The nexthop address should come from the src address of the RA.

I dont understand why the draft-sarikaya-mif-6man-ra-route-02 says:
> In this document we assume that next hop routers are not able to
> provide this information [nexthop address and related route information].

For one, routers in general are always the next hop of somebody else. 
Hence there's no need to name them next hop routers.

And, I am not aware of any kind of link on which routers don't put their 
src address in an RA.

What is meant here?

Instead of a new nexthop attribute, wouldn't it be better to use an ICMP 
Redirect?

Alex

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Feb 2015 18:34:18 +0100

> For one, routers in general are always the next hop of somebody else. Hence there's no need to name them next hop routers.
> 
> And, I am not aware of any kind of link on which routers don't put their src address in an RA.
> 
> What is meant here?
> 
> Instead of a new nexthop attribute, wouldn't it be better to use an ICMP Redirect?

those are my questions too.

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Feb 2015 16:58:47 -0600

Hi Alex,

You are referring to this paragraph in the draft:

Next hop address and related route information may be provided by
   some other means such as directly by the next hop routers.  In this
   document we assume that next hop routers are not able to provide this
   information.  One solution would be to develop an inter-router
   protocol to instigate the next hop routers to provide this
   information.  However, such a solution has been singled out due to
   the complexities involved.

Is there anything wrong with it?

This text was in the draft since Rev. 00 even in an earlier version of
this draft, I don't remember anybody complaining about it.

Regards,

Behcet

On Thu, Feb 5, 2015 at 11:12 AM, Alexandru Petrescu
<[email-masked]> wrote:
> For one, routers in general are always the next hop of somebody else. Hence
> there's no need to name them next hop routers.
>
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Feb 2015 08:47:12 +0100

Behcet,

> Is there anything wrong with it?

yes.
given that the routers must have correct forwarding information regardless. you haven't explained why next-hop routers can't advertise their own routes. please explain that, and give a use case.

> this draft, I don't remember anybody complaining about it.

please check the thread. your proposal for including next-hop has been complained about a lot.

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Feb 2015 09:58:20 -0600

> given that the routers must have correct forwarding information regardless. you haven't explained why next-hop routers can't advertise their own routes. please explain that, and give a use case.

I have explained in Section 6, last paragraph

In home networks, there is possibility of configuring each interface
   of the host using Router Advertisements sent from their next hop
   routers.  This brings the need for a new option, Router Prefix with
   Source Address Option defined in Figure 6 to indicate that any source
   addresses derived from the source prefix will not be subject to
   ingress filtering on these routes supported by this router.

and have defined the option in Section 13 with route prefix, i.e.
Figure 6 for cases where the next hop routers are able to provide the
information. So I am covering both cases.

BTW the use cases are in the overview draft not in the solution draft.

> please check the thread. your proposal for including next-hop has been complained about a lot.

I have made revisions whenever needed, as above.

So the question is my initial assumption was completely wrong and it
would ever never happen in the world?

 My complaint is that people make out of context quotations from my
draft and people do not read the whole document.

Anyway, I learned to deal with all these.

Regards,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 10 Feb 2015 17:47:44 +0100

Behcet,

I looked at the 'overview' draft figures 1..5 but I dont understand 
which needs the next-hop value and why.
https://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-04

I think the question is legitimate: why do we need a next-hop in 
addition to a prefix field in the RA?  If we realize we dont need it 
then a very important part of the 'next-hop RA' draft will be modified: 
the message encoding.
http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-04

There are a few use-cases that can be made, but I am not sure which is 
needed.

1. Links on which routers don't set the src address.  Is there any?  I
    think I remember older cellular links in IPv6 trials zeroing the
    src, but it is no longer the case.
2. multiple Router topologies: this is the equivalent of
    ICMP Redirect and it should be employed that way, it already exists.
3. network debugging: can see the nexthop near the prefix in packet
    dumps.
4. Router-AR-Router:

       AR (Access Router in LTE)
     /    \
    R1    R2 (smartphone)
    |      |
    H      H

AR could tell R1 the specific prefix R2-H is reachable via R2's IP address.

But I am not sure that when R1 receives this route and installs it in 
its routing table it has any effect whatsoever.  I think that route is 
not used, or at best it slows down the search, because R2's IP address 
is not on a link of R1, and it resolves into AR's IP address anyways.

Some reply below:

>     ingress filtering on these routes supported by this router.

Ok, that motivates the src address option, but not a new next-hop 
address field.

> information. So I am covering both cases.

Still not motivating the presence of a Next Hop Address option in 
section 9 of http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-04

> BTW the use cases are in the overview draft not in the solution draft.

Which of figures 1..5 of the 'overview' draft leads to motivate the need 
of a next-hop address field in the RA?

The overview draft says:
>    When the application selects a source address, i.e. the source
>    address is chosen before next-hop selection, even though the source
>    address is a way for the application to select the exit point, in
>    this case that purpose will not be served.  In the presence of
>    multiple default routes, one will be picked, ignoring the source
>    address which was selected by the application because it is known
>    that IPv6 implementations are not required to remember which next-
>    hops advertised which prefixes.  Therefore, the next-hop router may
>    not be the correct one, and the packets may be filtered.

Ok, the selected next-hop may be the wrong one.  But I dont think 
putting a next-hop specific field in an RA solves the problem?  There is 
already a src address in the RA which can be used as a next-hop (it is 
already used so when installing default routes).

The right selection of the next-hop is a matter of calculation in the 
computer, not a matter of data missed from a message.

The source address selection RFCs are all specifying computer behaviour, 
not message contents.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Feb 2015 12:09:40 -0600

Hi Alex,

You are missing the main point, the 5th paragraph in Section 3 is the
one that explains why next hop is needed.

Don't look in other places. As I explained this was the main
assumption in defining the RA option in the next-hop-ra draft.

I hope it is clear now.

Later on, Pierre came up with another scenario of the *upcoming*  home
networks and suggested a solution without the next hop. I revised the
draft (Rev04) and added Fig. 6 and the solution in Section 13.
If I understand well this is what you are supporting. This is also
explained in the overview draft Section 5.2.

I think that the support for Section 5.2 has been good so far.

Now the question is the case with next hop related parameters and the
DHCP solution.

I believe that DHCP solution should be next hop based and I think
there are networks that use DHCP.

Below, I understand that it is your personal opinion that in the
networks you know, all routers almost always send RAs.
I respect your opinion.

I would like to know more cases on this. For example you did not
mention enterprise networks, campus networks, VPN cases, etc.
Why? because I think that the 5th paragraph in Section 3 in the next
hop RA draft was not my invention, I remember hearing these types of
arguments during 6man sessions in IETF.

Regards,

Behcet

On Tue, Feb 10, 2015 at 10:47 AM, Alexandru Petrescu
<[email-masked]> wrote:
> Behcet,
>
> I looked at the 'overview' draft figures 1..5 but I dont understand which
> needs the next-hop value and why.
> I think the question is legitimate: why do we need a next-hop in addition to
> a prefix field in the RA?  If we realize we dont need it then a very
> important part of the 'next-hop RA' draft will be modified: the message
> encoding.
> But I am not sure that when R1 receives this route and installs it in its
> routing table it has any effect whatsoever.  I think that route is not used,
> or at best it slows down the search, because R2's IP address is not on a
> link of R1, and it resolves into AR's IP address anyways.
>
> Some reply below:
>
>
>>> given that the routers must have correct forwarding information
>>> regardless. you haven't explained why next-hop routers can't advertise their
>>> own routes. please explain that, and give a use case.
>>>
>>
> Ok, that motivates the src address option, but not a new next-hop address
> field.
>
> Still not motivating the presence of a Next Hop Address option in section 9
> of http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-04
>
> Which of figures 1..5 of the 'overview' draft leads to motivate the need of
> a next-hop address field in the RA?
>
> The overview draft says:
>>
> Ok, the selected next-hop may be the wrong one.  But I dont think putting a
> next-hop specific field in an RA solves the problem?  There is already a src
> address in the RA which can be used as a next-hop (it is already used so
> when installing default routes).
>
> The source address selection RFCs are all specifying computer behaviour, not
> message contents.
>
> Alex
>
>
>>
>>
>>>>

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Feb 2015 20:02:09 +0100

Behcet,

> assumption in defining the RA option in the next-hop-ra draft.

this one:

sorry, but I don't understand what it is trying to say.
can you try to explain using other words / figure?

please accept the fact that we have read your drafts. have a fair understanding of SADR, but still don't understand what you are trying to achieve...

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 13 Feb 2015 12:39:33 -0600

> can you try to explain using other words / figure?

This text existed since Rev. 0 and even before. Why is this question
being posed now? Maybe answering a question with a question, sorry
about that.

I covered the reverse case in Section 6,

 So again, it is puzzling for me if you are saying that the reverse
case is the only case and the hosts are always configured by their
next hop routers using RAs and thus the hosts get the next hop address
from the source address of the RA. For example DHCP is never used,
etc.

Can you clarify that, Ole?

As far as I understand, Lorenzo's issue with the original assumption
was the fate sharing and the answer for that is VRRP which is widely
deployed in commercial routers. I can add some text to that effect in
the next rev.
If you have other suggestions, please do let me know.

Regards,

Behcet

---

From: Ole Troan <[email-masked]>
Date: Fri, 13 Feb 2015 20:49:34 +0100

Behect,

> being posed now? Maybe answering a question with a question, sorry

You may find that the question keeps being raised until you give it an answer, or modify your draft.
I asked this the first time just after IETF91 on November 17th. See message <[email-masked]>

As far as I can see all my objections still apply to the latest draft.

> from the source address of the RA. For example DHCP is never used,

Correct.

> If you have other suggestions, please do let me know.

Remove everything but a single S-RIO from the draft.

My apologies for having spent so much of the working group's time on this, I'll leave this matter for now.
We can pick it up live in Dallas if you must.

Best regards,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 16 Feb 2015 11:13:19 -0600

Hi Ole,

> As far as I can see all my objections still apply to the latest draft.

I think you gave a wrong link :-)

Never mind, I found your mail,
http://www.ietf.org/mail-archive/web/ipv6/current/msg21513.html
in which your first question was about the next hop.

Here is my answer, sorry for the delay.

In Section 3 of next-hop-ra draft we made it clear that RS-RA type of
host router communication is used.
One scenario is VPN based access. The host is using a VPN router at
the company and has multiple interfaces. The hosts sends RS and VPN
router configures the host using an RA and in the RA, it has to tell
the host that its next hop router is e.g. BNG for Wi-Fi interface and
PGW for LTE interface. It has to give source prefixes for each network
for SADR apart from the route prefixes.

We clarified the need for source prefixes in SADR overview draft, I
think no one questioned route prefixes so far. So we are OK.

Regards,
Behcet

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 10:34:41 +0900

> for SADR apart from the route prefixes.

I don't see how that would work.

If the BNG and PGW routers are willing to forward traffic to those
prefixes, they can simply send RAs with RFC 4191 RIOs for those prefixes.
If they are not willing to forward traffic to those prefixes, then
specifying them as next hops won't do anything useful - the packets will
just get dropped.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Feb 2015 16:15:49 -0600

On Mon, Feb 16, 2015 at 7:34 PM, Lorenzo Colitti <[email-masked]> wrote:
> If the BNG and PGW routers are willing to forward traffic to those prefixes,
> they can simply send RAs

We are talking about routers that do not send unsolicited RAs. They
need an RS to send an RA. The link type is not a shared link but a
point-to-point link.

> with RFC 4191 RIOs for those prefixes.

In fact an earlier version of next-hop-ra draft was called 4191bis. We
are trying to improve RFC 4191 for SADR and next hop.

> If they are
> not willing to forward traffic to those prefixes, then specifying them as
> next hops won't do anything useful - the packets will just get dropped.

No this needs to be avoided of course, i.e. the hosts trusts the
router that sends the RA.

Regards,

Behcet

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Feb 2015 10:14:07 +0900

On Wed, Feb 18, 2015 at 7:15 AM, Behcet Sarikaya <[email-masked]>
wrote:

> prefixes,

No, that doesn't work.

You can't run a network without unsolicited RAs. The maximum standard value
for an RA lifetime is 9000 seconds, and the packet format only contains a
16-bit number, so the maximum value that can be communicated is 65535
seconds.

Do you have another use case?

---

From: Ray Hunter <[email-masked]>
Date: Wed, 18 Feb 2015 14:26:08 +0100

Lorenzo Colitti wrote:
> On Tue, Feb 17, 2015 at 2:13 AM, Behcet Sarikaya 
> prefixes, they can simply send RAs with RFC 4191 RIOs for those 
> prefixes. If they are not willing to forward traffic to those 
> prefixes, then specifying them as next hops won't do anything useful - 
> the packets will just get dropped.
I'm wary of any mechanism where one router informs an end host of some 
information on behalf of another router.

It brings up all sorts of issues with the validity and timeliness of 
that information.

I thus agree with Lorenzo: if a router is prepared to forward some 
traffic, it should advertise that fact itself.

-- 
Regards,
RayH

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2015 17:22:24 +0100

Le 18/02/2015 02:14, Lorenzo Colitti a écrit :
> On Wed, Feb 18, 2015 at 7:15 AM, Behcet Sarikaya
>> prefixes, they can simply send RAs
>
> You can't run a network without unsolicited RAs. The maximum standard
>  value for an RA lifetime is 9000 seconds, and the packet format only
>  contains a 16-bit number, so the maximum value that can be
> communicated is 65535 seconds.
>

I do not necessarily support/or not the BNG/PGW use-case, but:

- even though there are _router_ lifetimes in the RA, the corresponding
   route entries in the RT may last to infinity, as there's no
   correspondence between the two.

- the networks I am interested in may last anywhere from a few seconds
   to minutes to hours, and then disband.

For debugging reasons, it's always useful to trigger sending an RS.  But
even wide implementations dont offer this facility to the programmer -
one has to craft it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2015 17:25:36 +0100

> are trying to improve RFC 4191 for SADR and next hop.

My point of view is to improve RFC4191 for Routers (beyond currently 
specified for Hosts).

Even if improved for SADR, RFC4191-SADR will be unuseful when using it 
on a Router: it doesnt touch the src address.

> router that sends the RA.

Yes, that would be mis-configuration.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Feb 2015 11:21:35 -0600

On Wed, Feb 18, 2015 at 7:26 AM, Ray Hunter <[email-masked]> wrote:
> Lorenzo Colitti wrote:
>
>> On Tue, Feb 17, 2015 at 2:13 AM, Behcet Sarikaya <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> prefixes, they can simply send RAs with RFC 4191 RIOs for those prefixes. If
>> they are not willing to forward traffic to those prefixes, then specifying
>> them as next hops won't do anything useful - the packets will just get
>> dropped.
>
> It brings up all sorts of issues with the validity and timeliness of that
> information.
>
> I thus agree with Lorenzo: if a router is prepared to forward some traffic,
> it should advertise that fact itself.

Ray, we are talking about VPN routers. They install a lot of routes on
the hosts.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Feb 2015 11:25:02 -0600

On Wed, Feb 18, 2015 at 10:25 AM, Alexandru Petrescu
<[email-masked]> wrote:
> Even if improved for SADR, RFC4191-SADR will be unuseful when using it on a
> Router: it doesnt touch the src address.

What does this mean? Did we say that the router touches the src address?

I'll appreciate text modification proposal for the overview draft or
the solution draft.
I have revised the overview draft and will submit Rev 05 soon. I can
add some more if proposed.

Regards,

Behcet

---

From: V6ops <[email-masked]>
Date: Fri, 20 Feb 2015 11:03:28 +0100

>> On 19 Feb 2015, at 18:21, Behcet Sarikaya <[email-masked]> wrote:
>> 
Sure VPN routers can install a lot of routes on a host. Standard practice today already.

But why would one router need to point routes with the next hop pointing at another router?

I don't think that use case has been properly explained.

Especially e.g. how that route would be expired if the target next hop router becomes unreachable, or there were multiple next hop targets.

And why would a host trust such a route over what it has learned locally?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Feb 2015 12:54:03 +0100

> What does this mean? Did we say that the router touches the src address?

It means that if the goal is to make RFC4191 work on Routers (instead of 
Hosts) then there is no problem of src address selection.  The src 
address selection is a problem with applications, and they wouldn't run 
on Routers.

Source address selection is an important part of Source Address and 
Destination-based Routing (SADR), no?  I got it wrong?

> add some more if proposed.

I will look at that.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Feb 2015 12:58:34 +0100

Le 20/02/2015 11:03, V6ops a écrit :
>>> On Wed, Feb 18, 2015 at 7:26 AM, Ray Hunter <[email-masked]>
>>> wrote: Lorenzo Colitti wrote:
>>>
>>>> One scenario is VPN based access. The host is using a VPN
>>>> router at the company and has multiple interfaces. The hosts
>>>> sends RS and VPN router configures the host using an RA and in
>>>> the RA, it has to tell the host that its next hop router is
>>>> e.g. BNG for Wi-Fi interface and PGW for LTE interface. It has
>>>> to give source prefixes for each network for SADR apart from
>>>> the route prefixes.
>>>>
>>>>
>>>> If the BNG and PGW routers are willing to forward traffic to
>>>> those prefixes, they can simply send RAs with RFC 4191 RIOs for
>>>> those prefixes. If they are not willing to forward traffic to
>>>> those prefixes, then specifying them as next hops won't do
>>>> anything useful - the packets will just get dropped.
>>>
>>> I'm wary of any mechanism where one router informs an end host of
>>> some information on behalf of another router.
>>>
>>> It brings up all sorts of issues with the validity and timeliness
>>> of that information.
>>>
>>> I thus agree with Lorenzo: if a router is prepared to forward
>>> some traffic, it should advertise that fact itself.
>>
>>
>> Ray, we are talking about VPN routers. They install a lot of routes
>> on the hosts.
>>
>> Regards,
>>
>> Behcet
>

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.

Alex

> Especially e.g. how that route would be expired if the target next
> hop router becomes unreachable, or there were multiple next hop
> targets.
>
>>> -- Regards, RayH

---

From: Ole Troan <[email-masked]>
Date: Fri, 20 Feb 2015 13:23:34 +0100

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

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Feb 2015 17:51:38 +0100

> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Feb 2015 14:16:28 -0600

> Especially e.g. how that route would be expired if the target next hop router becomes unreachable, or there were multiple next hop targets.

I think this issue is out of scope.

> And why would a host trust such a route over what it has learned locally?

The host has not learned anything locally due to RS/RA communication.

Behcet

---

From: V6ops <[email-masked]>
Date: Fri, 20 Feb 2015 21:46:46 +0100

> On 20 Feb 2015, at 17:51, Alexandru Petrescu <[email-masked]> wrote:
> 
> 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?

---

From: V6ops <[email-masked]>
Date: Fri, 20 Feb 2015 22:04:10 +0100

> On 20 Feb 2015, at 21:16, Behcet Sarikaya <[email-masked]> wrote:
> 

I disagree. The use case described seems to me to be an RA arriving on one (VPN) interface that installs a route on another interface: either 3gpp or lte. Given RA is link local scope and the next hop address would also presumably be link local, but on another interface, I find that problematic.

> The host has not learned anything locally due to RS/RA communication.
So what exactly is the use case for this option of a router being able to send an RA advertise a next hop to another router?

To me a phone is just a computer that sometimes sends some voice packets. And all the fancy radio gear just provides point to point links at the end of the day.

To me the management model is orthogonal to the tech. The IETF shouldn't be assuming or enforcing a trust model when designing protocols. It's equally valid to assume a phone is a multi homed host living in multiple ASes as it is to assume the phone exists entirely within a provider AS. So the drafts inclusion of a specific trust model is problematic to me.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2015 10:55:04 +0100

Le 20/02/2015 21:46, V6ops a écrit :
>>>> 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.
>>>
>> 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
>>
>

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.

A smartphone Router would send an RA on its bluetooth interface
containing the prefix of its WiFi interface.  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

---

From: V6ops <[email-masked]>
Date: Mon, 23 Feb 2015 17:40:04 +0100

> On 23 Feb 2015, at 10:55, Alexandru Petrescu <[email-masked]> wrote:
> 
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.
> containing the prefix of its WiFi interface.  
This was already extensively discussed when producing 464xlat.....

> An On-Board Unit Router

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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Feb 2015 16:18:54 +0100

Le 23/02/2015 17:40, V6ops a écrit :
>>>>>> 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).
>>>>>>
>>>> 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.
>>>>
>>>> they may not be connected to anything else prior to connecting
>>>> to each other, so they wouldnt issue Redirects.
>>>>
>>>> Alex
>>>>
>>>
>> 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.
>

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.

> 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

---

From: Ray Hunter <[email-masked]>
Date: Wed, 25 Feb 2015 14:06:17 +0100

> Alexandru Petrescu <mailto:[email-masked]>
> 24 February 2015 16:18

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

Agreed.

> 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).
> The reason I react on this thread is only related to having other links'
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:[email-masked]>
> 23 February 2015 17:40
>> On 23 Feb 2015, at 10:55, Alexandru Petrescu<[email-masked]>  wrote:
>>

-- 
Regards,
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Feb 2015 16:15:32 -0600

Hi Ray,

> with respect to the existing semantics of 4191).

We have strong ES host model, do we need anything else?

>>> options. I.e. The conceptual host model of 4191.

 again strong ES host model

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

We are talking about real environments and in such cases, the host is
not directly connected to the router.
There are many nodes in between. Like UE and PGW in LTE network or
Host and BNG in home/enterprise networks.

There are so many details, you can check from the literature.
Tunneling is heavily used, RS/RA type of router interactions are used.

Regards,

Behcet

---

From: V6ops <[email-masked]>
Date: Thu, 26 Feb 2015 17:59:56 +0100

> On 25 Feb 2015, at 23:15, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi Ray,
> 
> 
> 
More confused than ever.

On the one hand you invoke the ES host model, which strongly links addresses to a physical interface.

And yet one of the use cases is a phone learning the next hop for the wifi interface via an RA received on the LTE interface.

It would seem logical to me in a strongly bound host model that a host would ignore route information received on interface 1 pertinent to interface 2. Especially as I've read that the trust model in LTE is provider specific. I also don't know the details of how Apple ties a route to an interface, but I have read recently that routing tables are indeed interface specific.

Another point is that the next hop address contained in a Next Hop Address option will be a link local address. Yet the scope of a link local address is the physical link. Receiving a link local address next hop via another link to me seems to be highly questionable re: address scoping. Who's to say that link local addresses aren't duplicated over multiple interfaces? AFAICS Link-local addresses are usually not guaranteed to be unique beyond a single network segment.

I guess I just need to drop out of commenting this draft.

> Tunneling is heavily used, RS/RA type of router interactions are used.
I'm used to dealing with networks with multiple layers of encapsulation, switching, tunneling, and routing. 

But a router is always a router.......

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Feb 2015 15:00:51 -0600

Hi Ray, all,

> It would seem logical to me in a strongly bound host model that a host would ignore route information received on interface 1 pertinent to interface 2. Especially as I've read that the trust model…

I agree with all this. So RA sent to each interface contains
configuration for that interface which does not negate what you say.

> Another point is that the next hop address contained in a Next Hop Address option will be a link local address. Yet the scope of a link local address is the physical link. Receiving a link local ad…

Yes, I agree. We can add these concerns to the draft, no problem.

> I guess I just need to drop out of commenting this draft.

No, please don't.

Now a point to the WG:

I posted Revision 05 of my draft entitled
Source Address Dependent Routing and Source Address Selection for IPv6  Hosts

It is an informational draft. I think that there is good support for
SADR which is described in Section 5.2 on Page 10. In Rev. 05 I added
some text on the next hop. Next hop issue has only recently been
discussed. I added some justification and also the concerns to Section
5.3 on Page 11.

I asked Ole to make a WG adoption call on this analysis draft.
Let's work on it, put all arguments there as a WG draft and then use
that as a guide to decide on the solution.

Thanks,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2015 14:23:25 +0100

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

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

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.

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

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

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

Noted, but disagreeing.

> Quote: "A node MUST silently discard any received Router
> Advertisement messages that do not satisfy all of the following
> validity checks:
>

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.

> 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:[email-masked]> 23 February 2015 17:40
>>> On 23 Feb 2015, at 10:55, Alexandru
>>> Petrescu<[email-masked]>  wrote:
>>>
>>>>>>> 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).
>>>>>>>
>>>>>  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
>>>>>