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

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 Jan 2015 15:42:52 -0600

Hi all,

On the solutions to the problem and issues discussed in this draft:
http://tools.ietf.org/id/draft-sarikaya-6man-sadr-overview-04.txt

we would like to hear from the working group. Referring to Section 5,
which solution approach WG prefers? RA options as in Section 5.2?
Section 5.3?
Also regarding the corresponding DHCP work, which direction is the
preferred direction?

Your opinions are welcome.

Regards,

Behcet

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 22 Jan 2015 00:44:32 +0000 (UTC)

I think the principles described in RFC5505 are worth following:

"Principles of Internet Host Configuration"
https://tools.ietf.org/html/rfc5505#section-2

More options to configure and more methods to choose from just make things harder to make work and make them break more often.

----- Original Message -----
From: Behcet Sarikaya <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: 
Sent: Thursday, 22 January 2015, 8:42
Subject: Source Address Dependent Routing and Source Address Selection for IPv6

Hi all,

Regards,

Behcet

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Jan 2015 11:13:19 +0900

On Thu, Jan 22, 2015 at 6:42 AM, Behcet Sarikaya <[email-masked]>
wrote:

> Referring to Section 5,

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.

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.

---

From: Ole Troan <[email-masked]>
Date: Thu, 22 Jan 2015 09:38:23 +0100

Behcet,

> Also regarding the corresponding DHCP work, which direction is the

I'm still not convinced that any specific configuration for source based next-hop determination is needed.
until then my preferred direction is to do none of these.

can you please explain in excruciating detail in which case these configuration options (including 3rd party nexthop)  are required?

Best regards,
Ole

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 22 Jan 2015 10:30:34 +0100

Hello Lorenzo, Ole and Behcet,

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

I fully agree there. If another router should be next-hop, then that other router can send RAs by itself.

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

Yes, but if we rely on routers’ capabilities only, we will have suboptimal routing. e.g., the next-hop will send the packet back on the same link. Which would halve the throughput.
And if we rely on redirects, well… Redirects are not source-specific, so we may have redirect ping-pongs between the two routers.

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

Something bugs me in general with the source address selection process.

If we assume the host is dumb, it will first select the next-hop/oif and pick the source address using rule 5 or rule 5.5.
If we assume the host is clever, it will first select the source-address based on the information it has (e.g., DHCPv6 address selection). But how is it supposed to select the next-hop then ? rule 5 and 5.5 solve source address selection when you know the next hop, but not next-hop selection when you know the source address.

In other words, when you say DHCPv6 address selection policy solves the issue, you say the host should select the address based on configuration, which implies that you do that before you pick the next hop.
But when you say rule 5 or 5.5 solve the issue, you assume the next-hop has already been selected. So, picking each figure and propose different solutions which seems to exclude each other seems unfair to me.

Source address selection by the host/application is, IMHO, the simplest approach to upstream selection, as it reduces interface/next-hop/cpe selection to the selection of a single element. Homenet is moving toward this kind of solutions. But once the application or host has chosen the source address, we need some process to select the next hop.

When I ask myself ‘where should we pick the next-hop’… The routing table seems to be the answer. And if we consider we want different next hops depending on the source address, source-dest routing looks like the right thing to do to me. 

Now, either we require hosts to look at PIOs and always add source-routes based on the RAs they receive (which means the router hides things to the host and the host hacks a solution to deal with it - and it may not always work), or we provide a longer-term solution where routers tell the truth to hosts.

I disagree with the overall approach of this draft. I think what we need is a source-specific extension to RFC4191. With only one single new option similar to RIOs but with a source-prefix included.

Cheers,

- Pierre

---

From: Ole Troan <[email-masked]>
Date: Thu, 22 Jan 2015 13:30:15 +0100

Pierre,

> Something bugs me in general with the source address selection process.

I think source address selection bugs a lot of people. encoding what's essentially policy in an RFC...

> If we assume the host is clever, it will first select the source-address based on the information it has (e.g., DHCPv6 address selection). But how is it supposed to select the next-hop then ? rule…

the selection of next-hop is tied to the source address. if you choose the next-hop first, then that will force which set of source addresses you can choose from. if you choose the source address first, that limits the possible next-hops you have. that's essentially what SADR is, right.

