Subject: [dhcwg] Informational IPv6 prefix option for DHCPv6

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Jul 2014 17:54:41 +0000

Hi,

I am looking for a DHCPv6 option that a server can use to report an IPv6
prefix to a client. This *would not* be used as a replacement for Router
Advertisement Prefix Information Options (PIOs), and the client *would
not* use the prefix for SLAAC.

A DHCPv6 option that specifically returned an IPv6 prefix (along with
prefix length) would be preferred. A DHCPv6 option that returned opaque
data could also be used as a kludge but I would rather not have to do
that. Is there a DHCPv6 option that would meet these requirements?

Thanks - Fred
[email-masked]

---

From: Andre Kostur <[email-masked]>
Date: Mon, 7 Jul 2014 11:22:46 -0700

Isn't that Prefix Delegation? RFC 3633.  Nutshell is that the client
can specifically ask the server for a prefix.  Part of the plan is for
routers deployed out at the edge, and they can ask the DHCP server for
a prefix that the router will then manage on its further downstream
links.

On Mon, Jul 7, 2014 at 10:54 AM, Templin, Fred L
<[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Andre Kostur
Distinguished Software Architect & Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

F: 604-678-2864
VoIP: sip:[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Jul 2014 18:52:21 +0000

Hi Andre,

No, this is not Prefix Delegation. For PD, the DHCPv6 server
returns an IPv6 prefix that the client then uses to number its
downstream-attached links. What I want is an informational
option that pertains to the link over which the client contacts
the server, and to my understanding PD cannot be used for that.

Thanks - Fred

> -----Original Message-----
> From: Andre Kostur [mailto:[email-masked]]
> Sent: Monday, July 07, 2014 11:23 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6
>

---

From: Andre Kostur <[email-masked]>
Date: Mon, 7 Jul 2014 12:27:28 -0700

Then I'm not sure of the purpose of this information.  The client got
an IPv6 address from somewhere, so it should be able to know its
prefix from that.  What's the client supposed to do with this
information that it's getting from DHCP?

-- 
Andre Kostur

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Jul 2014 19:44:18 +0000

Hi Andre,

> Sent: Monday, July 07, 2014 12:27 PM
> To: Templin, Fred L
> Cc: [email-masked]

It is for a link type on which there is no non-link-local IPv6 prefix
assigned. The link connects a bunch of routers that only configure a
link-local address on the link. The routers also act as DHCPv6 clients,
and act as requesting routers using DHCPv6 PD to get a prefix to assign
to their downstream attached links.

The IPv6 prefix I want to include in the DHCPv6 option I am asking for
is the aggregated prefix from which client prefixes are delegated. So,
if the aggregated prefix is 2001:db8::/32, then the clients would be
delegated longer prefixes such as 2001:db8:4000::/48, 2001:db8:1::/56,
2001:db8:21:31::/64, etc.

So, the aggregated prefix is not assigned *to* the link, but rather
tells the set of prefixes that can be reached *through* the link.
This is important information that I want to provide to the clients
via a DHCPv6 option.

Thanks - Fred

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Jul 2014 19:57:27 +0000

There was a draft to do something like this. But I think it died. See http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, July 07, 2014 3:44 PM
To: Andre Kostur
Cc: [email-masked]
Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6

Hi Andre,

> information that it's getting from DHCP?

It is for a link type on which there is no non-link-local IPv6 prefix assigned. The link connects a bunch of routers that only configure a link-local address on the link. The routers also act as DHCPv6 clients, and act as requesting routers using DHCPv6 PD to get a prefix to assign to their downstream attached links.

The IPv6 prefix I want to include in the DHCPv6 option I am asking for is the aggregated prefix from which client prefixes are delegated. So, if the aggregated prefix is 2001:db8::/32, then the clients would be delegated longer prefixes such as 2001:db8:4000::/48, 2001:db8:1::/56, 2001:db8:21:31::/64, etc.

So, the aggregated prefix is not assigned *to* the link, but rather tells the set of prefixes that can be reached *through* the link.
This is important information that I want to provide to the clients via a DHCPv6 option.

Thanks - Fred

> > No, this is not Prefix Delegation. For PD, the DHCPv6 server returns 
> > an IPv6 prefix that the client then uses to number its 
> > downstream-attached links. What I want is an informational option 
> > that pertains to the link over which the client contacts the server, 
> > and to my understanding PD cannot be used for that.
> >
> > Thanks - Fred
> >> Isn't that Prefix Delegation? RFC 3633.  Nutshell is that the 
> >> client can specifically ask the server for a prefix.  Part of the 
> >> plan is for routers deployed out at the edge, and they can ask the 
> >> DHCP server for a prefix that the router will then manage on its 
> >> further downstream links.
> >>
> >> > I am looking for a DHCPv6 option that a server can use to report 
> >> > an IPv6 prefix to a client. This *would not* be used as a 
> >> > replacement for Router Advertisement Prefix Information Options 
> >> > (PIOs), and the client *would
> >> > A DHCPv6 option that specifically returned an IPv6 prefix (along 
> >> > with prefix length) would be preferred. A DHCPv6 option that 
> >> > returned opaque data could also be used as a kludge but I would 
> >> > rather not have to do that. Is there a DHCPv6 option that would meet these requirements?
> >> >
> >> > Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Jul 2014 20:09:57 +0000

Hi Bernie,

Thanks. At first glance, this looks like it is too tightly wrapped
around DHCPv6 PD for what I am after. I want something very simple
that is somehow related to PD but at the same time independent of PD.

So again, to my link model, I have a link on which there are one
or more delegating routers and lots and lots of requesting routers.
To get the information I am looking for, I could set the delegating
routers to include the aggregated prefix in RA PIOs with the 'A' and
'L' bits set to 0. But, that means that I would need to set up some
manual configuration on each of the delegating routers and I really
don't want to have to do that.

Much better would be to have the DHCPv6 server include the aggregated
prefix in a simple informative DHCPv6 option as a single administrative
touch point. The delegating routers are then simpler and less prone to
misconfigurations, and the requesting routers get the PD and aggregated
prefix information they need in a single DHCPv6 request.

I think a while back there was some discussion about including PIOs in
DHCPv6 messages. Did that hit some kind of roadblock? Because, I think
I now have an interesting use case for it.

Thanks - Fred

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Monday, July 07, 2014 12:57 PM
> To: Templin, Fred L; Andre Kostur
> Cc: [email-masked]
> Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6
> 
> There was a draft to do something like this. But I think it died. See
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt
> 
> - Bernie
> 
> It is for a link type on which there is no non-link-local IPv6 prefix assigned. The link connects a
> bunch of routers that only configure a link-local address on the link. The routers also act as DHCPv6
> clients, and act as requesting routers using DHCPv6 PD to get a prefix to assign to their downstream
> attached links.
> 
> The IPv6 prefix I want to include in the DHCPv6 option I am asking for is the aggregated prefix from
> which client prefixes are delegated. So, if the aggregated prefix is 2001:db8::/32, then the clients
> would be delegated longer prefixes such as 2001:db8:4000::/48, 2001:db8:1::/56, 2001:db8:21:31::/64,
> etc.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Jul 2014 20:15:17 +0000

See http://tools.ietf.org/html/draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00 as I this just got resurrected (there were several other documents in the past that attempted to do this or something close to it).

Nothing exists as an IETF standard for what you want. Whether you can use something that others are working on or not, I cannot say. I find these documents by googling :).

The options ones that presently exist are at: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml, and I don't think anything there works for what you want.

You could always use Vendor Options (option 17).

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, July 07, 2014 4:10 PM
To: Bernie Volz (volz); Andre Kostur
Cc: [email-masked]
Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6

Hi Bernie,

Thanks. At first glance, this looks like it is too tightly wrapped around DHCPv6 PD for what I am after. I want something very simple that is somehow related to PD but at the same time independent of PD.

So again, to my link model, I have a link on which there are one or more delegating routers and lots and lots of requesting routers.
To get the information I am looking for, I could set the delegating routers to include the aggregated prefix in RA PIOs with the 'A' and 'L' bits set to 0. But, that means that I would need to set up some manual configuration on each of the delegating routers and I really don't want to have to do that.

Much better would be to have the DHCPv6 server include the aggregated prefix in a simple informative DHCPv6 option as a single administrative touch point. The delegating routers are then simpler and less prone to misconfigurations, and the requesting routers get the PD and aggregated prefix information they need in a single DHCPv6 request.

I think a while back there was some discussion about including PIOs in
DHCPv6 messages. Did that hit some kind of roadblock? Because, I think I now have an interesting use case for it.

Thanks - Fred

> > Then I'm not sure of the purpose of this information.  The client 
> > got an IPv6 address from somewhere, so it should be able to know its 
> link-local address on the link. The routers also act as DHCPv6 
> clients, and act as requesting routers using DHCPv6 PD to get a prefix to assign to their downstream attached links.
> 
> delegated longer prefixes such as 2001:db8:4000::/48, 2001:db8:1::/56, 2001:db8:21:31::/64, etc.
> 
> > > that pertains to the link over which the client contacts the 
> > > server, and to my understanding PD cannot be used for that.
> > >
> > > Thanks - Fred
> > >> plan is for routers deployed out at the edge, and they can ask 
> > >> the DHCP server for a prefix that the router will then manage on 
> > >> its further downstream links.
> > >>
> > >> > I am looking for a DHCPv6 option that a server can use to 
> > >> > report an IPv6 prefix to a client. This *would not* be used as 
> > >> > a replacement for Router Advertisement Prefix Information 
> > >> > Options (PIOs), and the client *would
> > >> > A DHCPv6 option that specifically returned an IPv6 prefix 
> > >> > (along with prefix length) would be preferred. A DHCPv6 option 
> > >> > that returned opaque data could also be used as a kludge but I 
> > >> > would rather not have to do that. Is there a DHCPv6 option that would meet these requirements?
> > >> >
> > >> > Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Jul 2014 20:29:44 +0000

Hi Bernie,

> Sent: Monday, July 07, 2014 1:15 PM
> See http://tools.ietf.org/html/draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00 as I this just got
> resurrected (there were several other documents in the past that attempted to do this or something
> close to it).

Thanks; that too looks like overkill for what I need.
 
> Nothing exists as an IETF standard for what you want. Whether you can use something that others are
> working on or not, I cannot say. I find these documents by googling :).

I will try to do a better job of googling.

> The options ones that presently exist are at: http://www.iana.org/assignments/dhcpv6-
> parameters/dhcpv6-parameters.xml, and I don't think anything there works for what you want.

Right, I took a look there and didn't see anything.

> You could always use Vendor Options (option 17).

OK, that would satisfy what I was meaning when I said:

  "A DHCPv6 option that returned opaque data could also be used as
   a kludge but I would rather not have to do that."

But, maybe it wouldn't be so bad, plus (correct me if I am wrong)
it has the distinct advantage that it is already implemented in
widely-deployed DHCPv6 implementations, right?

Thanks again for the help,

Fred

> Thanks. At first glance, this looks like it is too tightly wrapped around DHCPv6 PD for what I am
> after. I want something very simple that is somehow related to PD but at the same time independent of
> PD.
> 
> To get the information I am looking for, I could set the delegating routers to include the aggregated
> prefix in RA PIOs with the 'A' and 'L' bits set to 0. But, that means that I would need to set up some
> manual configuration on each of the delegating routers and I really don't want to have to do that.
> 
> Much better would be to have the DHCPv6 server include the aggregated prefix in a simple informative
> DHCPv6 option as a single administrative touch point. The delegating routers are then simpler and less
> prone to misconfigurations, and the requesting routers get the PD and aggregated prefix information
> they need in a single DHCPv6 request.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Jul 2014 20:52:27 +0000

>But, maybe it wouldn't be so bad, plus (correct me if I am wrong) it has the distinct advantage that it is already implemented in widely-deployed DHCPv6 implementations, right?

I would expect that this is widely implemented.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, July 07, 2014 4:30 PM
To: Bernie Volz (volz); Andre Kostur
Cc: [email-masked]
Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6

Hi Bernie,

> See 
> http://tools.ietf.org/html/draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00 
> as I this just got resurrected (there were several other documents in the past that attempted to do this or something close to it).

> Nothing exists as an IETF standard for what you want. Whether you can 
> use something that others are working on or not, I cannot say. I find these documents by googling :).

But, maybe it wouldn't be so bad, plus (correct me if I am wrong) it has the distinct advantage that it is already implemented in widely-deployed DHCPv6 implementations, right?

Fred

> So again, to my link model, I have a link on which there are one or 
> more delegating routers and lots and lots of requesting routers.
> 'L' bits set to 0. But, that means that I would need to set up some manual configuration on each of the delegating routers and I really don't want to have to do that.
> 
> prefix in a simple informative
> DHCPv6 option as a single administrative touch point. The delegating 
> routers are then simpler and less prone to misconfigurations, and the 
> requesting routers get the PD and aggregated prefix information they need in a single DHCPv6 request.
> 
> > There was a draft to do something like this. But I think it died. 
> > See http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt
> >
> > - Bernie
> >
> > > got an IPv6 address from somewhere, so it should be able to know 
> > > its prefix from that.  What's the client supposed to do with this 
> > It is for a link type on which there is no non-link-local IPv6 
> > prefix assigned. The link connects a bunch of routers that only 
> > configure a link-local address on the link. The routers also act as 
> > DHCPv6 clients, and act as requesting routers using DHCPv6 PD to get 
> > a prefix to assign to their downstream
> attached links.
> >
> > The IPv6 prefix I want to include in the DHCPv6 option I am asking 
> > for is the aggregated prefix from which client prefixes are 
> > delegated. So, if the aggregated prefix is 2001:db8::/32, then the 
> > clients would be delegated longer prefixes such as 2001:db8:4000::/48, 2001:db8:1::/56, 2001:db8:21:31::/64, etc.
> >
> > > >> client can specifically ask the server for a prefix.  Part of 
> > > >> the plan is for routers deployed out at the edge, and they can 
> > > >> ask the DHCP server for a prefix that the router will then 
> > > >> manage on its further downstream links.
> > > >>
> > > >> > report an IPv6 prefix to a client. This *would not* be used 
> > > >> > as a replacement for Router Advertisement Prefix Information 
> > > >> > (along with prefix length) would be preferred. A DHCPv6 
> > > >> > option that returned opaque data could also be used as a 
> > > >> > kludge but I would rather not have to do that. Is there a 
> > > >> > DHCPv6 option that would meet these
> requirements?
> > > >> >
> > > >> > Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Jul 2014 21:02:25 +0000

> I would expect that this is widely implemented.

Meets my requirements, then. Many thanks.

Fred