Re: [v6ops] Updating RFC 7084

[Vasilenko Eduard <[e-mail]>]

I did not say anything about destination routing.
"Prefixes" below - it is only prefixes that are used for PIO and then eventually for source addresses.
By the way, proper prefixes distribution for PIO is a routing challenge too.

> global addresses stay valid in-home despite the transient nature of the ISP link, for a few hours or so
Reminder: deprecating for "preferred" status, not for "Valid Lifetime".
If the deprecated prefix is the only one available - it would be used anyway for a new connection.
It would be used if the session is already open.

The one who propagates prefixes for PIO,
Should think about how he would clean the mess,
After some prefix would become stale.
It is easy for the prefix to become stale with 3GPP or DSL uplink to the Carrier.

Ed/
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, November 23, 2022 6:19 PM
To: [e-mail]
Subject: Re: [v6ops] Updating RFC 7084



Le 21/11/2022 à 17:34, Timothy Winters a écrit :
> Hi Eduard,
> 
> You won't want all the devices to lose global addresses in the home if 
> the (WAN) DSL link went down.  They might be communicating in the home 
> network to other devices using global addresses.  If you unaddressed 
> them all those connections would instantly be terminated.

I think the point raised by Eduard is valid from two points of view.

The addresses being deprecated upon disconnection from the ISP - is one point.  In this point, one would appreciate indeed that the global addresses stay valid in-home despite the transient nature of the ISP link, for a few hours or so.  On another hand, one might not appreciate that GUAs are valid in a network that is disconnected from the ISP, because it might get connected to the Internet via another 5G or 6G link, for example - the maintained GUAs from ISP might be wrong on the 56/6G network.  Maybe ULAs would be better, or not.

The other point valid in Eduard's message is the routing.  I think Eduard makes some assumptions about in-home routing, and on the ISP router in-home, that are not entirely true.  But we can discuss that separately.

Alex

> 
> ~Tim
> 
> On Mon, Nov 21, 2022 at 10:59 AM Vasilenko Eduard 
> <vasilenko.eduard=[e-mail]
> <mailto:[e-mail]>> wrote:
> 
> 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] <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/>
>> 
> <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
> <https://www.ietf.org/mailman/listinfo/v6ops>
> _______________________________________________ v6ops mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>
> _______________________________________________ v6ops mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>____
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>____
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/v6ops
> <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