> Now, either we require hosts to look at PIOs and always add source-routes based on the RAs they receive (which means the router hides things to the host and the host hacks a solution to deal with i…

I do agree with you that the host learns this information implicitly. I don't see that the network would be able to pass you any _more_ information even though the information was passed explicitly in a new RA option. at least the forwarding algorithm outlines above would still be the same I believe.

> I disagree with the overall approach of this draft. I think what we need is a source-specific extension to RFC4191. With only one single new option similar to RIOs but with a source-prefix included.

it might be useful that the network is much more explicit about "network policy" to the hosts. like some of the information we've talked about with the "prefix properties" draft. e.g. this is a walled garden prefix, this prefix is charged, and so on.
we might have more pressing problems with MHMP though. given that we either need SHIM6, transport layer support (MP-TCP) or application changes to make it work well.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Jan 2015 08:52:16 +0100 (CET)

On Thu, 22 Jan 2015, Ole Troan wrote:

> we might have more pressing problems with MHMP though. given that we 
> either need SHIM6, transport layer support (MP-TCP) or application 
> changes to make it work well.

I also don't know where to start.

Right now source address selection and routing is done "ships in the 
night" which I think is the wrong thing to do. We need to tie together 
what source address is used and what next hop is chosen. Personally I 
think the MIF route here of having implicit PVDs is the best way to go, 
and to do this in the host IP stack. What needs to be changed where when 
it comes to network support of this, how information should be propagated, 
if more information is needed etc, is a discussion that seems to quickly 
get very confused because we haven't even agreed what the end goal is and 
how we want it to work.

A big problem I have with this is that the posix interfaces people 
generally think of are fast becoming close to obsolete, considering all 
the innovation seems to be in vendor-proprietary interfaces by Apple, 
Microsoft and others.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 09:32:26 +0100

Mikael,

> Right now source address selection and routing is done "ships in the night" which I think is the wrong thing to do. We need to tie together what source address is used and what next hop is chosen.

agreed, and I think RFC6724 already implies that. even more so with rule 5.5.

> Personally I think the MIF route here of having implicit PVDs is the best way to go, and to do this in the host IP stack.

from a forwarding perspective, at least if we look at the 'simple' use cases of multi-homing to congruent networks. what do you see MIF adding here?

> What needs to be changed where when it comes to network support of this, how information should be propagated, if more information is needed etc, is a discussion that seems to quickly get very confused because we haven't even agreed what the end goal is and how we want it to work.

if we stick to multi-prefix multi-homing, I think we have a decent set of requirements from RFC3582 and RFC7157.
isn't the goal of MHMP to implement the requirements in 3582?

> A big problem I have with this is that the posix interfaces people generally think of are fast becoming close to obsolete, considering all the innovation seems to be in vendor-proprietary interfaces by Apple, Microsoft and others.

TAPS?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Jan 2015 09:57:25 +0100 (CET)

> from a forwarding perspective, at least if we look at the 'simple' use cases of multi-homing to congruent networks. what do you see MIF adding here?

If my host has three different IP addresses (from different /64s, 
potentially even on different interfaces), my application chooses to use 
one of these, what next-hop is chosen is now depending on routing and 
RFC6724 has nothing to do with it. I want the routing choice to be done 
based on the source address chosen. I consider this part of MIF, but I 
guess a case can be made that it's not. However, it's SADR I'm implying 
here.

> if we stick to multi-prefix multi-homing, I think we have a decent set 
> of requirements from RFC3582 and RFC7157. isn't the goal of MHMP to 
> implement the requirements in 3582?

Ok, I now looked into 7157, and yes, that's exactly what I'm talking 
about. 7157 talks in section 5 of source address selection, next-hop 
selection, and dns server selection, and these are all in what I called 
"PVD" in the MIF context. I want these to be a implicit PVD to which the 
application binds, and then everything happens within that PVD.

For instance, in the homenet scenario, if two routers are announcing 
multiple prefixes, is it enough that the router that has the better path 
to the ISP wherefrom that prefix is coming, is announcing itself as router 
with higher preference than the one that would send traffic from that 
prefix back onto the same link it came from? Should the host send multiple 
RAs, because in the scenario:

       /-- rtr1 --- ISP1
host -
       \-- rtr2 --- ISP2

In the homenet scenario, only one of the routers would announce both 
prefixes (?), meaning if this was rtr1, traffic to ISP2 would always 
bounce via rtr1, which is suboptimal. I'm not sure I like having rtr1 
announcing the route to ISP2 with rtr2 as next-hop, I would prefer if we 
had a tool where rtr2 would communicate to the host that it's a better 
exit for packet with source address of ISP2. Last I checked, in RAs, there 
is an implicit "I am the default gateway for everything". I would like to 
see "I am the $PRIORIRY default gateway for PREFIX" option. It seems this 
is what draft-sarikaya-6man-next-hop-ra is talking about.

So instead of having one router announce another router as next-hop (which 
seems to remove the fate-sharing of RAs with availability of that node), 
can't we have both routers announce themselves with different priorities 
for the respective prefixes based on IGP metric or similar?

>> A big problem I have with this is that the posix interfaces people generally think of are fast becoming close to obsolete, considering all the innovation seems to be in vendor-proprietary interfac…

I don't know what that is.

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 10:31:53 +0100

Mikael,

> If my host has three different IP addresses (from different /64s, potentially even on different interfaces), my application chooses to use one of these, what next-hop is chosen is now depending on routing and RFC6724 has nothing to do with it. I want the routing choice to be done based on the source address chosen. I consider this part of MIF, but I guess a case can be made that it's not. However, it's SADR I'm implying here.

I think we agree on how this should work, so it doesn't so much matter which document it is written in. ;-)

cut and paste from RFC6724:
   Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
   If SA or SA's prefix is assigned by the selected next-hop that will
   be used to send to D and SB or SB's prefix is assigned by a different
   next-hop, then prefer SA.  Similarly, if SB or SB's prefix is
   assigned by the next-hop that will be used to send to D and SA or
   SA's prefix is assigned by a different next-hop, then prefer SB.

I haven't seen any MIF document on host sending rules?

>> if we stick to multi-prefix multi-homing, I think we have a decent set of requirements from RFC3582 and RFC7157. isn't the goal of MHMP to implement the requirements in 3582?
> 
> Ok, I now looked into 7157, and yes, that's exactly what I'm talking about. 7157 talks in section 5 of source address selection, next-hop selection, and dns server selection, and these are all in what I called "PVD" in the MIF context. I want these to be a implicit PVD to which the application binds, and then everything happens within that PVD.
> 
> For instance, in the homenet scenario, if two routers are announcing multiple prefixes, is it enough that the router that has the better path to the ISP wherefrom that prefix is coming, is announcing itself as router with higher preference than the one that would send traffic from that prefix back onto the same link it came from? Should the host send multiple RAs, because in the scenario:
> 
>      /-- rtr1 --- ISP1
> host -
>      \-- rtr2 --- ISP2
> 
> In the homenet scenario, only one of the routers would announce both prefixes (?), meaning if this was rtr1, traffic to ISP2 would always bounce via rtr1, which is suboptimal. I'm not sure I like having rtr1 announcing the route to ISP2 with rtr2 as next-hop, I would prefer if we had a tool where rtr2 would communicate to the host that it's a better exit for packet with source address of ISP2. Last I checked, in RAs, there is an implicit "I am the default gateway for everything". I would like to see "I am the $PRIORIRY default gateway for PREFIX" option. It seems this is what draft-sarikaya-6man-next-hop-ra is talking about.

OK, now you have lost me. in the figure above does host have 2 separate interfaces or 1?

- 2 separate interfaces. host receives RA with ISP1 prefix on interface 1, and RA with ISP2 prefix on interface 2. strong host model ensures appropriate source address is used given chosen next-hop/interface. likewise chosen if the application picks source, then the host picks the appropriate next-hop for the interface the source is attached to.

- 1 single interface. host receives two RAs, one from rtr1 one from rtr2. rule 5.5 will ensure that host picks correct router for given source. there is no need for any collaboration between rtr1 and rtr3.

if there was a rtr3 between host and rtr1/2 then rtr3 must implement SADR forwarding, and the host will have 2 addresses but a single next-hop.

for the purpose of sending packets to congruent networks I don't know what PVDs would add to this puzzle. as far as I can see the host has enough information already to make a choice.

diverging into PVDs; I do think that in a home network, pushing external PVDs all the way to the hosts is a policy issue. in my home network, even though I have multiple ISPs, I have only a single provisioning domain, which is _my_ home network, as I wouldn't let ISPs configure/control hosts/applications directly. 

> So instead of having one router announce another router as next-hop (which seems to remove the fate-sharing of RAs with availability of that node), can't we have both routers announce themselves with different priorities for the respective prefixes based on IGP metric or similar?
> 

http://datatracker.ietf.org/wg/taps/documents/

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Jan 2015 11:10:35 +0100 (CET)

> I haven't seen any MIF document on host sending rules?

I don't know if there is, but I think we're going to need them, for 
instance if we have different prefixes for different functions. Prefix 
properties.

> OK, now you have lost me. in the figure above does host have 2 separate 

I interface.

> - 1 single interface. host receives two RAs, one from rtr1 one from 
> rtr2. rule 5.5 will ensure that host picks correct router for given 
> source. there is no need for any collaboration between rtr1 and rtr3.

Since this is a "homenet", these routers will have decided which one 
should send RAs for the LAN, and only one router will send RAs, but for 
both prefixes.

My idea was to send 4 RAs, one per prefix per router. The same information 
could potentially be sent in a single RA per router in case there is 
enough information in there to discern SADR, implicit "I am default 
gateway" and priority from a different SADR.

That way rtr1 would send RA for ISP1 with high preference, rtr2 would send 
RAs for ISP2 with high preference, RTR1 would send ISP2 prefix with low 
preference, and RTR2 would send ISP1 prefix with low preference. This 
isn't strictly needed or helping in my example network, but imagine a more 
advanced network where there would be multiple paths to one or each ISP.

> if there was a rtr3 between host and rtr1/2 then rtr3 must implement 
> SADR forwarding, and the host will have 2 addresses but a single 
> next-hop.

      +--+rtr3++rtr1+---+ISP1
     |          +
     |    +-----+
  H1++    +                  
     +--+rtr2+-+ISP2         

So lets say rtr2-rtr1 link is really slow. This would mean that 
rtr3-rtr1->ISP1 is to be preferred before rtr2->rtr1->ISP1.

In the homenet case either rtr3 or rtr2 would be default gw for the lan, 
meaning packet flow would be going rtr3->rtr2->ISP2 if rtr3 is the 
handling router for the subnet, or rtr2->rtr3->rtr1->ISP1 if rtr2 is the 
handling router for the subnet.

With my proposal, rtr3 could announce itself as a more optimal router for 
ISP1 prefix, and rtr2 could announce itself as a more optimal router for 
ISP2.

If this is needed or not depends on if one considers an extra routing hop 
being a problem or not.

> http://datatracker.ietf.org/wg/taps/documents/

That seems to be mostly investigation, not defining new APIs? "Submit an 
Experimental document to the IESG specifying one or more methods to 
provide applications with the Transport Services identified by the WG" , 
so this is mostly about doing preparation before defining new APIs?

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 23 Jan 2015 11:33:41 +0100

Ole,

> the selection of next-hop is tied to the source address. if you choose the next-hop first, then that will force which set of source addresses you can choose from. if you choose the source address f…

Yes for the first part. But no for the second. As far as I know, SADR does not tell you anything about how to select the next hop once you selected the source address. This is the role of the routing table. Which may break BCP38. So it looks to me there is something to be done here.

> I do agree with you that the host learns this information implicitly. I don't see that the network would be able to pass you any _more_ information even though the information was passed explicitly…

Your solution would interpret PIOs as source-specific default routes. Depending on the router’s lifetime obviously. 
It would explicitly tie on-link address configuration to routing. Routers would need to modify the PIOs they advertise based on other router’s presence (dynamically updating address configuration which could not change). Routing and address configuration are separated in ND, and I think it is a good thing. It reduces complexity.

Additionally, what if you don’t want a source-specific default route, but a source and destination specific route ? For instance, I have an SP that allows le to reach a single destination prefix. That does not mean it won’t implement BCP38. Why would I have a default route for only a restricted set of destinations ? Maybe I can use the same source address to reach other destinations through a different next-hop.

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 23 Jan 2015 11:43:29 +0100

Hello Mikael,

> I don't know if there is, but I think we're going to need them, for instance if we have different prefixes for different functions. Prefix properties.
> 
> Since this is a "homenet", these routers will have decided which one should send RAs for the LAN, and only one router will send RAs, but for both prefixes.
> 
> My idea was to send 4 RAs, one per prefix per router. The same information could potentially be sent in a single RA per router in case there is enough information in there to discern SADR, implicit "I am default gateway" and priority from a different SADR.
> 
> That way rtr1 would send RA for ISP1 with high preference, rtr2 would send RAs for ISP2 with high preference, RTR1 would send ISP2 prefix with low preference, and RTR2 would send ISP1 prefix with low preference. This isn't strictly needed or helping in my example network, but imagine a more advanced network where there would be multiple paths to one or each ISP.
> 
> So lets say rtr2-rtr1 link is really slow. This would mean that rtr3-rtr1->ISP1 is to be preferred before rtr2->rtr1->ISP1.
> 
> In the homenet case either rtr3 or rtr2 would be default gw for the lan, meaning packet flow would be going rtr3->rtr2->ISP2 if rtr3 is the handling router for the subnet, or rtr2->rtr3->rtr1->ISP1 if rtr2 is the handling router for the subnet.
> 
> With my proposal, rtr3 could announce itself as a more optimal router for ISP1 prefix, and rtr2 could announce itself as a more optimal router for ISP2.
> 
> If this is needed or not depends on if one considers an extra routing hop being a problem or not.

This really looks like the design I have in mind too.

I think all routers connected to the same link should advertise all the PIOs they know about (in homenet case, it means all of them, as HNCP and Prefix Assignment take care of sharing the information).
Then, they would advertise different Source-Specific RIOs with different priorities and prefixes, just like you said.

This way, when a router disappears, not only the host does not deprecate its address (waiting for another router to start advertising the lost PIO), but it can automatically backup the routing the the lower-priority route.

This approach also supports source and destination specific routes.

- Pierre

> That seems to be mostly investigation, not defining new APIs? "Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG" , so this is mostly about doing preparation before defining new APIs?
> 
> --

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 12:04:51 +0100

Pierre,

> Yes for the first part. But no for the second. As far as I know, SADR does not tell you anything about how to select the next hop once you selected the source address. This is the role of the routi…

isn't that just an implementation detail? some host implementations don't use routing tables btw.
my point is that the host has the necessary information already, and that rule 5.5 as far as I can see specifies how the external behaviour should be.

> It would explicitly tie on-link address configuration to routing. Routers would need to modify the PIOs they advertise based on other router’s presence (dynamically updating address configuration w…

hosts don't do routing. the PIO would be tied to next-hop selection. yes.
I don't think it has to be tied to the router's lifetime. when the relevant router expires, then the tie is broken.
rule 5.5 already makes that tie, and I don't see how you can avoid that if you want to ensure that a source address influences next-hop selection.

I don't see why this would imply that one router has to modify what it advertises based on other routers. the PIO isn't routing.

> Additionally, what if you don’t want a source-specific default route, but a source and destination specific route ? For instance, I have an SP that allows le to reach a single destination prefix. T…

yes, that's why I limited my answer to multi-homing to congruent networks.
in the use case we're talking about, that would be solved by an RA with the PIO and the more specific with lifetime = 0 from the other router.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 12:11:53 +0100

Pierre,

> This approach also supports source and destination specific routes.

you could do that.
I think the options we have are:

1) current specifications (rule 5.5, works as I described)
2) Homenet case, all routers advertise all PIOs. depends on redirects
3) Extend RFC4191 with source specific routes
4) Instead of making ND into a routing protocol just make hosts participate in a real RP.

