Re: Errata for RFC4862

Hi Mark,

On 10 Jan 2017, at 21:45, Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>> wrote:

On 11 Jan. 2017 6:32 am, "神明達哉" <jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>> wrote:
At Tue, 10 Jan 2017 12:45:27 +0000,
Tim Chown <Tim.Chown@jisc.ac.uk<mailto:Tim.Chown@jisc.ac.uk>> wrote:

> My recollection of running renumbering experiments is that it’s the
> Preferred Lifetime that matters, i.e. when that is set to zero for a
> prefix, the prefix is marked as deprecated.  So when renumbering,
> you run with two prefixes advertised, old and new, setting the
> Preferred Lifetime to 0 on the old prefix (even though the Valid
> Lifetime is set to 2+ hours), so that the address with the new
> prefix is used for newly initiated communications (as per RFC 6724,
> Rule 3).

Yes, but I guess what Ole tried to point out (which I agree with) is
that the valid lifetime will also have to decrease to 0 eventually,
and this original text of RFC4862 allows such decrease operation
without requiring explicit authentication if done by gradually:

If that is the case (and I don't think it is, it creates the DoS opportunity that all other >2 hr checks attempt to defeat), then I think it needs to be far better and more explicitly explained, including the sequence of events.

What is the use case that can't be achieved by setting the preferred lifetime to zero, immediately deprecating the addresses (and a VL of 2 hours to cause them to disappear shortly).

If it is to remove addresses immediately from a host by setting the RA PIO VL to zero - actually that's not going to work, because seeing VL to zero will fail the greater than remaining time check.

It would be very laborious to try to remove an address by only being able to send a VL greater than the address's remaining time. Letting the address age out/expire naturally by itself by stopping sending the RA PIO for the prefix wolf be easier and I think quicker.

Yes, the process you describe is exactly what RFC 4192 recommends for renumbering, and which was tested on common OSes at the time that RFC was written. To begin the renumbering process, you run with PL 0 and VL 2hrs on the “old” prefix, and with normal values on the “new” prefix.  To transition to just the new prefix in use, you stop advertising the old prefix, such that addresses formed from it will become invalid and be removed, and during which time the address generated from the new prefix will be used due to RFC 6724 Rule 3.

So from that perspective, there’s no need to change RFC 4862 to allow an unauthenticated VL < 2hrs.

Tim

Regards,
Mark.

> >>     1.  If the received Valid Lifetime is greater than 2 hours or
> >>         greater than RemainingLifetime, set the valid lifetime of the
> >>         corresponding address to the advertised Valid Lifetime.

--
JINMEI, Tatuya

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------