Re: [v6ops] Updating RFC 7084

[Alexandre Petrescu <[e-mail]>]

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