I have argued for 1, from the standpoint that this is what's most likely to get current hosts to implement today, and it works with two independent routers that doesn't support homenet protocols.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Jan 2015 12:52:41 +0100 (CET)

> I have argued for 1, from the standpoint that this is what's most likely to get current hosts to implement today, and it works with two independent routers that doesn't support homenet protocols.

Ok, pasting 5.5 again:

"
"

This is still source address selection. What text handles to which 
next-hop the host should send traffic with this SA? RFC 7157 section 6.2 
has some texts on this, but I don't see it answering the question.

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 13:12:24 +0100

Mikael,

> This is still source address selection. What text handles to which next-hop the host should send traffic with this SA? RFC 7157 section 6.2 has some texts on this, but I don't see it answering the question.

right, this text doesn't say exactly what to do if you pick the SA. but it isn't a big jump to conclude that you can use the same  coupling between source prefix and next-hop.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Jan 2015 13:17:57 +0100 (CET)

On Fri, 23 Jan 2015, Ole Troan wrote:

> right, this text doesn't say exactly what to do if you pick the SA. but 
> it isn't a big jump to conclude that you can use the same coupling 
> between source prefix and next-hop.

Do you expect MIF to say this outright, or is that something we should do 
in 6MAN, or both?

---

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

Hi Pierre,

> I disagree with the overall approach of this draft. I think what we need is a source-specific extension to RFC4191. With only one single new option similar to RIOs but with a source-prefix included.

I am not sure if you read Section 5.2 in this draft and Section 13 in
draft-sarikaya-6man-next-hop-ra-04?
I had these in an effort to satisfy your concerns. Your mails seems to
indicate that you did not even read them.
Poor me :-)

I can see from this long discussion thread that some people, e.g.
Mikael are soliciting all RA based solutions. I am OK with it.
But RFC 7157 which Ole, et al. wrote seems to advocate DHCPv6 based
approach. That was the reason I wrote DHCP solution draft.

Regards,

Behcet

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Jan 2015 08:21:43 +1300

Below...
> approach. That was the reason I wrote DHCP solution draft.

And surely the role of draft-sarikaya-6man-sadr-overview is to set
the context for that choice (or we could do both, which is not actually
forbidden when there is a clear split in the community's preferred practice).

I'm sure Behcet can tune his text to include all the considerations
that have been mentioned, but is there anything seriously wrong
with the analysis of scenarios 1-5?

   Brian

---

From: Ole Troan <[email-masked]>
Date: Sat, 24 Jan 2015 22:21:28 +0100

[...]

> forbidden when there is a clear split in the community's preferred practice).

what makes you say that? RFC7157 sets the context for choosing DCPv6. the use-case was a multi-homed network, with one link to a walled garden, and only some hosts on the link needed to reach the walled garden.

> with the analysis of scenarios 1-5?

yes, there are a number of serious flaws in this document.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Jan 2015 11:37:54 +1300

> what makes you say that? RFC7157 sets the context for choosing DCPv6. the use-case was a multi-homed network, with one link to a walled garden, and only some hosts on the link needed to reach the w…

Sure. In that context DHCPv6 would probably be chosen. But we haven't
made it a MUST in the node requirements. As long as it's a SHOULD
(RFC6434 section 5.9.5) we have to assume there will be hosts without it.

> yes, there are a number of serious flaws in this document.

Well, I'll leave that between you and Behcet. fwiw I think we need
such a document, because the situation is not as clear for
everybody, so the flaws needs to be corrected.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Sun, 25 Jan 2015 09:07:26 +0100

Brian,

> (RFC6434 section 5.9.5) we have to assume there will be hosts without it.

yes, and that's likely something we have to live with.
note that 7157 resulted in a DHCP option to program the source address selection policy table.
that isn't exactly the same as SADR although the two are tightly connected.

> everybody, so the flaws needs to be corrected.

yes, I also think we need such a document. I think Behcet's draft is a good start, but there are a few "red flags" and bugs in there that makes it a hard read. e.g. the 3rd party next-hop.

can we try to agree on the behaviour we desire? let me posit a few suggestions:

1) given a destination, interface and next-hop
    => prefer the source address on the outbound interface.
    RFC6724: Rule 5.
    that covers Behcet's use case 1,2,3.

2) given a destination, interface and next-hop
    => prefer the source address on the outbound interface and associated with the next-hop
    RFC6724: Rule 5.5.
    that covers Behcet's use case 4

now to the inverse:

3) given a source address
    => choose the outgoing interface that the source address is associated with
    Behcet's use case 4 (with single ISP)

4) given a source address
    => choose the outgoing interface and next-hop that the source address is associated with
   Behcet's use case 4

3,4 aren't specified in IETF text I believe.
those 4 rules are implementable to hosts using Default Router Lists.

in which cases wouldn't these rules suffice? and would any more specific source dependent routes require a host with a Routing Table?

cheers,
Ole

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 25 Jan 2015 11:47:33 +0100

Ole,
 
> in which cases wouldn't these rules suffice? and would any more specific source dependent routes require a host with a Routing Table?

I think they would suffice. I don’t think they are satisfying.
In current homenet, when there are multiple routers on the same link, they all advertise the same prefixes. And I think this is the correct behavior. I see two possibilities:
a. Routers do not advertise all PIOs, but only those they are best next-hop for (Works with your 4th proposition).
b. Routers advertise all PIOs. Best next-hop advertise something more (Source-Specific RIO).

With (a), when there are topology changes, routers will start and stop advertising PIOs as they detect they are best next-hop or not. Although addresses may have remained valid the whole time.
With (b), valid PIOs are always advertised by at least one router. As suggested Mikael, we can even use priorities to let hosts backup to a different next-hop when the best fails. Also, you separate the routing information and the address assignment information, which I think is better.

Cheers,

Pierre

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 25 Jan 2015 11:54:59 +0100

Hello Behcet

> indicate that you did not even read them.

Thank you for the effort. I actually read the update.
My point was that we only need one single RA option to solve all the situations. You added yet-another option.
Also, as Ole mentioned, third party next-hop doesn’t seem like a good idea to me (at least in RAs, I dont know in DHCP).

And I just realized all your options contain one single source address.
But what we actually need, IMHO, is rather a source prefix.

Regards,

- Pierre

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Jan 2015 09:42:50 +0100

Pierre,

> With (b), valid PIOs are always advertised by at least one router. As suggested Mikael, we can even use priorities to let hosts backup to a different next-hop when the best fails. Also, you separat…

this information only has value to the host when it is on the same link as the border router(s) right?
I don't think topology changes should result in routers starting and stopping advertising PIOs (unless it gets changes from a border router to an internal router). addresses are of course valid regardless of the PIO not being advertised (e.g. one of the border routers reboot).

so we're creating a special case here regardless. on the multiple border routers on a link case:
 I) ISP A border router only advertises ISP A prefixes in PIO
II) ISP A border router advertises both ISP A and ISP B prefixes in PIO, but only ISP A prefix in SS-RIO

all other internal routers advertise all prefixes in PIO. and presumably no internal routers include the SS-RIO.

RFC4191 has an interesting discussion:
---------
 There are several reasons for using a new Route Information Option
   instead of using flag bits to overload the existing Prefix
   Information Option:

   1. Prefixes will typically only show up in one option, not both, so a
      new option does not introduce duplication.

   2. The Route Information Option is typically 16 octets while the
      Prefix Information Option is 32 octets.

   3. Using a new option may improve backwards-compatibility with some
      host implementations.
---------

in our case, wouldn't typically the SS-RIO include the prefix that's already is in the PIO?
can we think of cases where you would use a different source prefix?

with regards to backwards compatibility, the cat might be out of the bag already.

do we need to also take care of the case of MHMP where the uplinks aren't ingress filtered? if so we need to be explicit.

a) implicit. describe how existing PIO, RIO should tie together SA,interface and next-hop selection
b) explicit with new SS-RIO
c) explicit with flags. new SS flag in PIO, and new SS flag in RIO

I'm not sure what's the best choice. are there use cases that one would cover and the other would not? are any of them more backwards compatible? other considerations in making the choice?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Jan 2015 11:20:26 +0100 (CET)

> a) implicit. describe how existing PIO, RIO should tie together SA,interface and next-hop selection

If the same router is announcing three different prefixes, with this 
suggestion I guess it'd need to announce with three different RAs if it 
wants the hosts to treat the prefixes differently?

> b) explicit with new SS-RIO

The good and bad thing with this one is that legacy hosts will not 
understand this new option.

> c) explicit with flags. new SS flag in PIO, and new SS flag in RIO

How do hosts generally treat flags?

> I'm not sure what's the best choice. are there use cases that one would cover and the other would not? are any of them more backwards compatible? other considerations in making the choice?

Good question!

In MIF, there is talk about having a PVD UUID of some kind. Where do we 
want to put that information? I believe that would be good input in this 
discussion.

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Jan 2015 12:30:41 +0100

Mikael,

> If the same router is announcing three different prefixes, with this suggestion I guess it'd need to announce with three different RAs if it wants the hosts to treat the prefixes differently?

what different treatment could you imagine?
I'm not sure with this option that you can differentiate very much at all.

> The good and bad thing with this one is that legacy hosts will not understand this new option.

right, but I think we have that with either of the solutions.

> How do hosts generally treat flags?

well, they would have to implement them. ;-)

> In MIF, there is talk about having a PVD UUID of some kind. Where do we want to put that information? I believe that would be good input in this discussion.

I'm not sure where to place PVDs here, I suppose you could look at them as being represented by multiple interfaces on the host, thereby making an MHMP host a MIMH (multi-interface multihomed) host instead.

at least in homenet I would think the network will amalgamate the information from external sources and present a single view on the inside.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Jan 2015 12:38:53 +0100 (CET)

> I'm not sure with this option that you can differentiate very much at all.

Well, you could for instance send RAs with different router priorities for 
different prefixes. Since it's implicit, I guess hosts would treat 
whatever came in an RA as a "bundle", so if the host received two 
different RAs from the same router for different prefixes, with different 
default router priority, it would actually use this information?

> well, they would have to implement them. ;-)

Will they ignore the option if it has flags it doesn't understand?

That's what differenting b from c here right?

> I'm not sure where to place PVDs here, I suppose you could look at them 
> as being represented by multiple interfaces on the host, thereby making 
> an MHMP host a MIMH (multi-interface multihomed) host instead.
>
> at least in homenet I would think the network will amalgamate the 
> information from external sources and present a single view on the 
> inside.

Well, how would the host find out that there might be multiple PVDs on the 
same wire? One was was to come up with a new RIO that would include this 
information, ie a PVD identifier included in RAs.

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Jan 2015 12:57:18 +0100

> Well, you could for instance send RAs with different router priorities for different prefixes. Since it's implicit, I guess hosts would treat whatever came in an RA as a "bundle", so if the host received two different RAs from the same router for different prefixes, with different default router priority, it would actually use this information?

if each border router advertises what's essentially a source constrained default route, would you need different priorities? you could of course, but then I think you would need the SS-RIO option.

> That's what differenting b from c here right?

yes, the flags are ignored.
so with re-using the PIO/RIO options a host would continue to use those as normal just without, or if implementing a) with source constrains. for the new SS-RIO option hosts that don't implement it would just ignore it altogether.

> Well, how would the host find out that there might be multiple PVDs on the same wire? One was was to come up with a new RIO that would include this information, ie a PVD identifier included in RAs.

I don't know. there might be two models, one where the network amalgamates the external information, and the only thing visible to the host is the prefixes, and the other which is the "virtual interface" to the host with PVDs. are PVDs largely needed to support walled gardens?

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2015 08:12:59 +1300

On 27/01/2015 00:57, Ole Troan wrote:

<snip>

> I don't know. there might be two models, one where the network amalgamates the external information, and the only thing visible to the host is the prefixes, and the other which is the "virtual inte…

I am puzzled. Has "the network" evolved into a super-brain that can amalgamate
information on its own? Either every host will have to accumulate all the
information and perform some kind of analysis, or a designated router will
have to do so, or a distributed autonomic process will have to do so.
I see a lot of dots in this discussion that need joining together still.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Jan 2015 20:20:28 +0100

Brian,

> I see a lot of dots in this discussion that need joining together still.

a super-brain I think not. ;-)
if we take homenet as an example, then there really isn't that much that is learnt from the upstreams.
one example of amalgamation would be the border routers learn the ISPs recursive resolvers, but the homenet offers its own DNS caching server forwarding to the ISPs one (according to whatever DNS server selection policy received).

that's pretty much how most homenets work today. examples of the other model, would be where each host had PPPoE sessions to a set of ISPs directly.

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 27 Jan 2015 11:59:36 -0600

Hello Pierre,

> My point was that we only need one single RA option to solve all the situations. You added yet-another option.

Again, it seems like you did not read my reply to your mail

http://www.ietf.org/mail-archive/web/ipv6/current/msg21655.html
on December 8.

