Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-00.txt

From: "Olopade, Olorunloba" <[email-masked]>
Date: Mon, 19 Oct 2020 18:53:56 +0000

Hello all,

I'm proposing an alternate way to address the SLAAC flash renumbering issue, and I've been advised to put this in a draft. This is the initial draft, and definitely need more work, but will like to know if people think this approach is worth considering.

Regards.

Loba Olopade

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 19 October 2020 19:43
To: Olopade, Olorunloba <[email-masked]>
Subject: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt

A new version of I-D, draft-olopade-6man-slaac-signaling-00.txt
has been successfully submitted by Loba Olopade and posted to the IETF repository.

Name:		draft-olopade-6man-slaac-signaling
Revision:	00
Title:		Explicit signaling of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events
Document date:	2020-10-19
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/archive/id/draft-olopade-6man-slaac-signaling-00.txt
Status:         https://datatracker.ietf.org/doc/draft-olopade-6man-slaac-signaling/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-olopade-6man-slaac-signaling
Htmlized:       https://tools.ietf.org/html/draft-olopade-6man-slaac-signaling-00

Abstract:
   After a renumbering event in an IPv6 network utilizing SLAAC, hosts
   might continue to use stale addresses, as they are unaware of the
   changes. Likewise, routers, who may deprecate the use of these
   prefixes, are unaware of their use on the hosts. This scenario could
   have an adverse effect on communication with the host. This document
   proposes changes to the SLAAC algorithm that will explicitly allow
   routers to learn of these stale prefixes that are still assigned on
   the network.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

Visit www.virginmedia.com for more information, and more fun.

This email and any attachments are or may be confidential and legally privileged
and are sent solely for the attention of the addressee(s).

Virgin Media will never ask for account or financial information via email. If you are in receipt of a suspicious email, please report to www.virginmedia.com/netreport

If you have received this email in error, please delete it from your system: its use, disclosure or copying is unauthorised. Statements and opinions expressed in this email may not represent those of Virgin Media. Any representations or commitments in this email are subject to contract.

Registered office: 500 Brook Drive, Reading, RG2 6UU

Registered in England and Wales with number 2591237

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 20 Oct 2020 08:03:36 +0000

Hi Loba,
I was the loudest shouting that "tweaking timers" is a very bad solution.
Hence, it was logical consequences that Ole did push me to develop my draft.
I am very close to publish it. I am in the context of this discussion. I have spent couple of weeks exclusively on this problem.

You probably mean: "multicast RS " or "multicast NS to all routers".
It is not possible to find "multicast" in your draft.

Your proposal by itself is not bad. Synchronization is needed, indeed.
I have proposed here (and it would be discussed in my draft) 1 additional flag in RA message that information is "complete".
IMHO: It is a little better way for synchronization, because it does not need additional messages to synchronize states.

But such type of solutions are considered by me as "long-term". It needs host support. It could not happen very soon.
Something for short-term is needed too.

Additionally, you have not discussed solutions for all use cases presented by Fernando in draft-ietf-v6ops-slaac-renum.
For example: abrupt prefix change on the router (without deprecation)
Or abrupt VLAN change on L2 (802.1X)
Or prefix is just disconnected from Carrier, because uplink is down (replacement is not proposed yet)
Or situation in multi-homing when many PA prefixes from different Carriers are announced and some could be disconnected from carrier.
But maybe it was not your goal to develop comprehensive solution for "ND prefix robustness" (the last term is the name of my draft)

Eduard
> From: v6ops [mailto:[email-masked]] On Behalf Of Olopade,
> Olorunloba
> Sent: 19 октября 2020 г. 21:54
> To: 6man <[email-masked]>; [email-masked]
> Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-
> signaling-00.txt
> 
> Hello all,
> 
> I'm proposing an alternate way to address the SLAAC flash renumbering issue,
> and I've been advised to put this in a draft. This is the initial draft, and definitely
> need more work, but will like to know if people think this approach is worth
> considering.
> 
> Regards.
> 
> Loba Olopade
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> Virgin Media will never ask for account or financial information via email. If you
> are in receipt of a suspicious email, please report to
> www.virginmedia.com/netreport
> 
> If you have received this email in error, please delete it from your system: its
> use, disclosure or copying is unauthorised. Statements and opinions expressed in
> this email may not represent those of Virgin Media. Any representations or
> commitments in this email are subject to contract.
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Tue, 20 Oct 2020 16:31:24 +0200

In your letter dated Mon, 19 Oct 2020 18:53:56 +0000 you wrote:
>I'm proposing an alternate way to address the SLAAC flash renumbering issue, a
>nd I've been advised to put this in a draft. This is the initial draft, and de
>finitely need more work, but will like to know if people think this approach i
>s worth considering.

The mechanism proposed in this draft could work if carefully specified to deal
with edge cases (for example "poor man's multihoming").

However, for this to work changes are required to both routers and hosts.
If the router is a CPE, then we already have quite mature solutions that don't
require changes to hosts.

This would do nothing for hosts behind old CPEs. 

This draft could provide a solution of hosts that get moved to a different
VLAN. However, the need to update both hosts and router makes it more
attractive to find a solution that only requires hosts to be changed.

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Tue, 20 Oct 2020 23:14:23 +0000

Hello Eduard,

Yes, I do mean Multicast RS. 

Yes, we do need synchronisation. I believe some form of "feedback" is needed to achieve a "stable system". This is the premise I'm working on. With SLAAC as it currently is, we don't have a means of feeding back information from hosts to routers. That area is what I'm trying to address in this draft. By including information in RS messages, routers can learn about the state of the host.

This is an initial draft. So I wasn't attempting to document the complete solution at this time. But wanted to see if others would see the benefit of moving in this direction. In my opinion, I will like to see 2 changes to increase SLAAC robustness. This and a means for the router to indicate that it is sending "complete"  information (like you are indicating with the flag). 

But if we are to look into the various use cases, a common factor would be the forming of a new address. Hence, my proposal leverages on this, by sending the RS, as the address transitions from tentative to preferred. So, I believe all the use cases should be covered. 

Although, I'm having a change of heart on how to achieve this. I now think that using options in RS is better than relying on the source address. The key difference is that the current proposal is limited to PIO information. We also need to consider how to do garbage collection for RIO and RDNSS

I agree that this are long term solutions. For the short term, I think we are stuck with just lowering the timers.

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Vasilenko Eduard
Sent: 20 October 2020 09:04
To: Olopade, Olorunloba <Loba.Olopade=[email-masked]>; 6man <[email-masked]>; [email-masked]
Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-00.txt

Hi Loba,

Additionally, you have not discussed solutions for all use cases presented by Fernando in draft-ietf-v6ops-slaac-renum.
For example: abrupt prefix change on the router (without deprecation) Or abrupt VLAN change on L2 (802.1X) Or prefix is just disconnected from Carrier, because uplink is down (replacement is not proposed yet) Or situation in multi-homing when many PA prefixes from different Carriers are announced and some could be disconnected from carrier.
But maybe it was not your goal to develop comprehensive solution for "ND prefix robustness" (the last term is the name of my draft)

Eduard
> Subject: Re: [v6ops] New Version Notification for 
> draft-olopade-6man-slaac- signaling-00.txt
> 
> Hello all,
> 
> I'm proposing an alternate way to address the SLAAC flash renumbering 
> issue, and I've been advised to put this in a draft. This is the 
> initial draft, and definitely need more work, but will like to know if 
> people think this approach is worth considering.
> 
> Regards.
> 
> Loba Olopade
> 
> Subject: New Version Notification for 
> draft-olopade-6man-slaac-signaling-00.txt
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> This email and any attachments are or may be confidential and legally 
> privileged and are sent solely for the attention of the addressee(s).
> 
> Virgin Media will never ask for account or financial information via 
> email. If you are in receipt of a suspicious email, please report to 
> If you have received this email in error, please delete it from your 
> system: its use, disclosure or copying is unauthorised. Statements and 
> opinions expressed in this email may not represent those of Virgin 
> Media. Any representations or commitments in this email are subject to contract.
>

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Tue, 20 Oct 2020 23:18:54 +0000

