Re: [dhcwg] Informational IPv6 prefix option for DHCPv6

["Bernie Volz (volz)" <[e-mail]>]

>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:[e-mail]] 
Sent: Monday, July 07, 2014 4:30 PM
To: Bernie Volz (volz); Andre Kostur
Cc: [e-mail]
Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6

Hi Bernie,

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[e-mail]]
> Sent: Monday, July 07, 2014 1:15 PM
> To: Templin, Fred L; Andre Kostur
> Cc: [e-mail]
> Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6
> 
> 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
[e-mail]

> - Bernie
> 
> -----Original Message-----
> From: Templin, Fred L [mailto:[e-mail]]
> Sent: Monday, July 07, 2014 4:10 PM
> To: Bernie Volz (volz); Andre Kostur
> Cc: [e-mail]
> 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
> [e-mail]
> 
> > -----Original Message-----
> > From: Bernie Volz (volz) [mailto:[e-mail]]
> > Sent: Monday, July 07, 2014 12:57 PM
> > To: Templin, Fred L; Andre Kostur
> > Cc: [e-mail]
> > 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
> >
> > -----Original Message-----
> > From: dhcwg [mailto:[e-mail]] On Behalf Of Templin, 
> > Fred L
> > Sent: Monday, July 07, 2014 3:44 PM
> > To: Andre Kostur
> > Cc: [e-mail]
> > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6
> >
> > Hi Andre,
> >
> > > -----Original Message-----
> > > From: Andre Kostur [mailto:[e-mail]]
> > > Sent: Monday, July 07, 2014 12:27 PM
> > > To: Templin, Fred L
> > > Cc: [e-mail]
> > > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6
> > >
> > > 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?
> >
> > 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
> > [e-mail]
> >
> > > On Mon, Jul 7, 2014 at 11:52 AM, Templin, Fred L 
> > > <[e-mail]> wrote:
> > > > 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
> > > > [e-mail]
> > > >
> > > >> -----Original Message-----
> > > >> From: Andre Kostur [mailto:[e-mail]]
> > > >> Sent: Monday, July 07, 2014 11:23 AM
> > > >> To: Templin, Fred L
> > > >> Cc: [e-mail]
> > > >> Subject: Re: [dhcwg] Informational IPv6 prefix option for 
> > > >> DHCPv6
> > > >>
> > > >> 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 
> > > >> <[e-mail]> wrote:
> > > >> > 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
> > > >> > [e-mail]
> > > >> >
> > > >> > _______________________________________________
> > > >> > dhcwg mailing list
> > > >> > [e-mail]
> > > >> > https://www.ietf.org/mailman/listinfo/dhcwg
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Andre Kostur
> > >
> > > --
> > > Andre Kostur
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg