Re: [dhcwg] Informational IPv6 prefix option for DHCPv6

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

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:[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