Hello Philip,

Not sure which mature solutions you are referring to. Are these standardised?

In my opinion, to comprehensively deal with robustness issue with SLAAC, we need to make changes to both hosts and routers. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: 20 October 2020 15:31
To: [email-masked]
Cc: Olopade, Olorunloba <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-00.txt 

In your letter dated Mon, 19 Oct 2020 18:53:56 +0000 you wrote:
>issue, a nd I've been advised to put this in a draft. This is the 
>initial draft, and de finitely need more work, but will like to know if 
>people think this approach i s worth considering.

The mechanism proposed in this draft could work if carefully specified to deal with edge cases (for example "poor man's multihoming").

However, for this to work changes are required to both routers and hosts.
If the router is a CPE, then we already have quite mature solutions that don't require changes to hosts.

This draft could provide a solution of hosts that get moved to a different VLAN. However, the need to update both hosts and router makes it more attractive to find a solution that only requires hosts to be changed.
--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 21 Oct 2020 07:39:20 +0000

> a common factor would be the forming of a new address.
[Ed: ] Nope. Prefix could be for DHCP (A flag cleared). New address would be given not inside ND engine (DHCP demon is different in Unix).
By the way, on the problem statement: similar problem could happen for DHCP too. Timers would be better (hours against days), but it is not acceptable for user anyway (far from 50ms standards of the previous age). DHCP corner case is just have not been found in live, not yet. In reality we have here general prefix robustness problem of ND - it is not related only to SLAAC.
My "Complete" flag would resolve this problem too - enough information to deprecate DHCP after 1st RA.
How host should do DHCP address deprecation in your solution? Feedback from DHCP demon to ND?

>  So, I believe all the use cases should be covered.
[Ed: ] Nope. You see above.

> I agree that this are long term solutions. For the short term, I think we are stuck with just lowering the timers.
[Ed: ] Nope. I would show.

> We also need to consider how to do garbage collection for RIO and RDNSS
[Ed: ] RIO is better to deprecate for "telco broadband services" because of multi-prefix (many PA prefixes) environment. I would show why - MHMP is a little complex story.
RIO make sense only for Enterprise environment (with single address space, probably PI) - I have put this statement in the draft.

Ed/
> From: Olopade, Olorunloba [mailto:[email-masked]]
> Sent: 21 октября 2020 г. 2:14
> To: Vasilenko Eduard <[email-masked]>; 6man <[email-masked]>;
> [email-masked]
> Subject: RE: New Version Notification for draft-olopade-6man-slaac-signaling-
> 00.txt
> 
> Hello Eduard,
> 
> Yes, we do need synchronisation. I believe some form of "feedback" is needed
> to achieve a "stable system". This is the premise I'm working on. With SLAAC as
> it currently is, we don't have a means of feeding back information from hosts to
> routers. That area is what I'm trying to address in this draft. By including
> information in RS messages, routers can learn about the state of the host.
> 
> This is an initial draft. So I wasn't attempting to document the complete solution
> at this time. But wanted to see if others would see the benefit of moving in this
> direction. In my opinion, I will like to see 2 changes to increase SLAAC
> robustness. This and a means for the router to indicate that it is sending
> "complete"  information (like you are indicating with the flag).
> 
> But if we are to look into the various use cases, a common factor would be the
> forming of a new address. Hence, my proposal leverages on this, by sending the
> RS, as the address transitions from tentative to preferred. So, I believe all the
> use cases should be covered.
> 
> Although, I'm having a change of heart on how to achieve this. I now think that
> using options in RS is better than relying on the source address. The key
> difference is that the current proposal is limited to PIO information. We also
> need to consider how to do garbage collection for RIO and RDNSS
[Ed: ] RIO is better to deprecate. I would show why.
> To: Olopade, Olorunloba
> <Loba.Olopade=[email-masked]>; 6man <[email-masked]>;
> [email-masked]
> I am very close to publish it. I am in the context of this discussion. I have spent
> couple of weeks exclusively on this problem.
> 
> I have proposed here (and it would be discussed in my draft) 1 additional flag in
> RA message that information is "complete".
> IMHO: It is a little better way for synchronization, because it does not need
> additional messages to synchronize states.
> 
> Additionally, you have not discussed solutions for all use cases presented by
> Fernando in draft-ietf-v6ops-slaac-renum.
> For example: abrupt prefix change on the router (without deprecation) Or abrupt
> VLAN change on L2 (802.1X) Or prefix is just disconnected from Carrier, because
> uplink is down (replacement is not proposed yet) Or situation in multi-homing
> when many PA prefixes from different Carriers are announced and some could
> be disconnected from carrier.
> But maybe it was not your goal to develop comprehensive solution for "ND
> prefix robustness" (the last term is the name of my draft)
> 
> Eduard
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-olopade-6man-
> slaac-
> > signaling

---

From: Philip Homburg <[email-masked]>
Date: Wed, 21 Oct 2020 13:43:45 +0200

> Not sure which mature solutions you are referring to. Are these

I'm talking about draft-ietf-v6ops-cpe-slaac-renum-05

I think the preferred solution to complement this is have something that
only changes the host. However, a solution that only involves hosts is complex,
so your approach might be a good option if a host-only solution doesn't
work out.

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Wed, 21 Oct 2020 16:53:32 +0000

Would confess that I hadn't consider DHCP. But the logic can still work i.e. DHCP Solicit to validate address that was assigned via DHCPv6.

So scenario one, host with address assigned via DHCPv6 starts to receive RA with PIO having A flag set. New SLAAC address is formed, and host should validate previous address by sending DHCP solicit message. If response is received, address is still valid. Otherwise, address should no longer be preferred

Scenario 2, host with address assigned via SLAAC, start to receive RAs with A flag cleared. Host should send DHCP Solicit message to get net address. And then RS message to routers, who can then deprecate the prefix if required.  

-----Original Message-----
From: Vasilenko Eduard [mailto:[email-masked]] 
Sent: 21 October 2020 08:39
To: Olopade, Olorunloba <[email-masked]>; 6man <[email-masked]>; [email-masked]
Subject: RE: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt

Ed/
> To: Vasilenko Eduard <[email-masked]>; 6man 
> <[email-masked]>; [email-masked]
> Yes, we do need synchronisation. I believe some form of "feedback" is 
> needed to achieve a "stable system". This is the premise I'm working 
> on. With SLAAC as it currently is, we don't have a means of feeding 
> back information from hosts to routers. That area is what I'm trying 
> to address in this draft. By including information in RS messages, routers can learn about the state of the host.
> 
> This is an initial draft. So I wasn't attempting to document the 
> complete solution at this time. But wanted to see if others would see 
> the benefit of moving in this direction. In my opinion, I will like to 
> see 2 changes to increase SLAAC robustness. This and a means for the 
> router to indicate that it is sending "complete"  information (like you are indicating with the flag).
> 
> But if we are to look into the various use cases, a common factor 
> would be the forming of a new address. Hence, my proposal leverages on 
> this, by sending the RS, as the address transitions from tentative to 
> preferred. So, I believe all the use cases should be covered.
> 
> Although, I'm having a change of heart on how to achieve this. I now 
> think that using options in RS is better than relying on the source 
> address. The key difference is that the current proposal is limited to 
> PIO information. We also need to consider how to do garbage collection 
> for RIO and RDNSS
> 
> I agree that this are long term solutions. For the short term, I think 
> we are stuck with just lowering the timers.
> 
> 
> <Loba.Olopade=[email-masked]>; 6man 
> <[email-masked]>; [email-masked]
> I am very close to publish it. I am in the context of this discussion. 
> I have spent couple of weeks exclusively on this problem.
> 
> I have proposed here (and it would be discussed in my draft) 1 
> additional flag in RA message that information is "complete".
> IMHO: It is a little better way for synchronization, because it does 
> not need additional messages to synchronize states.
> 
> But such type of solutions are considered by me as "long-term". It 
> needs host support. It could not happen very soon.
> Additionally, you have not discussed solutions for all use cases 
> presented by Fernando in draft-ietf-v6ops-slaac-renum.
> Or abrupt VLAN change on L2 (802.1X) Or prefix is just disconnected 
> from Carrier, because uplink is down (replacement is not proposed yet) 
> Or situation in multi-homing when many PA prefixes from different 
> Carriers are announced and some could be disconnected from carrier.
> But maybe it was not your goal to develop comprehensive solution for 
> "ND prefix robustness" (the last term is the name of my draft)
> 
> Eduard
> > I'm proposing an alternate way to address the SLAAC flash 
> > renumbering issue, and I've been advised to put this in a draft. 
> > This is the initial draft, and definitely need more work, but will 
> > like to know if people think this approach is worth considering.
> >
> > Regards.
> >
> > Loba Olopade
> >
> > This email and any attachments are or may be confidential and 
> > legally privileged and are sent solely for the attention of the addressee(s).
> >
> > system: its use, disclosure or copying is unauthorised. Statements 
> > and opinions expressed in this email may not represent those of 
> > Virgin Media. Any representations or commitments in this email are 
> > subject to
> contract.
> >

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 21 Oct 2020 17:52:52 +0000

