Subject: Comments at the mic: draft-sarikaya-6man-next-hop-ra

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 17 Nov 2014 15:37:08 -0600

Hello Folks,

Last Friday at IETF 91 6man session many people expressed opinions on
the source address dependent routing related drafts.

Will each of you please put your comments in writing and let us see them?

If no one comes up, I am going to wait for the minutes and make calls
for each of you separately.

Regards,

Behcet

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Nov 2014 13:40:05 -0800

Behcet,

mine were:
 - I don't understand why these routes require a 3rd party nexthop
 - host support in SADR is only required when the host is directly connected to multiple exits, in other topologies then SADR routing will take care of it, and host changes aren't required.
 - why doesn't rule 5.5. in RFC6724 suffice?

cheers,
Ole

> On 17 Nov 2014, at 13:37 , Behcet Sarikaya <[email-masked]> wrote:
> 
> Hello Folks,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 18 Nov 2014 09:12:57 +0900

+1 to all three.

I'm particularly concerned by the fact that this option as currently
defined allows a third party next-hop, which breaks the fate-sharing
properties provided by router advertisements.

Also, the comments I provided several months ago at
http://www.ietf.org/mail-archive/web/ipv6/current/msg20799.html still stand.

On Tue, Nov 18, 2014 at 6:40 AM, Ole Troan <[email-masked]> wrote:

>  - host support in SADR is only required when the host is directly
> connected to multiple exits, in other topologies then SADR routing will
> take care of it, and host changes aren't required.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Nov 2014 13:58:41 +1300

> properties provided by router advertisements.

As does a redirect, if such a thing happens in real life. Yes,
configurations that require this would violate fate-sharing, but
are you ready to assert that such a configuration will never arise?

> http://www.ietf.org/mail-archive/web/ipv6/current/msg20799.html still stand.

One of those is that in the end this proposal does require some kind of
inter-router protocol in order to work properly. I think that's true; the
box issuing these new options needs to get the info from somewhere (hopefully
not manual config).

Another is that "this breaks the convention that routers are identified by link-local
addresses: because the address options do not contain a scope, there is no
way to use a link-local address in the next hop option, as it would be meaningless."

Even if they did contain a space for the ZoneID, that would be wrong
because ZoneIDs are meaningless outside their originating host. So if
they hand out a link-local address, that is ambiguous in a MIF situation.
So, yes, it has to be a global scope address to be unambiguous.

Your last comment was: cruder than MIF. Yes, because a MIF PVD is in effect
a new kind of scope. But MIF isn't done yet, so it's hard to say much more
right now.

More below...

>> take care of it, and host changes aren't required.

Actually they could be *indirectly* connected to multiple exits, if
there are multiple routers on the LAN, but indeed this is only needed
if the choice of next hop must be made by the host in order to find a
working path. (See my first comment above.)

>>  - why doesn't rule 5.5. in RFC6724 suffice?

Because right under rule 5.5, it says this:

      Discussion: An IPv6 implementation is not required to remember
      which next-hops advertised which prefixes.  The conceptual models
      of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
      have no such requirement.  Hence, Rule 5.5 is only applicable to
      implementations that track this information.

Possibly, if we added this as REQUIRED, that would be sufficient? I think
it would also provide the fate-sharing property too.

   Brian

> ------------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 21 Nov 2014 10:13:07 +0900

On Fri, Nov 21, 2014 at 9:58 AM, Brian E Carpenter <
[email-masked]> wrote:

> box issuing these new options needs to get the info from somewhere

In other words, for this to be reliable, the routers need to run VRRP or
something like that. I think it's irresponsible to require this.

> So, yes, it has to be a global scope address to be unambiguous.

... which means there's no way to track the router's IP address if the link
is renumbered, which is another problem.

So this option creates a set of new problems, without a clear use case that
I can see. So: why do this?

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Nov 2014 07:41:54 +0100

> it would also provide the fate-sharing property too.

that's the question. would rule 5.5 on hosts, possibly with rfc7078 for walled gardens combined with SADR forwarding in the network solve all cases?

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 26 Nov 2014 14:37:19 -0600

>> it would also provide the fate-sharing property too.

OK, let me add this to the RA draft and publish it as Rev, 03. Do we
need it on DHCP draft too?

> that's the question. would rule 5.5 on hosts, possibly with rfc7078 for walled gardens combined with SADR forwarding in the network solve all cases?
 No, because now we have this tool which is available in both RA and
DHCP to directly configure multiple interfaced hosts.

Regarding your comment on why modify host,
first of all current OSes do not support simultaneous operation of
multiple interfaces and modifications are under way. So we do need to
modify hosts anyway.
I am not worried about host modification. I recently bought iPhone 6
about a month ago, since then Apple announced 3-4 revisions of iOS.
So, if 6man does good things, I am sure they will find a way of
deploying those in smart phones quickly.

 Regards,

Behcet

---

From: Ole Troan <[email-masked]>
Date: Thu, 27 Nov 2014 07:32:38 +0100

Bechet,

> DHCP to directly configure multiple interfaced hosts.

which tool are you referring to?

I still don't understand the use case.
why do we need SADR options to the hosts?
what problem are you trying to solve?

(which isn't solved already by making 5.5 mandatory and implement 7078.)

cheers,
Ole

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 27 Nov 2014 10:20:55 +0100

(Interesting bug with the empty message…)

Hello Behcet,

Sorry for taking that long to answer. I promised you some comments at the mike, here they are.

1. As other said. I don’t think the next-hop address is a good idea.
If another router wants to be a router for hosts, it can send its own RAs.

Similarly, I don’t see why we need that many new options.
One Source-Specific Route option would be enough.
IMHO, we should try to make it compatible with RIOs.
Define a new option (similar to RIO options) with Source-Prefix, and specify a new bit flag in RIO option saying
the option can be ignored by hosts capable of understanding the Source-Specific RIO (basically it means there is a source-specific RIO in the message, and the RIO may be ignored by those hosts capable of understanding the Source-Specific ones).

2. Concerning DHCPv6. I don’t think we need that here. Hosts MUST parse RAs. I don’t see why we would need it in DHCPv6.

3. Trying to answer to ‘why rule 5.5 in RFC6724 is not enough’.

The draft says the reason why we need this new feature is to avoid egress filtering problems for hosts connected to multiple interfaces. 
I think rule 5.5 solves that problem when an application sends a packet with an unspecified source address.
In the presence of two default routes, one route will be chosen, and rule 5.5 will make sure the right source address is used  (The next-hop is chosen before the source-address).
(That said, rule 5.5 is quite complex to implement. I think a RIO-based solution would be simpler, as it would just require a few more line of code compared to existing RIO option).

Now when the application selects a source address, I think rule 5.5 doesn’t solve the problem (The source address is chosen before next-hop selection).
The source address is a way for the application to select the exit point (MIF will probably provide an API for applications to select a PvD, but it is not there yet and I think defining that option could also be useful to MIF in order to provide information about PvDs, like source-specific routing capabilities).
In the presence of multiple default routes, one will be picked, ignoring the source address which was selected by the application. Therefore, the next-hop router may not be the correct one, and the packets may be filtered.

4. I would also like to point-out a use-case which seems to be ignored in this document, and which may appear in homenet scenarios.

You have one link, a host, and two CPEs.

Host — — Router 1 — ISP1
      |
      |_ _ Router 2 — ISP2

Each ISP provides a different prefix, and so do the two routers to the host.
Using a source/dest aware routing protocol (which is how homenet works), the two routers are both able to route traffic correctly, no matter which next-hop router and source address the host selects.
But if we don’t let the host know which router to choose:
- The link bandwidth may be halved (We don’t use redirects)
- We may have a redirect ping-pong between the two routers (When we use redirects).

The problem with redirects is that they are not source-specific, so if the host tries to send packets to the same destination using both source addresses, we happen to have an erratic situation with ping-pong redirects being sent by the routers.

Defining a Source-Specific RIO would allow solving that issue, and let hosts select the right router no matter what.

Regards,

- Pierre

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Nov 2014 08:00:17 +1300

> 2. Concerning DHCPv6. I don’t think we need that here. Hosts MUST parse RAs. I don’t see why we would need it in DHCPv6.

I think we have heard from enterprise network managers who *want* to
put all their configuration information in a central DHCPv6 server,
and put as little as possible in their routers (apart from a DHCPv6
proxy). I emphasise that it's "want" not "need".

(This is of course exactly the opposite style of network management
than we are discussing in homenet and anima.)

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 27 Nov 2014 23:52:58 +0000 (UTC)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Pierre Pfister <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Friday, 28 November 2014, 6:00
> Subject: Why DHCPv6 [Comments at the mic: draft-sarikaya-6man-next-hop-ra]
> 
>>  2. Concerning DHCPv6. I don’t think we need that here. Hosts MUST parse 
> RAs. I don’t see why we would need it in DHCPv6.
> 

I've generally come to view DHCPv6 as an 'end-to-end' transport layer and up configuration protocol (although I don't think it actually yet being used to configure any transport layer protocol parameters yet), while RAs are per-link network layer and possibly below configuration protocol.

The reason I've come to that view is that if a router is any more than a DHCPv6 relay, it now isn't oblivious the applications running across it, as it is required to be involved in configuring them. You then can get stuck in the trap that you can't deploy a new application over your network because your routers don't support the options needed to configure them - and your work around is probably to enable a DHCPv6 relay on the routers and configure the new application using DHCPv6. You may as well have deployed that model in the first place.

I think the network should be transparent to both the payload of applications (i.e., the traditional Internet transparency view) as well as the mechanisms used to configure them. (which I discussed in 
https://datatracker.ietf.org/doc/draft-smith-v6ops-ce-dhcpv6-transparency/ and need to revisit to make it more general).

(I'm also not completely sure of putting all per-application configuration information in DHCPv6 either, as the option space would be limited compared the possible configuration options applications can have. Perhaps a better model would be to have a single DHCPv6 option for a particular application pointing to an IP address of the application configuration server where all other application parameters are held. Perhaps up until now we've been lucky that the applications that do need multiple parameters and therefore multiple DHCPv6 options haven't needed many.)

If network operators want centralised configuration of per-link and therefore RA options, I think a better model would be to treat the router as the configuration destination end-point, and use a configuration protocol that can provide the router with values for those options such as RADIUS or NETCONF.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Fri, 28 Nov 2014 08:58:43 +0100

> In the presence of multiple default routes, one will be picked, ignoring the source address which was selected by the application. Therefore, the next-hop router may not be the correct one, and the…

OK, rule 5.5 and a strict host model then.
essentially the rule is pick the next-hop that you learnt the source address from.

> Defining a Source-Specific RIO would allow solving that issue, and let hosts select the right router no matter what.

I would claim that your figure above is the _only_ case where host behaviour is somewhat open, and this could make sense.

I don't understand the:

Host ----------- ISP1
   |
   |
ISP2

use case at all. assuming a strict host model, which I think is a requirement here regardless, what would be the purpose of sending SADR options to the hosts?
especially given that I would expect it to be quite common that the two ISPs are not coordinating the service delivered to the host.

cheers,
Ole