Re: [v6ops] Updating RFC 7084

[Alexandre Petrescu <[e-mail]>]

Le 23/11/2022 à 17:00, Vasilenko Eduard a écrit :
> I did not say anything about destination routing.

sorry, I took routing for propagating, words.


> "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.

Fair enough.  Timer management, lifetimes, are very difficult even in a 
single computer, let alone in a distributed manner among computers, and 
even less across domains.

A lifetime deprecation proposed by a 3GPP operator would be very 
different than that of the ADSL or fiber provider.

Yet, it is among those access networks, presumably satcom too, that an 
end user must re-connect.

Further, I can say that when such urgent needs of re-connection appear, 
IPv6 is the least of the worries.  But when IPv6 is there, these 
lifetime management aspects will be very important.

Alex

> 
> 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