Re: [v6ops] Updating RFC 7084

[Ted Lemon <[e-mail]>]

I think the problem here is that you don’t understand DHCPv6 PD or stub
routers. None of the objections you are stating here make any sense. I say
this as an author of the DHCPv6 specification and of the proposed stub
router specification. Before continuing this conversation, I encourage you
to read the documents.

Op ma 21 nov. 2022 om 12:55 schreef Vasilenko Eduard <
[e-mail]>

> The stub router does not see the state of the uplink of the different
> (infrastructure) router.
>
> It is a consequence of the propagation DHCP-PD multi-hop. It was intended
> strictly for 1 hop.
>
> It is a new problem that you are going to introduce.
>
>
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 8:53 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> Again, if a host on the infrastructure link can tell that the connection
> is down, the stub router can as well. So there is no new problem.
>
>
>
> Op ma 21 nov. 2022 om 12:51 schreef Vasilenko Eduard <
> [e-mail]>
>
> The problem does not exist currently.
>
>
>
> The current situation with DHCP-PD is not a problem because the DHCP-PD
> state is strictly connected to uplink (to the carrier).
>
> If the uplink is down then DHCP-PD could be cleared (and PIO with
> depreciation may be propagated).
>
> It is not many hops away as you propose.
>
>
>
> No mechanism for prefix delegation propagation over the site (multi-hop)
> has been adopted (HNCP is not adopted).
>
> By the way, HNCP was some sort of routing where it was possible to inform
> that some prefix is not valid anymore.
> HNCP propagates positive and negative messages the same effectively.
>
>
>
> If you would become successful with DHCP-PD propagation over the site
>
> Then you would create the problem of stale prefixes.
>
> People would start to complain exactly in situations when they have
> redundant carriers connections to improve reliability.
>
> They would be very disappointed because they made some efforts (redundant
> Carrier) to avoid the problem.
>
>
>
> Eduard
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 8:42 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> So, a host on the link would have the same problem, and hence this has
> nothing to do with DHCPv6 PD.
>
>
>
> Op ma 21 nov. 2022 om 12:40 schreef Vasilenko Eduard <
> [e-mail]>
>
> > independent of that, the stub router can see if the ra from the router
> that delegated a particular prefix indicates that the router is no longer
> preferred.
>
>
>
> No. the connection between routers on site is fine (it is LAN). RA is
> available without problems.
>
> The upstream connection on the infrastructure router has been lost.
>
> It is more probable because the upstream connection is WAN/MAN.
>
> DSL was not between on-site routers. DSL was on the upstream of the
> infrastructure router.
>
>
>
> By the way, RA absence in general is a bad indication because it is 900
> sec by default. Users with the real-time application (even youtube) would
> be not happy.
>
>
>
> > We can say that the server is required to support notification
>
> It needs investigation why DHCP notification is not popular.
>
> DHCP has not been intended for this initially.
>
>
>
> Eduard
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 8:32 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> We’re writing a new specification here. We can say that the server is
> required to support notification. But independent of that, the stub router
> can see if the ra from the router that delegated a particular prefix
> indicates that the router is no longer preferred.
>
>
>
> Op ma 21 nov. 2022 om 12:30 schreef Vasilenko Eduard <
> [e-mail]>
>
> How?
>
> The prefix has been delegated by the DHCP request from the stub router.
>
> Evidently, the stub router could not ping periodically for a refresh.
>
> Hence, the infrastructure router should “notify”.
>
> You said, “DHCP has notification”.
>
> I know that it is not used widely. Why?
>
> Would every built-in server support it?
>
> Eduard
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 8:26 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> In this scenario the stub router knows the router is deprecated. Why would
> it not deprecate the prefix?
>
>
>
> Op ma 21 nov. 2022 om 12:23 schreef Vasilenko Eduard <
> [e-mail]>
>
> In-line
>
>
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 8:14 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> You’ve described a situation, not a real world scenario. How did the host
> wind up in this situation?
>
> *[EV] his stub router just joined some infrastructure where connections to
> 2 carriers were available. Hence, the stub router received 2 prefixes and
> announced 2 PIOs to the host*
>
> Why is the network configured this way?
>
>
> *[EV] The person managing infrastructure would like resiliency. He has
> connected one router to 2 Carriers. Then received /56 prefixes from both.
> It is not MHMP – It is one router connected to different carriers.*
>
> Why is it that only by deprecating the prefix can the host experience
> reliable connectivity?
>
>
> *[EV] The host may use the PIO as the source address that is not connected
> anymore to the owner (Carrier). The different carrier would always do a
> uRPF check to drop the packet from the wrong source address (belonging to
> the different carrier).*
>
>
>
> Op ma 21 nov. 2022 om 12:11 schreef Vasilenko Eduard <
> [e-mail]>
>
> The host had many PIOs (from many PA prefixes).
>
> One prefix has become outdated somewhere upstream (because the connection
> to the carrier is lost), but the information has not been propagated to the
> host (DHCP is not the best for negative information propagation).
>
> The host may still try to use a dead PIO despite the same host having
> another alive PIO.
>
> The end user is unhappy, he could not open the site, and he calls you for
> help.
>
> Ed
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 8:04 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> Try to give us an example of an actual user experience that would be
> affected by the behavior you are concerned about. Describe the network
> configuration.
>
>
>
> The reason I am skeptical of your concern is that I have no idea what real
> world scenario is motivating it.
>
>
>
> Op ma 21 nov. 2022 om 12:02 schreef Vasilenko Eduard <
> [e-mail]>
>
> Hi Ted,
>
> I do not want to ignore you.
>
> But I am not capable to explain it differently.
>
> It looks so obvious…
>
> Eduard
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 7:36 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>; Ole Troan <otroan=
> [e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> What’s the problem you’re trying to solve here?
>
>
>
> Op ma 21 nov. 2022 om 10:59 schreef Vasilenko Eduard <
> [e-mail]>
>
> It was not about routing.
>
> DHCP-PD propagates prefixes that would be used for PIOs.
>
> If Carrier is not available anymore, hosts should stop using these PIOs
> for source addresses.
>
> But the stub router should be informed that particular prefixes should not
> be used anymore.
>
> How?
>
> Then stub router could deprecate PIO (zero preferred lifetime).
>
> Ed/
>
> *From:* Ole Troan [mailto:otroan=[e-mail]]
> *Sent:* Monday, November 21, 2022 6:53 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* Ted Lemon <[e-mail]>; IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> Eduard,
>
>
>
> I think you confuse addressing with routing.
>
>
>
> O.
>
>
>
> On 21 Nov 2022, at 16:39, Vasilenko Eduard <
> vasilenko.eduard=[e-mail]> wrote:
>
> 
>
> Imagine that the uplink to the Carrier (DSL for example) is down.
>
> All hosts on the site should stop using the /48 prefix received from this
> carrier. It should happen preferably sub-second.
>
> How this negative information would propagate over the site? (multi-hop)
>
> Default PIO preferred time is 1 week. Fernando has the intention to change
> it to 2hours – still pretty bad.
>
> The resolution by the current ND is very bad.
>
> Eduard
>
> *From:* Ted Lemon [mailto:[e-mail] <[e-mail]>]
> *Sent:* Monday, November 21, 2022 6:30 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> The DHCPv6 server could send a notification to the DHCPv6 client if we are
> concerned about this. But it’s not clear to me that we should be. If you
> think we should be, you need to actually make a case for that, not just
> assert that it’s so.
>
>
>
> Op ma 21 nov. 2022 om 08:52 schreef Vasilenko Eduard <vasilenko.eduard=
> [e-mail]>
>
> Hi all,
>
> I do not understand how DHCP-PD may be used for prefix distribution inside
> the site.
> Because uplink could go down.
> Should be some signaling to all routers on site that the prefix is not
> available anymore (and should be deprecated on all links).
> But DHCP is stateless in principle.
> This "flush renumbering problem" would be pretty difficult to fix.
> It would kill MHMP completely.
>
> Eduard
> -----Original Message-----
> From: v6ops <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: Friday, November 18, 2022 9:02 PM
> To: Timothy Winters <[e-mail]>; IPv6 Operations <[e-mail]>
> Subject: Re: [v6ops] Updating RFC 7084
>
> On 19-Nov-22 03:47, Timothy Winters wrote:
> > Hello,
> >
> > I've started a draft to update RFC 7084 to support prefix delegation on
> the LAN interfaces.  The current state of IPv6 in home networks is ISP are
> assigning prefixes of appropriate sizes but they currently are under
> utilized due to the lack of prefix delegation on LAN interfaces.
> >
> > This draft is an attempt to add that support to the draft.
> >
> > https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/
> > <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/>
> >
> > This is only an update to 7084 at the moment, there has been some
> discussion on the snac working group about leveraging this work as well.
> >
> > One item being discussed is this currently doesn't solve multi-homed
> networks.
>
> As a historical note, we've spent a lot of time in the past on
> multi-homing and more or less failed (and the HOMENET approach was designed
> for home nets, not for enterprises where the problem is probably more
> important).
>
> To summarise what I've said over on SNAC:
>
> 1. If we're going to mention PvDs in the 7084 update, I think we should
> also mention RFC 8028. It isn't that a CE router should necessarily support
> 8028, but that in a network that does implement 8028 on its subnet routers,
> the following part of 8028 applies:
>
> 2.2.  Expectations of Multihomed Networks
>
>     Networking equipment needs to support source/destination routing for
>     at least some of the routes in the Forwarding Information Base (FIB),
>     such as default egress routes differentiated by source prefix.
>     Installation of source/destination routes in the FIB might be
>     accomplished using static routes, Software-Defined Networking (SDN)
>     technologies, or dynamic routing protocols.
>
> Those egress routes of course lead to CE routers.
>
> (There is some other thinking about this topic in
> draft-vv-6man-nd-support-mhmp).
>
>     Brian
>
>
> >
> > I welcome any feedback about the proposal.
> >
> > ~Tim
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>