Subject: [v6ops] Prefix Delegation RS/RA vs DHCPv6

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Aug 2017 18:25:35 +0000

Hi, it seems like recent works and discussions have postulated a means for delegating
IPv6 prefixes to nodes using RS/RA instead of DHCPv6 PD. But, there really isn't any
L3 protocol defined for clients to control their prefix delegations using RS/RA whereas
DHCPv6 PD provides the client with the "four R's" (Request, Renew, Rebind, Release).

So, for clients to control and manage their prefix delegations it seems like DHCPv6
gives the clients the most flexibility and control in terms of L3 messaging, whereas
for RS/RA there would need to be either a new L3 protocol or some form of adjunct
L2 messaging. What am I missing?

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 29 Aug 2017 21:39:43 +0200 (CEST)

> L2 messaging. What am I missing?

DHCP is fundamentally a polling protocol and if a lease has been handed 
out, it's not yours and you can keep it until it times out.

I would like us to find a solution where the network can revoke a 
resource it has "leased". Right now we don't have a full solution for 
this. DHCPv6 and RS/RA are basically ships in the night and it's not clear 
how messages sent using one protocol, would affect the other. A minimum 
would be some kind of coupling between a DHCPv6 relay router and what it 
puts in the RA and how this affects the DHCPv6 information.

Perferrably I'd like to be able to do everything without DHCPv6 at all.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Aug 2017 20:00:23 +0000

Hi Mikael,

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2017 12:40 PM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6
> 

In DHCPv6, the client is responsible for reliability. It asks the server for a PD
and keeps asking until it gets a Reply. The client is also responsible for managing
its own leases and renewing them before they  time out.

> this.

DHCPv6 Reconfigure (the fifth "R").

> DHCPv6 and RS/RA are basically ships in the night and it's not clear

In DHCPv6, the PD activity is client-directed. In the RS/RA based schemes,
the PD activity is network-directed. That is a marked difference and needs
to be examined according to the use cases. 

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Aug 2017 08:14:08 +1200

> to be examined according to the use cases. 

Shouldn't you add HNCP to this discussion?

Or even draft-ietf-anima-prefix-management, at a stretch.

In any case, there are many ways to tackle this topic.

     Brian

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Aug 2017 21:56:45 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2017 1:14 PM
> To: Templin, Fred L <[email-masked]>; Mikael Abrahamsson <[email-masked]>
> Cc: [email-masked]

Interesting. It looks like it does DHCPv6 PD according to RFC7788?

> Or even draft-ietf-anima-prefix-management, at a stretch.

Can it use DHCPv6 PD or PIO-X instead?

> In any case, there are many ways to tackle this topic.

Probably, but I think there are two primary categories: 1) network-directed
and 2) client-directed. Which is more appropriate probably needs to be
examined on a case-by-case basis.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Aug 2017 10:35:45 +1200

> Interesting. It looks like it does DHCPv6 PD according to RFC7788?

As a tool, yes. In your sense, it's network-directed, because
the decisions are made by the network (HNCP being a distributed
decsion-making protocol).

> Can it use DHCPv6 PD or PIO-X instead?

So far we've assumed that it will be PD to the ultimate client
router. But actually that isn't required - a router that obtains
a prefix this way could just start using it.
 
> examined on a case-by-case basis.

The client can't invent a routable prefix, though: that always has to
managed from "above", as far as I can see.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Aug 2017 07:07:42 +0200 (CEST)

On Tue, 29 Aug 2017, Templin, Fred L wrote:

> Probably, but I think there are two primary categories: 1) 
> network-directed and 2) client-directed. Which is more appropriate 
> probably needs to be examined on a case-by-case basis.

I think whatever we come up with needs to support all of them. Client 
needs to be able to release resources, it needs to indicate that "I don't 
want this anymore, permanently" but also "I am disconnecting for a while, 
I am still interested in this resource" and also perhaps "hello, I am now 
here, can I please have my resource that I had over there" (in case of for 
instance wifi handover). The network in turn needs to be able to tell the 
device "sorry, this resource is or will soon no longer available, stop 
using it within X seconds"

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 Aug 2017 10:52:07 +0200