In that mail, I explained that your proposal comes down to proposing 3
new options.

> Also, as Ole mentioned, third party next-hop doesn’t seem like a good idea to me (at least in RAs, I dont know in DHCP).

I think it makes more sense with DHCP because DHCP server is not a router.

I meant Section 13 by itself, not including the others with the next
hop. That was the idea with Section 2 in SADR Overview draft entitled
Router Advertisement Option
 While Section 3 includes an Option Set with next hop options as well.

> But what we actually need, IMHO, is rather a source prefix.

Absolutely. Anywhere it says source address, it refers to source prefix.

Regards,

Behcet

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 28 Jan 2015 09:59:33 +0900

On Wed, Jan 28, 2015 at 2:59 AM, Behcet Sarikaya <[email-masked]>
wrote:

> > Also, as Ole mentioned, third party next-hop doesn’t seem like a good
> idea to me (at least in RAs, I dont know in DHCP).
>

And that is why we don't do routing in DHCP: it's a bad idea.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jan 2015 17:31:20 +1300

> And that is why we don't do routing in DHCP: it's a bad idea.

Nevertheless, DHCP(v4) hands out the address of the default router.
By a strange coincidence, in most unmanaged networks the DHCP server
has the same IP address as the default router. However, in v4 and v6
the DHCP server is logically disjoint from the default router, and
Lorenzo and Behcet seem to agree on that. They disagree on whether
it matters.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 28 Jan 2015 13:56:38 +0900

> Nevertheless, DHCP(v4) hands out the address of the default router.

It does, and that's the reason we have to run VRRP. We can do better than
that.

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Jan 2015 09:12:24 +0100

<chair>

The proposal of adding a "route option" to DHCPv6 was discussed extensively in the MIF working group. The proposal did _not_ reach consensus.

I suggest that we do not reopen that debate. Unless there are new issues, not already brought up and considered in the MIF discussions. Parts of that discussion available here:
https://mailarchive.ietf.org/arch/search/?q=draft-ietf-mif-dhcpv6-route-option&f_list=mif

</chair>

Best regards,
Ole

> On 28 Jan 2015, at 5:31 , Brian E Carpenter <[email-masked]> wrote:
>

---

From: Ray Hunter <[email-masked]>
Date: Thu, 29 Jan 2015 08:10:05 +0100

> Your opinions are welcome.
I have read this draft. May I humbly suggest that I don't think you guys 
are on the right track at all with your problem statement.

You seem to think the problem with Homenet is how a non-mobile host 
discovers the correct SADR outbound route in the presence of a link 
shared between multiple provider routers, and there being no "cross 
link" higher in the topology to sort out incorrectly routed packets.

To me that's fighting an old battle (equivalent to IPv4 HSRP/VRRP + next 
hop/object trackers to counter split-brain and faults higher in the 
topology).

IMHO the real issue in Homenet routing is how to ensure that hosts that 
roam between various L3 subnets (because they move around in the Homenet 
and pick up various L3 WiFi interfaces) are correctly routed, also in 
the presence of multiple alternative wireless links.

That requires solving the reverse route too, and anything like VRRP is 
going to be hopeless.

IMVHO I think that hosts that want to be this flexible will be forced to 
actively participate in Homenet routing protocols, and that these hosts 
will have to be assigned their own /64 to a non-time-variant 
software-loopback interface that does not have to renumber as the end 
node moves between L3 LANs..

-- 
Regards,
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 29 Jan 2015 16:31:38 -0600

> https://mailarchive.ietf.org/arch/search/?q=draft-ietf-mif-dhcpv6-route-option&f_list=mif

I know that discussion as I was co-author of the draft.

I think the conclusion was to move the discussion to 6man.
That's what we have been doing with SADR drafts.
Once we reach consensus on the RA option then we need to decide if a
corresponding DHCP option is needed for networks where DHCP is used
for this type of configuration.

Regards,

Behcet

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jan 2015 11:41:35 +1300

> for this type of configuration.

Exactly. We actually need to agree on the scenarios and problems
first.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jan 2015 11:46:38 +1300

Hi Ray,

On 29/01/2015 20:10, Ray Hunter wrote:
> I have read this draft. May I humbly suggest that I don't think you guys are on the right track at all with your problem statement.
> 
> You seem to think the problem with Homenet is how a non-mobile host discovers the correct SADR outbound route in the presence of
> a link shared between multiple provider routers, and there being no "cross link" higher in the topology to sort out incorrectly
> routed packets.
> 
> To me that's fighting an old battle (equivalent to IPv4 HSRP/VRRP + next hop/object trackers to counter split-brain and faults
> higher in the topology).

It may be an old battle but I'm not sure it's over.

> 
> IMHO the real issue in Homenet routing is how to ensure that hosts that roam between various L3 subnets (because they move
> around in the Homenet and pick up various L3 WiFi interfaces) are correctly routed, also in the presence of multiple alternative
> wireless links.

If I roam to a different L3 network I get renumbered (unless I run Mobile IP
in the house). When I get a new address, don't I have to fight the old battle
one more time?

    Brian
> 
> That requires solving the reverse route too, and anything like VRRP is going to be hopeless.
> 
> IMVHO I think that hosts that want to be this flexible will be forced to actively participate in Homenet routing protocols, and
> that these hosts will have to be assigned their own /64 to a non-time-variant software-loopback interface that does not have to
> renumber as the end node moves between L3 LANs..
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 30 Jan 2015 13:39:47 +0900

On Fri, Jan 30, 2015 at 7:31 AM, Behcet Sarikaya <[email-masked]>
wrote:

