DecrementLifetimes and preferred (vs valid) lifetime

[ipilcher]

When DecrementLifetimes is set on for a prefix, radvd stops advertising that prefix when its preferred lifetime reaches zero. I believe that it would be useful if radvd were to continue advertising such a prefix, with a preferred lifetime of zero, until its valid lifetime reaches zero. (This obviously assumes that the initial valid lifetime is greater than the initial preferred lifetime.)

My use case for this behavior is "dynamic prefix delegation." My ISP delegates a /56 prefix, and I divide it into multiple /64 subnets; radvd handles router advertisements for those /64 "leaf" subnets. Unfortunately my ISP can change the delegated prefix, so I have created a set of scripts to automatically reconfigure my home network, including radvd, when this occurs.

I'm currently taking the following steps to make devices on the leaf networks react as quickly as possible to a change in the delegated prefix:

1. I use short lifetimes for the "dynamic" prefixes.

   AdvValidLifetime 300;
   AdvPreferredLifetime 300;

   Despite the text in RFC 4862, this actually does work, as long as the prefix is never advertised with a longer lifetime.

2. When my delegated prefix changes, I generate a new radvd.conf with both the old and the new "leaf" network prefixes. The old prefixes are advertised with a preferred lifetime of 0, which should cause them to be deprecated by devices that receive the advertisements.

3. I reload (SIGHUP) radvd, so that it begins advertising both the new and old (deprecated) prefixes.

4. Wait for a period at least as long as the original valid lifetime of the old prefix (300 seconds). During this time, radvd is continuing to advertise the old prefix with a preferred lifetime of 0 (and a valid lifetime of 75, slightly longer than the MaxRtrAdvInterval of 60).

5. When the waiting period expires, I again generate a new radvd.conf, this time without the old prefix(es).

6. SIGHUP radvd again, so that it uses the 2nd new config and stops advertising the old prefix(es).

I use this somewhat convoluted process to handle two categories of devices:

1. Devices that always listen to and act on router advertisements. These devices should mark addresses within the old prefix(es) as deprecated in step 3 above.

2. Devices (phones and tablets) that ignore router advertisements while in power-saving mode. If such a device happens to wake up and "see" a router advertisement during step 4 above, then it will behave like a "category 1" device. If it doesn't wake up until after step 6, the valid lifetime of the old prefix will have expired.

This approach seems to work fairly well, but it has a couple of disadvantages.

1. Complexity - The multiple config file generations and radvd reloads is a bit of a pain. The behavior I described at the beginning of this post would at least remove the need for a second radvd reload.

2. "Type 1" devices end up holding on to deprecated addresses for longer than is optimal. During "step 4," I advertise the old prefix(es) with a preferred lifetime of zero and a valid lifetime of 75 seconds, slightly longer that the MaxRtrAdvInterval. I do this so that systems on the leaf networks don't have to repeatedly delete and re-add these addresses. This step lasts 300 seconds, so these devices actually don't delete these addresses until 375 seconds after they are no longer actually routable. (Granted they shouldn't be trying to use deprecated addresses for new connections, but tell that to Firefox!)

Ultimately, it would just be much more elegant if I could advertise the old addresses with something like:

AdvPreferredLifetime 0;
AdvValidLifetime 300;
DecrementLifetimes on;

And let radvd auto-decrement the valid lifetime in its advertisements and stop advertising the prefix when the valid lifetime reaches zero.

[ipilcher]

I should add that I'd be happy to take a crack at making this change, if there's interest.

[reubenhwk]

I’ll have to reread you email carefully, but it sounds like the special prefix ::/64 is close to what you want. Maybe radvd should generalize that special prefix a bit more to support ::/56?

I thought there was already something similar to Base6to4Interface, but I don’t see it now.

From the man page: “Special prefix "::/64" is also supported on systems that implement getifaddrs() (on other systems, configuration activation fails and radvd exits). When configured, radvd picks one non-link-local prefix assigned to the interface and starts advertising it. This may be applicable in non-6to4 scenarios where the upstream prefix might change. This option is incompatible with Base6to4Interface option. AdvRouterAddr option is always enabled when this configuration is used.”

Also, on an unrelated note, it may be time to purge radvd of 6to4 centric code and features. 6to4 was freaking awesome in 2010, but I don’t think it’s been used for many years now. 6rd too...

Sent from my iPhone

On Oct 25, 2019, at 7:46 AM, Ian Pilcher notifications@github.com wrote:

I should add that I'd be happy to take a crack at making this change, if there's interest.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ipilcher]

I’ll have to reread you email carefully, but it sounds like the special prefix ::/64 is close to what you want.

The ::/64 special prefix is (mostly) orthogonal to this issue. (I probably could use it to advertise my "dynamic leaf prefixes," but AFAIK it doesn't help with the problem of getting systems on those leaf networks to stop trying to use the old addresses.)

The behavior I'm interested in is using DecrementLifetimes on a prefix whose preferred lifetime is zero (but which still has a non-zero valid lifetime).

For example, assume that my delegated prefix is 2605:6000:8c8b:a400::/56; let's consider the 2605:6000:8c8b:a4fa::/64 leaf network. The radvd.conf snippet for this prefix looks like this:

interface bond0.250
{
        AdvDefaultLifetime 1800;
        MaxRtrAdvInterval 60;
        MinRtrAdvInterval 30;
        AdvSendAdvert on;

        prefix 2605:6000:8c8b:a4fa::/64
        {
                AdvAutonomous on;
                AdvOnLink on;
                AdvPreferredLifetime 300;
                AdvRouterAddr off;
                AdvValidLifetime 300;
        };
};

Now assume that the delegated prefix changes to 2605:6000:8c8f:c00::/56; the new leaf network is 2605:6000:8c8f:cfa::/64. Advertising the new new leaf prefix is simple enough; the challenge is getting systems on the network, including devices which ignore router advertisements, to stop trying to use addresses in the old prefix.

First, I do this.

interface bond0.250
{
        AdvDefaultLifetime 1800;
        MaxRtrAdvInterval 60;
        MinRtrAdvInterval 30;
        AdvSendAdvert on;

        prefix 2605:6000:8c8f:cfa::/64
        {
                AdvAutonomous on;
                AdvOnLink on;
                AdvPreferredLifetime 300;
                AdvRouterAddr off;
                AdvValidLifetime 300;
        };

        prefix 2605:6000:8c8b:a4fa::/64
        {
                AdvPreferredLifetime 0;
                AdvValidLifetime 75;
        };
};

In addition to the new prefix, I'm advertising the old prefix with a preferred lifetime of zero. Systems that are listening to router advertisements should mark the their old addresses as deprecated and stop trying to use them for new connections.

I continue using this configuration, and advertising the old prefix as deprecated, for at least 300 seconds - the original lifetime of the old prefix. If a system ignores router advertisements for the entire 300 seconds, the valid lifetime of the old prefix will have expired when it finally does wake up. After the 300 second "transition" period, I completely stop advertising the old prefix:

interface bond0.250
{
        AdvDefaultLifetime 1800;
        MaxRtrAdvInterval 60;
        MinRtrAdvInterval 30;
        AdvSendAdvert on;

        prefix 2605:6000:8c8f:cfa::/64
        {
                AdvAutonomous on;
                AdvOnLink on;
                AdvPreferredLifetime 300;
                AdvRouterAddr off;
                AdvValidLifetime 300;
        };
};

Approximately 75 seconds later, systems that actually did receive the "transitional" router advertisements will completely remove the old addresses.

The behavior that I would like to see is a change to the "transitional" configuration. It would like to be able to do this.

interface bond0.250
{
        AdvDefaultLifetime 1800;
        MaxRtrAdvInterval 60;
        MinRtrAdvInterval 30;
        AdvSendAdvert on;

        prefix 2605:6000:8c8f:cfa::/64
        {
                AdvAutonomous on;
                AdvOnLink on;
                AdvPreferredLifetime 300;
                AdvRouterAddr off;
                AdvValidLifetime 300;
        };

        prefix 2605:6000:8c8b:a4fa::/64
        {
                AdvPreferredLifetime 0;
                AdvValidLifetime 300;
                DecrementLifetimes on;
        };
};

Today, that won't work. A prefix with DecrementLifetimes set is not advertised when its preferred lifetime reaches zero.

My proposal is that the old prefix would continue to be advertised in this circumstance. The preferred lifetime in the advertisements would always be zero, and the valid lifetime would be automatically decremented until it reaches zero. Only when the valid lifetime reaches zero would radvd stop advertising the prefix.

Hopefully that clarifies my thinking.

[markzzzsmith]

As the author of the DecrementLifetimes option, I don't fully understand why this proposal is required. I'll have to study and think about it further.

However, be aware that a ValidLifetime of less then 7200 seconds (2 hours) is invalid, and IPv6 hosts are supposed to ignore RA PIOs that have a VL of less than 7200 seconds - see RFC 4862, 5.5.3, part (e).

So I'd be wary of suggesting anything when your radvd configuration isn't compliant with IPv6 RFCs. If you make your configuration compliant with the IPv6 RFCs, then perhaps the problem you have may go away, making any changes to 'radvd' unnecessary.

[markzzzsmith]

By the way, have you tried to use the DeprecatePrefix option? That tries to immediately deprecate addresses from the specified prefix, which seems to be somewhat close to what you're trying to achieve with a PL/VL of 300 seconds.

[ipilcher]

As the author of the DecrementLifetimes option, I don't fully understand why this proposal is required. I'll have to study and think about it further.

The goal is to advertise a "deprecated" prefix for a limited period of time, so that systems will stop trying to use addresses in old prefix.

However, be aware that a ValidLifetime of less then 7200 seconds (2 hours) is invalid, and IPv6 hosts are supposed to ignore RA PIOs that have a VL of less than 7200 seconds - see RFC 4862, 5.5.3, part (e).

In my testing, host ignore a valid lifetime of less than 7200 if it is less than the current valid lifetime of an existing prefix. So a short valid lifetime (like the 300 seconds that I use) actually is honored by at least Linux (including Android) and Windows systems as long as the prefix hasn't previously been advertised with a longer lifetime. I believe that this behavior is RFC 4862 compliant, although the RFC certainly doesn't go out of its way to clarify this case.

So I'd be wary of suggesting anything when your radvd configuration isn't compliant with IPv6 RFCs. If you make your configuration compliant with the IPv6 RFCs, then perhaps the problem you have may go away, making any changes to 'radvd' unnecessary.

Using longer valid lifetimes would simply cause old, no longer routable, addresses to be used for longer.

[ipilcher]

By the way, have you tried to use the DeprecatePrefix option? That tries to immediately deprecate addresses from the specified prefix, which seems to be somewhat close to what you're trying to achieve with a PL/VL of 300 seconds.

I have. The problem is "mobile devices" that ignore router advertisements when they're in various power-saving modes.

DeprecatePrefix only sends a single advertisement with a preferred lifetime of zero. A device that ignores this RA and then wakes up will continue trying to use the old prefix until its valid lifetime expires.

[reubenhwk]

Can you check with your isp to see why your upstream address keeps changing? How often does it change? If ISPs keep changing the upstream address we’re going to have to start NATing IPv6 to shield ourselves from this nonsense. :/

Sent from my iPhone

On Oct 27, 2019, at 5:43 PM, Ian Pilcher notifications@github.com wrote:

By the way, have you tried to use the DeprecatePrefix option? That tries to immediately deprecate addresses from the specified prefix, which seems to be somewhat close to what you're trying to achieve with a PL/VL of 300 seconds.

I have. The problem is "mobile devices" that ignore router advertisements when they're in various power-saving modes.

DeprecatePrefix only sends a single advertisement with a preferred lifetime of zero. A device that ignores this RA and then wakes up will continue trying to use the old prefix until its valid lifetime expires.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[markzzzsmith]

On Mon, 28 Oct 2019, 16:25 reubenhwk, notifications@github.com wrote:

Can you check with your isp to see why your upstream address keeps changing? How often does it change? If ISPs keep changing the upstream address we’re going to have to start NATing IPv6 to shield ourselves from this nonsense. :/

Yes. This is the real problem.

A stable, always on Internet connection should always have the same addresses.

If IPv6 needs to have NAT to avoid this problem, then there is no point to IPv6.

The story of the work arounds the OP is trying to do to overcome what their ISP is doing to them is horrible. I wouldn't use IPv6 if it is that hard to make work from my ISP.

ISPs aren't deploying IPv6 correctly if they are forcing unexpected address changes onto their customers.

Sent from my iPhone

On Oct 27, 2019, at 5:43 PM, Ian Pilcher notifications@github.com wrote:

By the way, have you tried to use the DeprecatePrefix option? That tries to immediately deprecate addresses from the specified prefix, which seems to be somewhat close to what you're trying to achieve with a PL/VL of 300 seconds.

I have. The problem is "mobile devices" that ignore router advertisements when they're in various power-saving modes.

DeprecatePrefix only sends a single advertisement with a preferred lifetime of zero. A device that ignores this RA and then wakes up will continue trying to use the old prefix until its valid lifetime expires.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reubenhwk/radvd/issues/116?email_source=notifications&email_token=ADLQA7IDZSGBVACRZR7WN5TQQZZSXA5CNFSM4JE4CZH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECLXBTQ#issuecomment-546795726, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLQA7IUGEU4P5YVL2V36D3QQZZSXANCNFSM4JE4CZHQ .

[markzzzsmith]

On Mon, 28 Oct 2019, 11:39 Ian Pilcher, notifications@github.com wrote:

As the author of the DecrementLifetimes option, I don't fully understand why this proposal is required. I'll have to study and think about it further.

The goal is to advertise a "deprecated" prefix for a limited period of time, so that systems will stop trying to use addresses in old prefix.

There is no way to inform a host to immediately stop using an address.

The reason there isn't is because that creates a DoS attack opportunity. A rogue host could spoof an RA with all of the link's PIOs with a VL of 0, causing all hosts to immediately stop using all their addresses.

However, be aware that a ValidLifetime of less then 7200 seconds (2 hours)

is invalid, and IPv6 hosts are supposed to ignore RA PIOs that have a VL of less than 7200 seconds - see RFC 4862, 5.5.3, part (e).

In my testing, host ignore a valid lifetime of less than 7200 if it is less than the current valid lifetime of an existing prefix. So a short valid lifetime (like the 300 seconds that I use) actually is honored by at least Linux (including Android) and Windows systems as long as the prefix hasn't previously been advertised with a longer lifetime. I believe that this behavior is RFC 4862 compliant, although the RFC certainly doesn't go out of its way to clarify this case.

I don't think it is RFC 4862 complaint.

The only rule in 5.5.3 that accepts a VL that is smaller than 2 hours is the first one:

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.

RemainingLifetime is

" The specific action to perform for the valid lifetime of the address depends on the Valid Lifetime in the received advertisement and the remaining time to the valid lifetime expiration of the previously autoconfigured address. We call the remaining time "RemainingLifetime" in the following discussion:"

In other words, a VL of less than 2 hours is only accepted if it is extending or increasing the host's current value for the Valid Lifetime.

Working through the scenarios:

A PIO VL of 300 should be ignored if the host has not seen any previous advertisements of this prefix, because VL of 300 is smaller than 2 hours.

A PIO VL of 300 should be ignored if the host's current VL for the prefix is smaller than 300.

A PIO VL of 300 should be processed if 300 is greater than the host's current VL for the prefix. That means that the RA PIO is increasing the VL. For example, if the host's current VL is 150 seconds, then it will be increased to 300 seconds.

This would be quite contrary to what the DecrementLifetime option does - it's purpose is to synchronise the ageing of prefix information on hosts by reducing or decreasing the VL. The result of receiving a DecrementLifetimes PIO is VL on the host is reduced to what is in the PIO.

Once the hosts prefix ageing is synchronised, and the age of the prefix is below 7200 seconds on all of the hosts, the hosts will ignore any RA PIOs with a VL of less than 7200 seconds, which is why there is no point sending these DecrementLifetime RA PIOs from that point in time on wards.

So I'd be wary of suggesting anything when your radvd configuration isn't

compliant with IPv6 RFCs. If you make your configuration compliant with the IPv6 RFCs, then perhaps the problem you have may go away, making any changes to 'radvd' unnecessary.

Using longer valid lifetimes would simply cause old, no longer routable, addresses to be used for longer.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reubenhwk/radvd/issues/116?email_source=notifications&email_token=ADLQA7NDVT27DZBDR7EMDD3QQYYFDA5CNFSM4JE4CZH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECLMQMA#issuecomment-546752560, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLQA7KPJCI2ZZPNNUANSVTQQYYFDANCNFSM4JE4CZHQ .

[ipilcher]

Can you check with your isp to see why your upstream address keeps changing? How often does it change? If ISPs keep changing the upstream address we’re going to have to start NATing IPv6 to shield ourselves from this nonsense. :/

The issue isn't that it changes frequently. (I honestly don't know how often it changes, as I'm just in the process of setting IPv6 up.) The issue is that it can change (probably about as often as my IPv4 address.), and I want my home network to deal with such changes as gracefully as possible.

[ipilcher]

Yes. This is the real problem. A stable, always on Internet connection should always have the same addresses. If IPv6 needs to have NAT to avoid this problem, then there is no point to IPv6. The story of the work arounds the OP is trying to do to overcome what their ISP is doing to them is horrible. I wouldn't use IPv6 if it is that hard to make work from my ISP. ISPs aren't deploying IPv6 correctly if they are forcing unexpected address changes onto their customers.

ISPs are accustomed to charging extra for stable IP addresses. Anyone who thinks that they're going to willingly give up on this revenue, just because the resource is question isn't actually scarce anymore, is living in a dream world.

If IPv6 needs to have NAT to avoid this problem, then there is no point to IPv6.

All of the "workarounds" that I'm putting in place are there to avoid using NAT'ed ULAs.

The story of the work arounds the OP is trying to do to overcome what their ISP is doing to them is horrible. I wouldn't use IPv6 if it is that hard to make work from my ISP.

I don't have any data, but given my experience with a variety of residential ISPs over the years, I'd be very surprised if many/most of them don't reserve the right to change delegated prefixes, just as they can change assigned IPv4 addresses today.

As to the second point, I guess I'm just stubborn.

ISPs aren't deploying IPv6 correctly if they are forcing unexpected address changes onto their customers.

Have you actually dealt with a residential ISP? I consider it a miracle that I can actually get a /56 delegation. I'm "lucky" enough to actually have 2 ISPs service my area; the other one doesn't offer IPv6 at all.

[ipilcher]

A PIO VL of 300 should be ignored if the host has not seen any previous advertisements of this prefix, because VL of 300 is smaller than 2 hours.

Where do you see this?

Processing of "new" (not previously encountered) prefixes is described in 5.5.3(d) and it only mentions that the valid lifetime must be non-zero.

A PIO VL of 300 should be ignored if the host's current VL for the prefix is smaller than 300.

I think that you meant to say that a VL of 300 should be ignored if the host's current VL for the prefix is greater than 300, right?

This would be quite contrary to what the DecrementLifetime option does - it's purpose is to synchronise the ageing of prefix information on hosts by reducing or decreasing the VL. The result of receiving a DecrementLifetimes PIO is VL on the host is reduced to what is in the PIO.

Consider the case of a prefix whose initial preferred lifetime is less than its valid lifetime. What should DecrementLifetimes do in this case?

Once the hosts prefix ageing is synchronised, and the age of the prefix is below 7200 seconds on all of the hosts, the hosts will ignore any RA PIOs with a VL of less than 7200 seconds, which is why there is no point sending these DecrementLifetime RA PIOs from that point in time on wards.

It is true that hosts that already know about the prefix will not adjust the valid lifetimes based on these router advertisements. However, a new host (or device) on the network will process the RAs and add address(es) with a valid lifetime of less than 2 hours. I have tested this with Linux (including Android), Windows, and Apple iOS devices.

[markzzzsmith]

On Tue, 29 Oct 2019, 01:45 Ian Pilcher, notifications@github.com wrote:

Can you check with your isp to see why your upstream address keeps changing? How often does it change? If ISPs keep changing the upstream address we’re going to have to start NATing IPv6 to shield ourselves from this nonsense. :/

The issue isn't that it changes frequently. (I honestly don't know how often it changes, as I'm just in the process of setting IPv6 up.) The issue is that it can change (probably about as often as my IPv4 address.),

Yes. This is the mistake.

A conversation about this issue and a related Internet Draft (it has come up before) is going on in the IETF.

Basically ISPs are trying to persist with their existing IPv4 per BNG/BRAS/NAS IP pool model. That model is actually a carry over from dial up. It's decades old.

IPv4+NAT was similar enough to dial up that they could continue to use that model. However that model cannot be used with IPv6 and end-to-end addressing (i.e. no NAT), without breaking IPv6.

ISPs could change their addressing model so that customers get stable and persistent prefixes. The ISP I worked for who introduced residential IPv6 did - all residential customers get a stable and persistent prefix as part of the service. It isn't a paid extra.

Those ISPs who won't change to this are causing this problem and then expecting others (IETF, CPE vendors, Host vendors, customers like you) to deal with the consequences, even though the ISP could fix it.

and I want my home network to deal with such changes as gracefully as

possible.

The term being used to describe this issue is "flash renumbering". Flash renumbering fundamentally can never be graceful because its abrupt.

—

You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reubenhwk/radvd/issues/116?email_source=notifications&email_token=ADLQA7LNVKRZAS6EBSM3JRTQQ33IBA5CNFSM4JE4CZH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECND62I#issuecomment-546979689, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLQA7O5PN56TWYECLX3M5TQQ33IBANCNFSM4JE4CZHQ .

[markzzzsmith]

On Tue, 29 Oct 2019, 02:01 Ian Pilcher, notifications@github.com wrote:

Yes. This is the real problem. A stable, always on Internet connection should always have the same addresses. If IPv6 needs to have NAT to avoid this problem, then there is no point to IPv6. The story of the work arounds the OP is trying to do to overcome what their ISP is doing to them is horrible. I wouldn't use IPv6 if it is that hard to make work from my ISP. ISPs aren't deploying IPv6 correctly if they are forcing unexpected address changes onto their customers.

ISPs are accustomed to charging extra for stable IP addresses. Anyone who thinks that they're going to willingly give up on this revenue, just because the resource is question isn't actually scarce anymore, is living in a dream world.

This is an opportunity for ISPs to distinguish themselves from their competitors. Artificial scarcity is so easy to compete against.

If IPv6 needs to have NAT to avoid this problem, then there is no point to

IPv6.

All of the "workarounds" that I'm putting in place are there to avoid using NAT'ed ULAs.

The story of the work arounds the OP is trying to do to overcome what their ISP is doing to them is horrible. I wouldn't use IPv6 if it is that hard to make work from my ISP.

I don't have any data, but given my experience with a variety of residential ISPs over the years, I'd be very surprised if many/most of them don't reserve the right to change delegated prefixes, just as they can change assigned IPv4 addresses today.

Thats slightly different. Reserving the right to change the prefix doesn't mean that they should try to make it as stable and persistent as they possibly can.

I can't take my /56 with me if I leave my ISP. However, it has been the same /56 in the 8 year I've lived here and been their customer.

As to the second point, I guess I'm just stubborn.

ISPs aren't deploying IPv6 correctly if they are forcing unexpected address changes onto their customers.

Have you actually dealt with a residential ISP? I consider it a miracle that I can actually get a /56 delegation.

Given how long IPv6 has been coming, and people have been told it is coming, there really isn't an excuse for deploying it badly.

The information is out there if you look for it.

From 2011, see slide 6.

https://www.slideshare.net/markzzzsmith/residential-ipv6-cpe-what-not-to-do-and-other-observations

I'm "lucky" enough to actually have 2 ISPs service my area; the other one

doesn't offer IPv6 at all.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reubenhwk/radvd/issues/116?email_source=notifications&email_token=ADLQA7MAJ2Q45VZCFSQM263QQ35EZA5CNFSM4JE4CZH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECNF6CY#issuecomment-546987787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLQA7OWDUB4QSICYPH43PDQQ35EZANCNFSM4JE4CZHQ .

[markzzzsmith]

On Tue, 29 Oct 2019, 02:34 Ian Pilcher, notifications@github.com wrote:

A PIO VL of 300 should be ignored if the host has not seen any previous advertisements of this prefix, because VL of 300 is smaller than 2 hours.

Where do you see this?

Processing of "new" (not previously encountered) prefixes is described in 5.5.3(d) and it only mentions that the valid lifetime must be non-zero.

I forget that you're dealing with a new prefix, because it isn't the common case i.e. it's the first RA PIO, where as the common case is the second and subsequent set of ongoing RAs for the prefix.

A PIO VL of 300 should be ignored if the host's current VL for the prefix

is smaller than 300.

I think that you meant to say that a VL of 300 should be ignored if the host's current VL for the prefix is greater than 300, right?

Yes, however I'm reading part (e), because that's the context for DecrementLifetimes.

DecrementLifetimes applies to a sequence of RA PIOs for the same prefix, and only takes effect on the second and subsequent RAs for a prefix's PIO.

DecrementLifetimes can't apply to a single first RA PIO because "Decrement" is meaningless - it has to be in the context of a the lifetime values if the previous RA PIO for the prefix.

This would be quite contrary to what the DecrementLifetime option does -

it's purpose is to synchronise the ageing of prefix information on hosts by reducing or decreasing the VL. The result of receiving a DecrementLifetimes PIO is VL on the host is reduced to what is in the PIO.

Consider the case of a prefix whose initial preferred lifetime is less than its valid lifetime.

That's the normal and common case for PL and VL. It's that way to suit graceful renumbering.

The odd case is to have them the same value. I understand why you're doing it, however it's not common because you're in a situation that isn't the IPv6 design and isn't supposed to be common.

What should DecrementLifetimes do in this case?

What it already does.

DecrementLifetimes purpose is to synchronise the aging of prefixes and addresses among hosts, and to try to ensure that hosts adresses age out completely when the DHCPv6-PD prefix ages out.

This really goes to the crux of the problem.

You ISP gives you a prefix that has a VL of e.g. 4 weeks. That is really a promise from the ISP that you should be able to use that prefix for 4 weeks reliability.

However your ISP then doesn't live up to that promise, because they then go and change the prefix on you before the 4 weeks is up.

Your ISP is promising you something but not delivering it.

Once the hosts prefix ageing is synchronised, and the age of the prefix is

below 7200 seconds on all of the hosts, the hosts will ignore any RA PIOs with a VL of less than 7200 seconds, which is why there is no point sending these DecrementLifetime RA PIOs from that point in time on wards.

It is true that hosts that already know about the prefix will not adjust the valid lifetimes based on these router advertisements. However, a new host (or device) on the network will process the RAs and add address(es) with a valid lifetime of less than 2 hours. I have tested this with Linux (including Android), Windows, and Apple iOS devices.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reubenhwk/radvd/issues/116?email_source=notifications&email_token=ADLQA7IFPABDAFM56S2D5ELQQ4BBVA5CNFSM4JE4CZH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECNJ6UQ#issuecomment-547004242, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLQA7KBTWPOKXKL4SQZRV3QQ4BBVANCNFSM4JE4CZHQ .

[ipilcher]

Closing this issue.

[tonusoo]

I have a similar setup to @ipilcher where dhclient exit hook script keeps advertising the deprecated prefix, but instead of static AdvValidLifetime and AdvPreferredLifetime I'm propagating the values set by my ISP DHCPv6 server(s). Expired prefixes are eventually removed from the /etc/radvd.conf by another script executed by cron.

Sorry for posting to closed issue, but perhaps it's useful for somebody.

[Neustradamus]

@robbat2, @stappersg: What do you think about @tonusoo comment?

[robbat2]

Nothing easy is going to change here, because it requires keeping state in a way that we don't do presently in radvd. Doing it properly requires keeping dynamic configuration over reloads

The closest we can come is using the ::/64 as suggested originally by @reubenhwk and adding logic that says if the router has a prefix it's busy deprecating, ensure everything downstream also follows that.

If it's being manually configured (e.g. not using ::/64), then the user is responsible for the config that handles it. Sure we could improve the config file, but it's really keeping state to say deprecate prefix X until timestamp Y, and then forget prefix X