Le 29/08/2017 à 22:00, Templin, Fred L a écrit :
> Hi Mikael,
> 
>> -----Original Message----- From: Mikael Abrahamsson 
>> [mailto:[email-masked]] Sent: Tuesday, August 29, 2017 12:40 PM 
>> To: Templin, Fred L <[email-masked]> Cc: [email-masked]
>>> Hi, it seems like recent works and discussions have postulated a 
>>> means for delegating IPv6 prefixes to nodes using RS/RA instead 
>>> of DHCPv6 PD. But, there really isn't any L3 protocol defined
>>> for clients to control their prefix delegations using RS/RA
>>> whereas DHCPv6 PD provides the client with the "four R's"
>>> (Request, Renew, Rebind, Release).
>>> 
>>> So, for clients to control and manage their prefix delegations
>>> it seems like DHCPv6 gives the clients the most flexibility and 
>>> control in terms of L3 messaging, whereas for RS/RA there would 
>>> need to be either a new L3 protocol or some form of adjunct L2 
>>> messaging. What am I missing?
>> 
>> DHCP is fundamentally a polling protocol and if a lease has been 
>> handed out, it's not yours and you can keep it until it times out.
> 
> In DHCPv6, the client is responsible for reliability. It asks the 
> server for a PD and keeps asking until it gets a Reply. The client
> is also responsible for managing its own leases and renewing them
> before they  time out.
> 
>> resource it has "leased". Right now we don't have a full solution 
>> for this.
> 
>> DHCPv6 and RS/RA are basically ships in the night and it's not 
>> clear how messages sent using one protocol, would affect the
>> other. A minimum would be some kind of coupling between a DHCPv6
>> relay router and what it puts in the RA and how this affects the
>> DHCPv6 information.
>> 
> In DHCPv6, the PD activity is client-directed. In the RS/RA based 
> schemes, the PD activity is network-directed. That is a marked 
> difference and needs to be examined according to the use cases.

In some use-cases on cellular network it may be preferable to use
DHCPv6-PD to delegate prefixes, instead of PIO-X.  An INFORMATIONAL
RFC6653 "PD on LTE" Figure 3 "Stateful Addr Conf Following PD"
illustrates such use-case.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 Aug 2017 10:57:21 +0200

Le 29/08/2017 à 21:39, Mikael Abrahamsson a écrit :
>> means for delegating IPv6 prefixes to nodes using RS/RA instead of 
>> DHCPv6 PD. But, there really isn't any L3 protocol defined for 
>> clients to control their prefix delegations using RS/RA whereas 
>> So, for clients to control and manage their prefix delegations it 
>> seems like DHCPv6 gives the clients the most flexibility and 
> for this. DHCPv6 and RS/RA are basically ships in the night

What is 'ships in the night'?

> and it's not clear how messages sent using one protocol, would
> affect the other.

It may be that there is little relationship between these protocols.  An
Access Router may put two very distinct prefixes (down to only 3 common
leftmost bits) in an RA and in the PD Advertise, provided these two
prefixes are routed correctly.

> A minimum would be some kind of coupling between a DHCPv6 relay
> router and what it puts in the RA and how this affects the DHCPv6
> information.

Some coordination may be advantageous, but it could also work without.

What would be the advantage?

Alex

---

From: Simon Hobson <[email-masked]>
Date: Wed, 30 Aug 2017 10:34:14 +0100

> What is 'ships in the night'?

https://en.wiktionary.org/wiki/ships_that_pass_in_the_night

Etymology
From a poetic metaphor by Henry Wadsworth Longfellow (1807-1882):
Ships that pass in the night, and speak each other in passing,
Only a signal shown and a distant voice in the darkness;
So on the ocean of life we pass and speak one another,
Only a look and a voice, then darkness again and a silence.

Noun
...
• (idiomatic, by extension) Things which have no significant connection or commonality.

It's a saying that's probably only familiar to english speaking and/or seafaring nationalities. Basically it refers to two strangers who meet briefly by chance, but never again. A bit like, two ships might pass in the night, and at best exchange a few signals of greeting (which would have been light signals when the phrase first came into use), before they disappear in their different directions.

In this case, I think what Mikael Abrahamsson is suggesting that these are different, unconnected processes/protocols with no common connection other than that the packets share the same wire.

---

From: Erik Nygren <[email-masked]>
Date: Wed, 30 Aug 2017 09:50:06 -0400

A specific use-case I'd love to see a better solution for is data center
scenario where individual nodes want to request a specific prefix for
providing a service from, especially if those nodes are collaborating and
want to be able to hand off the prefix between eachother as part of an HA
setup.  Examples might include a pair of active/standby NAT64 servers, a
web server that needs huge numbers of IPs, or a VM hosting server for a
test environment that has a huge number of IPs within a given prefix.

Currently BGP with a next hop service address seems to the best and most
universal way to configure this, but it brings another protocol family into
the mix.

In these cases the nodes generally have configured prefixes they are
requesting, often configured through an out-of-band config management or
orchestration system.

- Erik

On Aug 30, 2017 1:07 AM, "Mikael Abrahamsson" <[email-masked]> wrote:

>> network-directed and 2) client-directed. Which is more appropriate probably
>> needs to be examined on a case-by-case basis.
>>
>
> want this anymore, permanently" but also "I am disconnecting for a while, I
> am still interested in this resource" and also perhaps "hello, I am now
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 Aug 2017 21:28:21 +0000

Hi Mikael,

> Sent: Tuesday, August 29, 2017 10:08 PM
> Cc: Brian E Carpenter <[email-masked]>; [email-masked]
> Subject: RE: [v6ops] Prefix Delegation RS/RA vs DHCPv6
> 

Right, and that is what DHCPv6 PD already does. IPv6 ND could probably
be made to do it too, but there would need to be a new protocol and
possibly also new message types (in addition to what is already in PIO-X).

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Thu, 31 Aug 2017 09:20:52 +1000

On 31 Aug. 2017 07:28, "Templin, Fred L" <[email-masked]> wrote:

Hi Mikael,

I might not be understanding, however that sounds to me like a preferred or
valid lifetime update.

Thanks - Fred

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 31 Aug 2017 06:44:53 +0200 (CEST)

> Right, and that is what DHCPv6 PD already does. IPv6 ND could probably

I don't believe it does. It can do release, but that is no guarantee that 
it'll get the resource back in the future. There is no intention included 
in the "release". If it doesn't release and then tries to renew it 
somewhere else, afaik there is no standard way for this to work either 
because that PD lease is typically tied to an interface and a DHCPv6 proxy 
is typically sitting there with a binding.

Also, I have never seen DHCPv6 do "this resource is no longer available, 
stop using it in the next 60 seconds". You can shorten lifetimes when the 
client asks, but I have never seen the network reach out to the client to 
shorten the lifetime.

>From what I can tell we have no solution for what we're talking here, we 
need to extend what we have to do what we're talking about.

---

From: Clark Gaylord <[email-masked]>
Date: Thu, 31 Aug 2017 05:54:03 -0400

On Aug 29, 2017 3:39 PM, "Mikael Abrahamsson" <[email-masked]> wrote:

Granted DHCP is polled, but more to the point it is an explicit assignment
responding to the poll:
"I'd like an address"
"Ok here's your address"
"Thanks, bud"

With RS/RA it's more:
"So how does one do addressing around here?"
"If you do it like this, then I might talk to you. By the way, you don't
need to ask, I'm going to occasionally remind you anyway. And I might
change my mind."

So for PD, the DHCP implementation is straightforward:
"While your at it, I'd like a prefix I can use to give addresses to my
friends. Someday I hope to be a real boy."
"Here's a prefix you can use for your friends. But you'll always be a
little wooden puppet."

So what's the analog for a RS/RA PD implementation:
"How does one do addressing around here? Btw, I might have friends that ask
me the same question, if you'd care to give me that spec too."
"Here's how we do things around here. If you have friends I don't otherwise
know about, assign them addresses like this. Make sure you let me know when
you do, if you expect me to send packets to you on behalf of your friends.
These rules might change, so make sure your friends are aware of that too."

It's certainly doable, and the protocol gap exists. The question is if you
like RS/RA, are you likely to want to support PD?

Right now we don't have a full solution for this. DHCPv6 and RS/RA are
basically ships in the night and it's not clear how messages sent using one
protocol, would affect the

They can be ships in the night, but I think most environments choose which
approach makes sense for them. They can coexist, but I don't think you want
to couple them.

other. A minimum would be some kind of coupling between a DHCPv6 relay
router and what it puts in the RA and how this affects the DHCPv6
information.

That's an interesting idea, regardless of PD implications, but PD makes it
more clear. If the relay agent (typically the router) expects certain
config policies, he can confirm the offered DHCP config is consistent with
the policy.
"DHCP is offering addresses like X and I'm using Y."
Then the policy can choose:
"But I'm not going to say anything" or
"I'm telling mom!" or
"I'm not forwarding this bogus offer"

The network is the one true source of its own configuration.... :-)

--
Clark Gaylord
[email-masked]
... Autocorrect may have improved this message
    Brevity should not be interpreted as curtness ...

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 31 Aug 2017 13:33:09 +0200 (CEST)

On Thu, 31 Aug 2017, Clark Gaylord wrote:

> They can be ships in the night, but I think most environments choose 
> which approach makes sense for them. They can coexist, but I don't think 
> you want to couple them.

I have this problem right now. I have a largish router that does DHCPv6 PD 
proxy (amongst other things). For some reason the proxy loses state, so 
the PD binding isn't there, so no more PD route towards the HGW (home 
gateway). After refresh timer HGW asks "hey, can I please renew these?" 
the response is "nobinding" (ie "I have no idea what you're talking 
about").

The HGW then happily just says "ok then" and keeps the lease (because the 
lease is still valid), and thinks everything is fine and dandy (it's not).

I can't make this router say anything in RA or ND that makes the HGW 
restart its DHCPv6 PD process (do discovery again). The only way I know is 
to physically flap the port towards the HGW. We have no signal to say 
"look, everything has changed around here, please re-confirm your 
resources, if you can't confirm them within X seconds, drop them and try 
to get new ones".

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Aug 2017 13:54:55 +0200

Mikael,

>> They can be ships in the night, but I think most environments choose which approach makes sense for them. They can coexist, but I don't think you want to couple them.
> 
> I have this problem right now. I have a largish router that does DHCPv6 PD proxy (amongst other things). For some reason the proxy loses state, so the PD binding isn't there, so no more PD route towards the HGW (home gateway). After refresh timer HGW asks "hey, can I please renew these?" the response is "nobinding" (ie "I have no idea what you're talking about").

Let me quote this relevant paragraph from 1958:

  This principle has important consequences if we require applications
   to survive partial network failures. An end-to-end protocol design
   should not rely on the maintenance of state (i.e. information about
   the state of the end-to-end communication) inside the network. Such
   state should be maintained only in the endpoints, in such a way that
   the state can only be destroyed when the endpoint itself breaks
   (known as fate-sharing). An immediate consequence of this is that
   datagrams are better than classical virtual circuits.  The network's
   job is to transmit datagrams as efficiently and flexibly as possible.

In this case when you have a snooping DHCPv6 PD relay, there are no protocol mechanics there to save you.
The obvious answer is that you shouldn't do this. Snooping and gathering state by "listening" in to other protocol entities communicating is a bad idea.

Now what should you do instead?
Well Markus and I wrote about this in:
https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00

We also wrote on this topic back in 2006:
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-05

Which Ralph resubmitted a few months ago. With a somewhat unfortunate date. ;-)

If I were to recommend something, I would require the requesting router (HGW in your parlance) to be responsible for maintaining the state in intermediate devices. The mechanism I'd like to use for that is something akin to BFD echo mode. The RR sends a packet (e.g. ICMP echo) destined to _itself_ using a destination address from the delegated prefix via its first-hop router. If packet is received the RR is guaranteed that the fist hop router has forwarding state. If packet is not received, that should trigger the RR to revalidate the prefix with a DHCP VERIFY or RENEW message.

> 
> The HGW then happily just says "ok then" and keeps the lease (because the lease is still valid), and thinks everything is fine and dandy (it's not).
> 
> I can't make this router say anything in RA or ND that makes the HGW restart its DHCPv6 PD process (do discovery again). The only way I know is to physically flap the port towards the HGW. We have no signal to say "look, everything has changed around here, please re-confirm your resources, if you can't confirm them within X seconds, drop them and try to get new ones".

Best regards,
Ole

---

From: Simon Hobson <[email-masked]>
Date: Thu, 31 Aug 2017 12:57:20 +0100

> I can't make this router say anything in RA or ND that makes the HGW restart its DHCPv6 PD process (do discovery again). The only way I know is to physically flap the port towards the HGW. We have…

But I don't think that's relevant here. Your issue is "I have this piece of kit that doesn't work properly, it's a problem that I can't tell this other bit of kit to do something 'out of spec' to work around the fault in the faulty kit".

---

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

On Thu, 31 Aug 2017, Simon Hobson wrote:

> But I don't think that's relevant here. Your issue is "I have this piece 
> of kit that doesn't work properly, it's a problem that I can't tell this 
> other bit of kit to do something 'out of spec' to work around the fault 
> in the faulty kit".

What part is faulty? The PD proxy in the router? Yes, you might say so.

---

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

> In this case when you have a snooping DHCPv6 PD relay, there are no protocol mechanics there to save you.

Well, the well-known vendor calls it a "proxy". It's kind of a relay. But 
not. And the code-base seems intertwined with the vendor DHCPv6 server 
implementation that is also available on the router, because sometimes the 
proxy does funky things that a relay/proxy should never do.

> The obvious answer is that you shouldn't do this. Snooping and gathering state by "listening" in to other protocol entities communicating is a bad idea.

I agree. But, this seems to be the way things are typically done in DHCPv6 
land.

> https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00

Seems to capture a lot of the problems, yes.

> Which Ralph resubmitted a few months ago. With a somewhat unfortunate date. ;-)

Right.

> If I were to recommend something, I would require the requesting router 
> (HGW in your parlance) to be responsible for maintaining the state in 
> intermediate devices. The mechanism I'd like to use for that is 
> something akin to BFD echo mode. The RR sends a packet (e.g. ICMP echo) 
> destined to _itself_ using a destination address from the delegated 
> prefix via its first-hop router. If packet is received the RR is 
> guaranteed that the fist hop router has forwarding state. If packet is 
> not received, that should trigger the RR to revalidate the prefix with a 
> DHCP VERIFY or RENEW message.

Makes sense. Not that I am a network application programmer, but it looks 
like this will require raw sockets to accomplish. I'll look into it.

---

From: Richard Patterson <[email-masked]>
Date: Thu, 31 Aug 2017 13:28:27 +0100

>> What part is faulty? The PD proxy in the router? Yes, you might say so.

Your HGW/client.

When the HGW receives the Reply with a "nobinding" in the IA, it should
trigger a Request instead of failing silently.
If the server can't honour that Request it should send back a Reply with
NoAddrAvail. Your HGW/client can then send a new Solicit or Request for a
different IA.

 When the client receives a Reply message in response to a Renew or
   Rebind message, the client examines each IA independently.  For each
   IA in the original Renew or Rebind message, the client:

   -  sends a Request message if the IA contained a Status Code option
      with the NoBinding status (and does not send any additional
      Renew/Rebind messages)

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Aug 2017 14:38:21 +0200

Le 31/08/2017 à 14:28, Mikael Abrahamsson a écrit :
> Well, the well-known vendor calls it a "proxy". It's kind of a relay. 
> But not. And the code-base seems intertwined with the vendor DHCPv6 
> server implementation that is also available on the router, because 
> sometimes the proxy does funky things that a relay/proxy should never do.
> 
>> The obvious answer is that you shouldn't do this. Snooping and 
>> gathering state by "listening" in to other protocol entities 
>> communicating is a bad idea.
> 
> I agree. But, this seems to be the way things are typically done in 
> DHCPv6 land.

Also in RA land there are modems that implement strange RA matters: 
receive an RA on one side, create another one, and send it on another side.

Alex

>> If I were to recommend something, I would require the requesting 
>> router (HGW in your parlance) to be responsible for maintaining the 
>> state in intermediate devices. The mechanism I'd like to use for that 
>> is something akin to BFD echo mode. The RR sends a packet (e.g. ICMP 
>> echo) destined to _itself_ using a destination address from the 
>> delegated prefix via its first-hop router. If packet is received the 
>> RR is guaranteed that the fist hop router has forwarding state. If 
>> packet is not received, that should trigger the RR to revalidate the 
>> prefix with a DHCP VERIFY or RENEW message.
> 
> Makes sense. Not that I am a network application programmer, but it 
> looks like this will require raw sockets to accomplish. I'll look into it.
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Aug 2017 15:09:20 +0200

> Makes sense. Not that I am a network application programmer, but it looks like this will require raw sockets to accomplish. I'll look into it.

Right, the BSD socket API is probably not very accommodating for this.
On an Ethernet link you need to send a packet with IP source and destination address equal to your own address from the delegated prefix. The L2 MAC destination address must be set to the first-hop router's.

This mechanism has been described here and there... at least alluded to. I don't know if it is worthwhile documenting in a draft in excruciating detail?

Ole

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 31 Aug 2017 13:18:57 +0000

> From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Wednesday, August 30, 2017 5:28 PM
> To: Mikael Abrahamsson
> Cc: [email-masked]
[[Dusan]] 
Not quite. I started a discussion to add an error code that a client can set when:

>> Client
I did not get any understanding at DHCP WG. In the WG it is acceptable for DHCP server to 
return errors or assign anything but not for a client to release an address and provide a reason for it.

[[Dusan]] 
[[Dusan]] 

> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=4cONz
> cmAxGAmTRE7Zhn7hGNUFUvBYVjhsPsr897x0tc&s=1K9LZQTTTF0jL4BVPvKt7I1
> _ZdEQ911Jxz7QVNNEI3I&e=

---

From: Lee Howard <[email-masked]>
Date: Thu, 31 Aug 2017 09:57:23 -0400

No hat. . .

>using it within X seconds"

Why should we be encouraging staticness on the netwrk?
Shouldn’t we be making it easier to renumber, rather than making the
network less dynamic?

Lee

---

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

On Thu, 31 Aug 2017, Lee Howard wrote:

> Why should we be encouraging staticness on the netwrk? Shouldn’t we be 
> making it easier to renumber, rather than making the network less 
> dynamic?

Sounds like a great idea. How?

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Aug 2017 15:31:16 +0000

Hi Mikael,

> Sent: Wednesday, August 30, 2017 9:45 PM

DHCPv6 servers can maintain a list of (client, prefix) associations so that
the client can get the same prefix every time it asks. I do this in my DHCPv6
server configurations today. The client can even provide the server with a
"hint" as to the prefix it wants to receive so that it can get the same one
every time.

> client asks, but I have never seen the network reach out to the client to

That can be done with DHCPv6 Reconfigure. Server sends Reconfigure,
client responds by sending Renew, and server responds by sending a
Reply (the sixth "R") with a shortened prefix lifetime.

> need to extend what we have to do what we're talking about.

I think it can be done with RFC3315/RFC3633 compliant DHCPv6.

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 31 Aug 2017 18:29:41 +0200 (CEST)

On Thu, 31 Aug 2017, Templin, Fred L wrote:

> client responds by sending Renew, and server responds by sending a Reply 
> (the sixth "R") with a shortened prefix lifetime.

What DHCPv6 servers support reconfigure today? How is this reconfigure 
supposed to be triggered by the DR (because it's probably the one that 
knows that something happened)?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 31 Aug 2017 17:03:44 +0000

> What DHCPv6 servers support reconfigure today?

Cisco Prime Network Registrar does.

You can reconfigure individual clients; we don't have a function to reconfigure all the clients on a particular network segment, but it isn't difficult to do this -- you can request the leases active on a network segment, and issue reconfiguration operations to each of those clients.

Of course, this requires the clients to support Reconfigure -- and most of the DOCSIS devices do.

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Thursday, August 31, 2017 12:30 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6

> Reply (the sixth "R") with a shortened prefix lifetime.

What DHCPv6 servers support reconfigure today? How is this reconfigure supposed to be triggered by the DR (because it's probably the one that knows that something happened)?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 31 Aug 2017 17:12:33 +0000

BTW: I should add that we can send Reconfigure to devices that may only have done PD (and thus do not have a leased address). We can send the Reconfigure via the relay chain (Relay-Reply) that the client last used to communicate with the server. This is also useful in cases where the DHCPv6 server is unable to communicate directly with the client (though that is less typical in v6 network than in V4, hopefully).

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, August 31, 2017 1:04 PM
To: Mikael Abrahamsson <[email-masked]>; Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6

- Bernie

---

From: Lee Howard <[email-masked]>
Date: Thu, 31 Aug 2017 14:20:39 -0400

>Sounds like a great idea. How?

Well, I note that the anima WG has this in their charter:
A simple example is
assigning address prefixes to network segments in a large and constantly
changing network.

https://datatracker.ietf.org/wg/anima/about/

Lee