Re: [v6ops] Updating RFC 7084

[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]<mailto:[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]<mailto:[e-mail]>]
Sent: Monday, November 21, 2022 8:32 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: IETF v6ops WG <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
Sent: Monday, November 21, 2022 8:26 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: IETF v6ops WG <[e-mail]<mailto:[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]<mailto:[e-mail]>>
In-line

From: Ted Lemon [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Monday, November 21, 2022 8:14 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: IETF v6ops WG <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
Sent: Monday, November 21, 2022 8:04 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: IETF v6ops WG <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
Sent: Monday, November 21, 2022 7:36 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: IETF v6ops WG <[e-mail]<mailto:[e-mail]>>; Ole Troan <otroan=[e-mail]<mailto:[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]<mailto:[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<mailto:otroan>=[e-mail]<mailto:[e-mail]>]
Sent: Monday, November 21, 2022 6:53 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: Ted Lemon <[e-mail]<mailto:[e-mail]>>; IETF v6ops WG <[e-mail]<mailto:[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]<mailto: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]]
Sent: Monday, November 21, 2022 6:30 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: IETF v6ops WG <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Brian E Carpenter
Sent: Friday, November 18, 2022 9:02 PM
To: Timothy Winters <[e-mail]<mailto:[e-mail]>>; IPv6 Operations <[e-mail]<mailto:[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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops