Subject: [v6ops] clarification regarding RFC7084 G-5 requirement

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 09:57:59 +0200 (CEST)

Hi,

RFC7084:

    G-5:  By default, if the IPv6 CE router is an advertising router and
          loses its IPv6 default router(s) and/or detects loss of
          connectivity on the WAN interface, it MUST explicitly
          invalidate itself as an IPv6 default router on each of its
          advertising interfaces by immediately transmitting one or more
          Router Advertisement messages with the "Router Lifetime" field
          set to zero [RFC4861].

"loses its IPv6 default router". Does this imply that if it receives a 
zero-lifetime RA on its WAN port, then it should perform above action?

If this happens (there are no eligable routers on WAN anymore), should it 
also on its LAN ports send PIO with zero-lifetime/preferred for the 
DHCPv6-PD based prefixes it has been announcing, and invalidating the 
delegated PD?

I think my question is:

When receiving a zero-lifetime RA on WAN resulting in no router availabe 
on WAN, should this interface be considered "down", same as if the 
physical interface went down, and then all actions should be performed 
that are stated in RFC7084 for "WAN down" event?

The context of my question is when receiving this RA on WAN:

09:54:25.400641 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) 
fe80::2200:ff:fe00:1 > ff02::1: [icmp6 sum ok] ICMP6, router 
advertisement, length 64
         hop limit 64, Flags [other stateful], pref low, router lifetime 30s, reachable time 0s, retrans time 0s
           source link-address option (1), length 8 (1): 20:00:00:00:00:01
             0x0000:  2000 0000 0001
           mtu option (5), length 8 (1):  1420
             0x0000:  0000 0000 058c
           prefix info option (3), length 32 (4): 2003:1809:24:1500::/64, Flags [onlink, auto], valid time 60s, pref. time 50s
             0x0000:  40c0 0000 003c 0000 0032 0000 0000 2003
             0x0010:  1809 0024 1500 0000 0000 0000 0000

When no RA has been seen for 31 seconds (and router lifetime is now 0 as 
the 30s above has passed), should the router in question send (on LAN) an 
RA invalidating both itself as a router, and send 0 preferred lifetime for 
the PIOs/RIOs it's been advertising based on DHCPv6-PD prefix it has on 
the above WAN?

>From what I can find in RFC7084, only the first part is specified, ie 
invalidating itself as a router. It doesn't invalidate the delegated 
prefix, neither from a DHCPv6 timer point of view, nor in its RAs 
advertised.

>From how I read RFC7084, I can't blame the router vendor for doing the 
wrong thing...

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Timothy Winters <[email-masked]>
Date: Thu, 3 Aug 2017 06:58:44 -0400

Hi Mikael,

> DHCPv6-PD based prefixes it has been announcing, and invalidating the
It doesn't invalidate the PIO for IA_PD, it does send an RA with router
lifetime of 0 on the LAN.  The logic behind not invalidating the PIO is
devices on the LAN might be communicating using the global addresses and
that should still work.

> on WAN, should this interface be considered "down", same as if the physical
> interface went down, and then all actions should be performed that are
> stated in RFC7084 for "WAN down" event?
>

> fe80::2200:ff:fe00:1 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement,
> length 64
>           prefix info option (3), length 32 (4): 2003:1809:24:1500::/64,
> Flags [onlink, auto], valid time 60s, pref. time 50s
> the PIOs/RIOs it's been advertising based on DHCPv6-PD prefix it has on the
> above WAN?
>
A CE Router should transmits a RA with a lifetime 0 on the LAN after the
 WAN times out.   The IA_PD (DHCPV6) address aren't affected by this action.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 13:40:26 +0200 (CEST)

> devices on the LAN might be communicating using the global addresses and 

Ok, makes sense. Causes me problems though.

> WAN times out.   The IA_PD (DHCPV6) address aren't affected by this action.

The problem here is that when the WAN connectivity is then re-provisioned 
and it starts to receive RAs from a different router, it never invalidates 
the PD. It just keeps sitting there until it times out. This is typically 
after 120 seconds (we have pretty low timers on that thing as well).

So basically I have no way to cut down the time it takes to get things 
going again below the 3-5 minutes I am at right now. (the use-case is that 
we have a customer service portal the customer ends up in if there is no 
service configured on the port, and I'm trying to cut down the time it 
takes for everything to settle down again in fully working "Internet mode" 
which involves asking for new PD, letting old one time out etc.

Now, if I could only do PD with a mechanism where I can immediately update 
the host that "this is not valid anymore" instead of waiting for the 
device to poll, or the resource times out. :(

---

From: Timothy Winters <[email-masked]>
Date: Thu, 3 Aug 2017 08:05:19 -0400

Hi Mikael,

Yea there isn't much that can be done if IA_PD has been invalidated other
then timeout.    Meaning the DHCPv6 Server needs to give it a IA_PD
lifetime of 0.   A DHCPv6 Reconfigure/Rebind it will still keep the IA_PD
until it times out unless a server explicitly times it out.

A solution that comes to mind, is a host gets two global addresses it might
help in the future if they implemented something like (
https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-01).   A
Host would choose the lifetime with a higher lifetime.

Regards,
Tim

On Thu, Aug 3, 2017 at 7:40 AM, Mikael Abrahamsson <[email-masked]> wrote:

> the host that "this is not valid anymore" instead of waiting for the device
> to poll, or the resource times out. :(
>
>
> --

--

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 14:11:31 +0200 (CEST)

On Thu, 3 Aug 2017, Timothy Winters wrote:

> A solution that comes to mind, is a host gets two global addresses it 
> might help in the future if they implemented something like ( 

Yes, you're right, as soon as a new PD is available and PIOs are sent for 
that, hosts will start to use those addresses instead. The problem is that 
the DHCPv6-PD request process isn't triggered by WAN router RA timing out 
and potentially new router RAs showing up with different prefix?

What controls the PD timeout is its own timers, and as far as I know, this 
is in no way affected by what RAs are seen on WAN.

It would be an operational change to say "look, if WAN prefix changed, 
perhaps you should re-do the PD request process just in case?" This would 
require no protocol change, it's just a recommendation based on what's 
seen on the WAN?

---

From: Timothy Winters <[email-masked]>
Date: Thu, 3 Aug 2017 08:44:59 -0400

Hi Mikael,
    So 3315bis is attempting to address this exact issue, Section 18.2.12.
Which basically says if you think a link may have changed you should
probably should check for updated information.   Does the DHCPv6 Server
know to set the old Prefix to zero in this use case?   If not, that won't
help since it will still need to time-out.

Regards,
Tim

On Thu, Aug 3, 2017 at 8:11 AM, Mikael Abrahamsson <[email-masked]> wrote:

> require no protocol change, it's just a recommendation based on what's seen
> on the WAN?
>
>
> --

--

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Aug 2017 12:50:07 +0000

And, if you prefer different wording in this 3315bis section, now’s the time to raise that as we hope to send this on shorter (there will be a -10 before we do that).

  *   Bernie

From: v6ops <[email-masked]> on behalf of Timothy Winters <[email-masked]>
Date: Thursday, August 3, 2017 at 8:44 AM
To: Mikael Abrahamsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement

Hi Mikael,
    So 3315bis is attempting to address this exact issue, Section 18.2.12.  Which basically says if you think a link may have changed you should probably should check for updated information.   Does the DHCPv6 Server know to set the old Prefix to zero in this use case?   If not, that won't help since it will still need to time-out.

Regards,
Tim

On Thu, Aug 3, 2017 at 8:11 AM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, 3 Aug 2017, Timothy Winters wrote:
A solution that comes to mind, is a host gets two global addresses it might help in the future if they implemented something like ( https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-01).  A Host would choose the lifetime with a higher lifetime.

Yes, you're right, as soon as a new PD is available and PIOs are sent for that, hosts will start to use those addresses instead. The problem is that the DHCPv6-PD request process isn't triggered by WAN router RA timing out and potentially new router RAs showing up with different prefix?

What controls the PD timeout is its own timers, and as far as I know, this is in no way affected by what RAs are seen on WAN.

It would be an operational change to say "look, if WAN prefix changed, perhaps you should re-do the PD request process just in case?" This would require no protocol change, it's just a recommendation based on what's seen on the WAN?

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>

--

Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 14:55:50 +0200 (CEST)

> help since it will still need to time-out.

No, the old DHCPv6-PD server is now gone, not available anymore, will 
never answer you again. The link now has a brand new DHCPv6-PD server you 
can ask for completely different prefixes, which it will happily give you.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 15:34:00 +0200 (CEST)

On Thu, 3 Aug 2017, Bernie Volz (volz) wrote:

> And, if you prefer different wording in this 3315bis section, now’s the 
> time to raise that as we hope to send this on shorter (there will be a 
> -10 before we do that).

https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-09#section-18.2.12

    If the client has any valid delegated prefixes obtained from the DHCP
    server, the client MUST initiate a Rebind/Reply message exchange as
    described in Section 18.2.5, with the exception that the
    retransmission parameters should be set as for the Confirm message
    (see Section 18.2.3).  The client includes IA_NAs, IA_TAs, and
    IA_PDs, along with the associated leases, in its Rebind message.

>From what I can tell, the events are like this in my current 
implementation:

15:00:05 client does renew, and receives Reply.
15:00:35 client does renew, and receives Reply.
15:01:00 port is reprovisioned, we now see RAs from different router(there 
is no 0-lifetime RA sent from old router before this)
15:01:05 client does renew, no answer
15:01:15 client does renew, no answer
15:01:35 client does renew, no answer
15:01:35 client does renew, no answer
15:01:35 client does rebind, no answer
15:01:44 client does rebind, no answer
15:02:03 client does rebind, no answer
15:02:35 client does rebind, no answer
15:02:35 client does solicit, and receives advertise
15:02:37 client does request, and receives reply

After 15:01:00 there is a new DHCPv6-PD server available. 15:01:00 both 
WAN router and HGW does DAD and at 15:01:01 the new GUA based on the new 
RA/PIO is ready to go and since it has a higher preferred lifetime, it'll 
be used from now on. At around 15:01:31 I guess the old router is no 
longer counted as valid, at at 15:01:57 (one minute after the last RA seen 
from old server) means that PIO is no longer valid.

It then takes DHCPv6 processing 15:02:36 until it goes into solicit and 
acquires a new PD plus other parameters.

Now, I am no DHCPv6 expert, but would it hurt to go into solicit a lot 
earlier than it does in my timeline described before, when WAN RAs change 
enough? I know we might not want to invalidate the old prefix based on 
this, but what would potentially go wrong if the device went into solicit 
much earlier in the above process?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Aug 2017 14:16:41 +0000

Mikael:

I assume your "client" here is the DHCPv6 client on the WAN link?

It looks like the lifetimes for DHCPv6 PD were fairly short?

15:00:05 client does renew, and receives Reply.
15:00:35 client does renew, and receives Reply.
15:01:00 port is reprovisioned, we now see RAs from different router(there is no 0-lifetime RA sent from old router before this)
15:01:05 client does renew, no answer

And, thus I think the event at 15:01:00 did not trigger anything special.

The 3315bis has new text in https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-09#section-18.2.12:

   If not associated with one of the above mentioned conditions, a
   client MAY initiate a Renew/Reply exchange (as if the T1 time
   expired) as described in Section 18.2.4 or an Information-Request/
   Reply exchange as described in Section 18.2.6 if the client detects a
   significant change regarding the prefixes available on the link (when
   new are added or existing are deprecated) as this may indicate a
   configuration change.  However, a client MUST rate limit such
   attempts to avoid flooding a server with requests when there are link
   issues (for example, only doing one of these at most every 30
   seconds).

But perhaps this recommendation to use Renew/Reply is flawed if the old (WAN) router is gone? We were thinking that this was more likely a situation where a new prefix was added, or some prefixes were removed. We had figured a change of router would likely involve a link reconnection (which does trigger Rebind/Reply as earlier in that above referenced section). But it looks like in your case there is no link change. And, even if the client detected a "significant change", the Renew would fail if that router is gone.

- Bernie

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, August 03, 2017 9:34 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Timothy Winters <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement

On Thu, 3 Aug 2017, Bernie Volz (volz) wrote:

> And, if you prefer different wording in this 3315bis section, now’s 
> the time to raise that as we hope to send this on shorter (there will 
> be a
> -10 before we do that).

15:01:00 port is reprovisioned, we now see RAs from different router(there is no 0-lifetime RA sent from old router before this)

After 15:01:00 there is a new DHCPv6-PD server available. 15:01:00 both WAN router and HGW does DAD and at 15:01:01 the new GUA based on the new RA/PIO is ready to go and since it has a higher preferred lifetime, it'll be used from now on. At around 15:01:31 I guess the old router is no longer counted as valid, at at 15:01:57 (one minute after the last RA seen from old server) means that PIO is no longer valid.

It then takes DHCPv6 processing 15:02:36 until it goes into solicit and acquires a new PD plus other parameters.

Now, I am no DHCPv6 expert, but would it hurt to go into solicit a lot earlier than it does in my timeline described before, when WAN RAs change enough? I know we might not want to invalidate the old prefix based on this, but what would potentially go wrong if the device went into solicit much earlier in the above process?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 16:30:30 +0200 (CEST)

On Thu, 3 Aug 2017, Bernie Volz (volz) wrote:

> But perhaps this recommendation to use Renew/Reply is flawed if the old 
> (WAN) router is gone? We were thinking that this was more likely a 
> situation where a new prefix was added, or some prefixes were removed. 
> We had figured a change of router would likely involve a link 
> reconnection (which does trigger Rebind/Reply as earlier in that above 
> referenced section). But it looks like in your case there is no link 
> change. And, even if the client detected a "significant change", the 
> Renew would fail if that router is gone.

Correct. The port is completely reprovisioned, and there is no physical 
link indication that this has happened. The only indication to the client 
is that it's now receiving RAs with a completely different subnet from 
another router, and the old router (after 30 second) is no longer valid.

I consider this a significant enough change that I'd like for the 
DHCPv6-PD requestor (client) to go into solicit mode. However, I don't 
know the implications of this on normal operation. What is the downside of 
going into solicit mode in case the old DHCPv6 server is still there?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Aug 2017 10:34:07 -0400

On Aug 3, 2017, at 10:30 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Correct. The port is completely reprovisioned, and there is no physical link indication that this has happened. The only indication to the client is that it's now receiving RAs with a completely different subnet from another router, and the old router (after 30 second) is no longer valid.

This is a pretty broken situation.   Can you talk more about this use case?

That said, I think your point is valid: if the RA for the old prefix goes away, and there's a new prefix being advertised, the client should be trying to get a new address.   But why are you even doing DHCP allocation on this link?   It seems like the use case for DHCP allocation is on a thoroughly managed network, where we would essentially never see a flash renumber event.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Aug 2017 14:36:12 +0000

While it could take an additional set of round trip messages, the Rebind/Reply would be better since it would not involve to "stop" using the existing address/delegated prefixes that a Solicit would entail. And, in many cases we might expect that the original router is still there? So, I think the general case should be Rebind/Reply (which might be successful or result in Solicit/Reply after several attempts).

But perhaps the client can be smarter about this if it doesn't have any (DHCPv6 assigned) address/delegated prefixes (i.e., they might have been deprecated) then going to Solicit directly would of course be better.

- Bernie

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, August 03, 2017 10:31 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Timothy Winters <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: RE: [v6ops] clarification regarding RFC7084 G-5 requirement

I consider this a significant enough change that I'd like for the DHCPv6-PD requestor (client) to go into solicit mode. However, I don't know the implications of this on normal operation. What is the downside of going into solicit mode in case the old DHCPv6 server is still there?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Aug 2017 14:41:40 +0000

Ted:

Agreed it would be interesting to understand exactly why this happens.

I could see this occurring in cases where a subscriber is moved for some reason, but that should be a rare event and hopefully planned (i.e., use much shorter lifetimes). And, that may be exactly what was happening here as the PD lifetimes were rather short.

What's a bit odd in Mikael's timeline:

Is why there was nothing received to the Rebind requests (these would have been multicast)? This should have gone to all servers and hence triggered a response from the DHCP server.

In theory, new configuration should have been available closer to 15:01:35, almost a minute earlier than it was?

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, August 03, 2017 10:34 AM
To: Mikael Abrahamsson <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement

On Aug 3, 2017, at 10:30 AM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
Correct. The port is completely reprovisioned, and there is no physical link indication that this has happened. The only indication to the client is that it's now receiving RAs with a completely different subnet from another router, and the old router (after 30 second) is no longer valid.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 17:32:36 +0200 (CEST)

> This is a pretty broken situation.  Can you talk more about this use 

C1-RG-L2-R1

C1 = Customer computer
RG = Residential Gateway (RFC7084 style device)
L2 = L2 aggregation switch
R1 = L3 aggregation device.

R1 can either be in "L2 tunneling mode" to somewhere, or it's a regular 
router, sending RAs.

When customer doesn't have any serivice, R1 is in "L2 tunneling mode" to a 
cloud based signup portal. This portal sends RAs, handled DHCPv6-PD, over 
the tunnel.

Customer presses "signup" to a service.

R1 is now reprovisioned into L3 mode and starts sending RAs, is a DHCPv6 
relay etc.

RG has no idea this happened, because it's connected to L2 switch that 
doesn't go "down".

> That said, I think your point is valid: if the RA for the old prefix 
> goes away, and there's a new prefix being advertised, the client should 
> be trying to get a new address.  But why are you even doing DHCP 
> allocation on this link?  It seems like the use case for DHCP allocation 
> is on a thoroughly managed network, where we would essentially never see 
> a flash renumber event.

We have no other mechanism to hand out prefixes apart from DHCPv6-PD. I'd 
be happy to deprecate that and create ND based method. Right now I am not 
great fan of DHCP.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 17:41:22 +0200 (CEST)

On Thu, 3 Aug 2017, Bernie Volz (volz) wrote:

> While it could take an additional set of round trip messages, the 
> Rebind/Reply would be better since it would not involve to "stop" using 
> the existing address/delegated prefixes that a Solicit would entail.

So it can never go into solicit without stopping to use the allocated 
resources?

Isn't there a way to use DHCPv6 client to "discover" all DHCPv6 
relays/servers existing on the link, without stopping to use all current 
resources earlier handed out via DHCPv6?

Because if it did, it could run this "what DHCPv6 based servers are there 
out there?" and if the old one isn't available, my RA based resources are 
now no longer valid, perhaps this is a good indication that my DHCPv6 
based resources are no longer valid either, and I should stop using them? 
At least this could be a use-case for an RFC7084 type device on its WAN 
port, this might not make the most sense for other use-cases.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 17:45:26 +0200 (CEST)

On Thu, 3 Aug 2017, Bernie Volz (volz) wrote:
>
> Is why there was nothing received to the Rebind requests (these would 
> have been multicast)? This should have gone to all servers and hence 
> triggered a response from the DHCP server.

The rebind requests were sent to MAC 33:33:00:01:00:02 with IPv6 dst 
address ff02::1:2

So yes, looks like multicast to me. The rebind and solicits look identical 
from a src/dst/mac point of view.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 17:50:08 +0200 (CEST)

On Thu, 3 Aug 2017, Mikael Abrahamsson wrote:

>> Is why there was nothing received to the Rebind requests (these would have 
>> been multicast)? This should have gone to all servers and hence triggered a 
>> response from the DHCP server.
>
> The rebind requests were sent to MAC 33:33:00:01:00:02 with IPv6 dst address 
> ff02::1:2
>

Just to clarify. The signup portal has completely different prefixes in 
its PD pool compared to the active port DHCPv6 PD pool. So after 
reprovisioning of the port the RG is doing rebind for IA_PD prefix that no 
DHCPv6 server/relay on the link is configured to serve.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Aug 2017 12:00:35 -0400

On Aug 3, 2017, at 11:50 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Just to clarify. The signup portal has completely different prefixes in its PD pool compared to the active port DHCPv6 PD pool. So after reprovisioning of the port the RG is doing rebind for IA_PD prefix that no DHCPv6 server/relay on the link is configured to serve.

If your DHCP server were configured correctly, it would respond to the Rebind indicating that the lifetime of the sign-on mode prefix is zero.   Also, now that I think about it, aren't Renews multicast as well?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Aug 2017 16:05:16 +0000

Yeah, that seems rather odd as to why the "new" DHCP server didn't respond to the Rebind requests with something - likely it should have reported NoBinding or a Reply with 0 lifetimes and perhaps a new delegated prefix.

It is possible (see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-09#section-18.2.12) that the server chose to drop the Rebind as that is an option. However, it does have consequences as you can see so is generally not the best choice.

You might contact the server vendor to see about this?

- Bernie

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, August 03, 2017 11:45 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Ted Lemon <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: RE: [v6ops] clarification regarding RFC7084 G-5 requirement

> triggered a response from the DHCP server.

The rebind requests were sent to MAC 33:33:00:01:00:02 with IPv6 dst address ff02::1:2

So yes, looks like multicast to me. The rebind and solicits look identical from a src/dst/mac point of view.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Aug 2017 16:07:09 +0000

> Also, now that I think about it, aren't Renews multicast as well?

Yes, they are. But include a server-id option and so if the DHCPv6 server at the other end has also changed, this would not match and thus drops the packet. I have assumed that is the case here.

-          Bernie

Sent: Thursday, August 03, 2017 12:01 PM

On Aug 3, 2017, at 11:50 AM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
Just to clarify. The signup portal has completely different prefixes in its PD pool compared to the active port DHCPv6 PD pool. So after reprovisioning of the port the RG is doing rebind for IA_PD prefix that no DHCPv6 server/relay on the link is configured to serve.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Aug 2017 18:16:40 +0200 (CEST)

On Thu, 3 Aug 2017, Bernie Volz (volz) wrote:

> Yes, they are. But include a server-id option and so if the DHCPv6 
> server at the other end has also changed, this would not match and thus 
> drops the packet. I have assumed that is the case here.

I do not see any server-id option in the DHCPv6 part of the rebind.

The renew XID is different from the rebind XID. The renew has a server-id, 
the rebind does not.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Aug 2017 16:47:38 +0000

>I do not see any server-id option in the DHCPv6 part of the rebind.

Renew would have server-id; Rebind would NOT have server-id. Sorry if that wasn't clear.

- Bernie

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, August 03, 2017 12:17 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Ted Lemon <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: RE: [v6ops] clarification regarding RFC7084 G-5 requirement

On Thu, 3 Aug 2017, Bernie Volz (volz) wrote:

> server at the other end has also changed, this would not match and 
> thus drops the packet. I have assumed that is the case here.

The renew XID is different from the rebind XID. The renew has a server-id, the rebind does not.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 4 Aug 2017 01:07:39 +0200

On 3 Aug 2017 15:56, "Mikael Abrahamsson" <[email-masked]> wrote:

Does the DHCPv6 Server
> help since it will still need to time-out.

No, the old DHCPv6-PD server is now gone, not available anymore, will never
answer you again. The link now has a brand new DHCPv6-PD server you can ask
for completely different prefixes, which it will happily give you.

This sort of thing is precisely why DHCPv6 is not a good protocol to
configure dynamic networks such as home networks.

In DHCPv6, it's very hard to change anything dynamically because it's
driven by client requests. Mechanisms to tell clients to ask again exist
(e.g., RECONFIGURE), but clients apparently mostly don't support them.

Additionally, one of the advantages of DHCPv6 over other forms of
configuration is the ability to do centralised management - but that
advantage is hard or impossible to achieve when things change, because the
DHCPv6 server would need to listen to all relevant configuration or
topology changes that could affect client addresses in order to properly
update clients. For example, imagine a network using multiprocessor
multi-prefix multihoming such as a homenet or a network using the SADR
multihoming drafts bring worked on in the routing and v6ops working groups.
In such networks, when an upstream goes down the network needs to deprecate
all the IP addresses in a certain prefix. Having the DHCPv6 server keep
track of all link changes and issue RECONFIGUREs doesn't scale, and it's
not even possible at all if the DHCPv6 server is partitioned from the
clients.

Finally, I'm not even sure if RECONFIGURE works at all if the original
server is gone/crashed.

DHCP works well in IPv4 because we rarely change things  - you're always
192.168.0.113/20, and your default gateway is always 192.168.15.254. When
anything changes, the network handles it using NAT or VRRP. That model
can't provide end-to-end connectivity in a network that changes.

Perhaps we need a draft to explain this? It's fine to use DHCPv6 to
configure things that never change, such as static DNS addresses that are
anycasted and never renumbered. But it might not be obvious to
administrators that if your network changes *and* you need end-to-end
connectivity, DHCPv6 doesn't handle that well -or at all.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 4 Aug 2017 00:04:46 +0000

Lorenzo, we know your position.

In this case it looks like it is more likely an implementation issue/decision on the (new) server not to respond as it should.

And, we are trying to make sure the updated standard encourages using appropriate input and actions when changes are noticed.

- Bernie (from iPad)

On Aug 3, 2017, at 7:08 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On 3 Aug 2017 15:56, "Mikael Abrahamsson" <[email-masked]<mailto:[email-masked]>> wrote:
Does the DHCPv6 Server
know to set the old Prefix to zero in this use case?   If not, that won't
help since it will still need to time-out.

No, the old DHCPv6-PD server is now gone, not available anymore, will never answer you again. The link now has a brand new DHCPv6-PD server you can ask for completely different prefixes, which it will happily give you.

This sort of thing is precisely why DHCPv6 is not a good protocol to configure dynamic networks such as home networks.

In DHCPv6, it's very hard to change anything dynamically because it's driven by client requests. Mechanisms to tell clients to ask again exist (e.g., RECONFIGURE), but clients apparently mostly don't support them.

Additionally, one of the advantages of DHCPv6 over other forms of configuration is the ability to do centralised management - but that advantage is hard or impossible to achieve when things change, because the DHCPv6 server would need to listen to all relevant configuration or topology changes that could affect client addresses in order to properly update clients. For example, imagine a network using multiprocessor multi-prefix multihoming such as a homenet or a network using the SADR multihoming drafts bring worked on in the routing and v6ops working groups. In such networks, when an upstream goes down the network needs to deprecate all the IP addresses in a certain prefix. Having the DHCPv6 server keep track of all link changes and issue RECONFIGUREs doesn't scale, and it's not even possible at all if the DHCPv6 server is partitioned from the clients.

Finally, I'm not even sure if RECONFIGURE works at all if the original server is gone/crashed.

DHCP works well in IPv4 because we rarely change things  - you're always 192.168.0.113/20<http://192.168.0.113/20>, and your default gateway is always 192.168.15.254. When anything changes, the network handles it using NAT or VRRP. That model can't provide end-to-end connectivity in a network that changes.

Perhaps we need a draft to explain this? It's fine to use DHCPv6 to configure things that never change, such as static DNS addresses that are anycasted and never renumbered. But it might not be obvious to administrators that if your network changes *and* you need end-to-end connectivity, DHCPv6 doesn't handle that well -or at all.
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Aug 2017 03:06:36 +0200 (CEST)

On Fri, 4 Aug 2017, Bernie Volz (volz) wrote:

> In this case it looks like it is more likely an implementation 
> issue/decision on the (new) server not to respond as it should.

If we could send zero-lifetime RA before reconfiguring, the RA controlled 
part of this could be up and running again in a few seconds.

Even if DHCPv6 worked perfectly according to standards, it would as far as 
I understand not be up and running again in under a minute (instead of the 
two minutes I'm currently seeing).

We are investigating why the rebind isn't answered, so we can cut a minute 
of the time here.

But I have no way to signal to the DHCPv6-PD client in the RG that it 
should drop all resources NOW and go back into solicit. Some people think 
this is a feature, because it means you can't "DoS" an entire LAN segment 
with a single packet. There are always pro:s and con:s.

So I'm in agreement with Lorenzo here. DHCP is not well suited for 
fast-flux environments because it's driven by device polling and there is 
no push.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Aug 2017 21:28:04 -0400

On Aug 3, 2017, at 9:06 PM, Mikael Abrahamsson <[email-masked]> wrote:
> If we could send zero-lifetime RA before reconfiguring, the RA controlled part of this could be up and running again in a few seconds.

Why can't you?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Aug 2017 05:11:49 +0200 (CEST)

>> If we could send zero-lifetime RA before reconfiguring, the RA controlled part of this could be up and running again in a few seconds.

We can. But it won't help much, I won't invalidate the PD because of that. 
So the RG will have WAN connectivity, but the computers on its LAN will 
still have the old, non-functioning PD based addresses.

If is our gateway, we could modify it to do "/etc/init.d/network restart" 
(or just invalidate everything DHCP and restart that part) as soon as it 
sees a zero-lifetime RA (or when the WAN prefix RA changes). I tried this 
manually, and it works, it brings down the transition time a lot.

I would like to support customer-purchased gateways, that's why I'm 
bringing it here so DHCP documents can be updated with this kind of 
recommendation (and next time we rev RFC7084, that could be updated as 
well). That however requires that we reach consensus on how it should be 
done.

Just invalidating everything DHCP from WAN because we see other RA ruins 
the MIF use-case. Btw, does DHCP even support the MIF use-case without 
modifications? Can DHCP and RA information be tied together without PVD 
identifier? Heuristically perhaps, by seeing the MAC address used for DHCP 
and RA packets, if they match, then they belong together?

---

From: Gert Doering <[email-masked]>
Date: Fri, 4 Aug 2017 07:40:20 +0200

Hi,

> configure dynamic networks such as home networks.

When did you start opposing DHCPv6-PD as well (which is what this is about)?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 4 Aug 2017 14:56:13 +0900

> When did you start opposing DHCPv6-PD as well (which is what this is

I don't think it's useful for anyone to oppose DHCPv6 PD since we don't
really have an alternative. :-)

However, I do think we should be mindful of the limitations of the
protocols we use. And at least to me it's pretty clear, as a general rule
that when using DHCPv6 it's very hard to change things. I think it would be
good if we could find consensus on an operational guidance document that
explained this limitation.

One way to do this might be to have a document to explain the strengths and
weaknesses of RA and DHCPv6 for layer 3 configuration parameters. I'm not
particularly hopeful that we could gain consensus on any actual
recommendations (except maybe a vague "if you want property X and protocol
Y is not good at property X, then we recommend you don't use protocol Y"),
but perhaps we can gain consensus on the facts.