> > I suggest that we do not reopen that debate. Unless there are new
> issues, not already brought up and considered in the MIF discussions. Parts
> of that discussion available here:
> >

No, the conclusion was that there was no consensus to define the option.
The draft was abandoned as a working group item and the corresponding
bullet was removed from the charter.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jan 2015 20:27:52 +1300

> bullet was removed from the charter.

Both your statements are true, and compatible with each other.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 30 Jan 2015 16:39:21 +0900

> Both your statements are true, and compatible with each other.

I do not recall that the conclusion was that this work should be taken up
in 6man. Was this written down anywhere?

---

From: V6ops <[email-masked]>
Date: Fri, 30 Jan 2015 12:32:27 +0100

Sent from my iThing

> On 29 Jan 2015, at 23:46, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Ray,
> 

I don't think there's even consensus on what the problem is, never mind where the problem should be solved: by inefficient routing back out the inbound interface, the end host knowing SADR information, some sort of VRRP, end node path probing, providing more routing information to end nodes. Yet this draft is proposing specific mechanisms.
> in the house). When I get a new address, don't I have to fight the old battle
It's much more serious than that. Someone turns on a microwave and one wifi link drops, and another is preferred. Or radio propagation changes marginally. So the node has to renumber and drop all existing sessions? That ain't going to fly with consumers. Wifi roaming has been kludged in the enterprise at L2. It needs to be fixed at L3 if homenet is going to be routed. For mobile ipv6 in Homenet, which egress router is going to provide the home address? And how will that work with 2 or more ISP routers providing walled gardens or BCP38 filtering?

Communicating SADR information between routers and end nodes is a sideshow / sub problem of that whole IMHO. And a stand alone solution for the sub problem developed in isolation is unlikely to solve the whole IMHO.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Jan 2015 17:37:32 +0100

Le 23/01/2015 12:11, Ole Troan a écrit :
[...]
> I have argued for 1, from the standpoint that this is what's most
> likely to get current hosts to implement today, and it works with two
> independent routers that doesn't support homenet protocols.

As for option 4 - it is hard to bring one routing protocol in each Host 
(which one?), whereas ND is one and in all kernels.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Jan 2015 07:16:59 +1300

Hi Lorenzo,
> in 6man. Was this written down anywhere?

Honestly I have no idea. Of course, a discussion in MIF can't add an item to
6man's work plan - all I recall is somebody saying or writing that further
discussion clearly belonged in 6man.

Anyway, I don't particularly want to discuss solutions yet. I don't feel
we have an agreed set of problem scenarios yet.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 30 Jan 2015 20:55:22 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of V6ops

> It's much more serious than that. Someone turns on a microwave and one wifi
> link drops, and another is preferred. Or radio propagation changes
> marginally. So the node has to renumber and drop all existing sessions? That
> ain't going to fly with consumers. Wifi roaming has been kludged in the
> enterprise at L2.

But that's not a kludge. WiFi APs were always meant to be L2 devices.

Bert

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 Jan 2015 17:27:30 -0600

On Fri, Jan 30, 2015 at 1:39 AM, Lorenzo Colitti <[email-masked]> wrote:
> On Fri, Jan 30, 2015 at 4:27 PM, Brian E Carpenter
> <[email-masked]> wrote:
>>
> I do not recall that the conclusion was that this work should be taken up in
> 6man. Was this written down anywhere?

Sorry my bad. Frankly I don't remember what the conclusion was and I
don't think it was written anywhere.
Wojciech, the main author realized that the draft was not going
anywhere and abandoned the work.

After that mif started Multiple Provisioning Domain Architecture
development and related DHCP and ND support.

We started SADR work in 6man.

Maybe all these are related. Can we say that mif DHCP route options
work lead the way to these new avenues, so it was avant garde?

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 Jan 2015 17:28:55 -0600

Folks,
Mobility in home network is out of scope with this draft.
Maybe also that should be discussed in homenet.

Regards,

Behcet

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 31 Jan 2015 02:10:22 +0000

> On Jan 30, 2015, at 3:27 PM, Behcet Sarikaya <[email-masked]> wrote:
> 

Why would routing not be done in the routing area?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Jan 2015 20:12:12 +1300

> Why would routing not be done in the routing area?

I think that's a fair question, once we know we have a routing problem.
It seems to me that isn't clear yet, which is why I'd like to see
something approaching consenus about the scenario analysis.

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 31 Jan 2015 09:17:33 +0000

> On Jan 30, 2015, at 11:12 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Well, in case it helps:

https://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cases
https://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases
  "Requirements and Use Cases for Source/Destination Routing", Fred Baker,
  2014-10-21

---

From: Ole Troan <[email-masked]>
Date: Sat, 31 Jan 2015 10:32:43 +0100

Fred,

> Why would routing not be done in the routing area?

it would and I think it is.
as far as I remember this work was instigated both in homenet and in routing in parallel.

what I think has been discussed in 6man so far, and is in scope for 6man, is possible host changes (or network to host signalling).

cheers,
Ole

---

From: Ray Hunter <[email-masked]>
Date: Sat, 31 Jan 2015 16:57:02 +0100

> Behcet Sarikaya <mailto:[email-masked]>
> 31 January 2015 00:28
> Folks,

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.

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?

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), does not require updating any end hosts, and does not require 
any new standards or new RA/RIO/DHCPv6 options.

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 01 Feb 2015 07:25:30 +1300

>   "Requirements and Use Cases for Source/Destination Routing", Fred Baker,

IMHO they do help and Behcet's draft specifically refers to them, but the
concern is about what should be shipped in all host stacks such that all
hosts will work in any of the possible scenarios.

   Brian

    Brian