I was not talking about extremely rear case when DHCP is replaced by SLAAC or vice versa.
I was talking about more probable case: CPE has given prefix and DHCP lease to LAN host, then reloaded (in invisible way for host, probably bridge in between), then announce different prefix for DHCP.
How host should understand that old DHCP lease should be deprecated?
It may be that host would not start DHCP demon again. DHCP demon is not automatic - something should push it.
If this something would not push - host would not receive new address, that would not activate your solution. 
You are dependent on: (1) ND (additional NS check) and (2) DHCP demon (to receive new address)), and additionally (3) on something else (some monitoring) that should recognize availability of new DHCP prefix to activate DHCP.

Coordination between DHCP, ND and monitoring is additional complexity in your solution.
I propose flag "complete" that operates only on ND. DHCP demon or any monitoring is not needed to deprecate old address.
It would be less difficult for monitoring to understand that all addresses are deprecated - DHCP needed again.

Ed/
> Sent: 21 октября 2020 г. 19:54
> Would confess that I hadn't consider DHCP. But the logic can still work i.e. DHCP
> Solicit to validate address that was assigned via DHCPv6.
> 
> So scenario one, host with address assigned via DHCPv6 starts to receive RA
> with PIO having A flag set. New SLAAC address is formed, and host should
> validate previous address by sending DHCP solicit message. If response is
> received, address is still valid. Otherwise, address should no longer be preferred
> 
> Scenario 2, host with address assigned via SLAAC, start to receive RAs with A flag
> cleared. Host should send DHCP Solicit message to get net address. And then RS
> message to routers, who can then deprecate the prefix if required.
> 
> [Ed: ] Nope. Prefix could be for DHCP (A flag cleared). New address would be
> given not inside ND engine (DHCP demon is different in Unix).
> By the way, on the problem statement: similar problem could happen for DHCP
> too. Timers would be better (hours against days), but it is not acceptable for
> user anyway (far from 50ms standards of the previous age). DHCP corner case is
> just have not been found in live, not yet. In reality we have here general prefix
> robustness problem of ND - it is not related only to SLAAC.
> [Ed: ] RIO is better to deprecate for "telco broadband services" because of
> multi-prefix (many PA prefixes) environment. I would show why - MHMP is a
> little complex story.
> RIO make sense only for Enterprise environment (with single address space,
> probably PI) - I have put this statement in the draft.
> 
> Ed/
> > > Title:		Explicit signaling of Stateless Address Autoconfiguration
> (SLAAC)
> > > to Renumbering Events
> > > Htmlized:       https://tools.ietf.org/html/draft-olopade-6man-slaac-
> signaling-
> > 00
> > >
> > >
> > > Abstract: