dhcpcd-discuss

On 25/09/2018 17:39, Sébastien Luttringer wrote:
> On Mon, 2018-09-24 at 12:17 +0100, Roy Marples wrote:
> > Wow.
> Hi Roy,
>
> > This is an edge case I'm not entirely sure I want to work around.
>
> My goal is quite basic. I want choose an address in the IPv6 range that 
> my provider gives me.
> To give a little context, the provider in question gives a /56 per 
> server. To obtain the IP, according to its documentation[1], I have to 
> make a prefix request based on a given DUID.
>
> When I request an address, without a prefix (via ia_na), I only have one 
> IPv6 address (prefix + ::1). I cannot get others IP, I tried several 
> ia_na or to indicate an IP (via ia_na / address). Temporary prefix 
> didn't work either.
>
> So far, the cleanest option, seems to ask the prefix and to choose 
> myself the static address inside.

Why the need to choose the address inside the prefix?
What's exactly wrong with the address offered?

> > Firstly, you are delegating to the same interface you're requesting on
> > and dhcpcd correctly warns that your DHCPv6 server does not support this
> > (OPTION_PD_EXCLUDE is missing from it's reply).
> > If it did, then dhcpcd would assign an IPv6 address to the interface and
> > it would fork to the background correctly.
>
> Yes, the delegation is for the same interface I'm requesting on.
> Note there is one physical interface on the server, so there is no much 
> options.
>
> I don't get what's wrong with this, and why PD_EXCLUDE should be used here.
> If I understand correctly, the PD_EXCLUDE make sense when the delegating 
> router needs to use a sub prefix inside the delegated prefix (which is 
> forbidden by RFC 3633). In our case, the ipv6 prefix between the 
> delegating router (provider equipment) and the requesting router (my 
> server) is done via link-local addresses. So, the deletaged prefix is 
> not used by the delegating router, and so we don't need exclusion 
> (PD_EXCLUDE) extension.

RFC 3633 Section 12.1
https://tools.ietf.org/html/rfc3633#section-12.1

   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached, with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

RFC 6603 Section 3
https://tools.ietf.org/html/rfc6603#page-3

   DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit
   limitation described in Section 12.1 of [RFC3633] that a prefix
   delegated to a requesting router cannot be used by the delegating
   router.  This restriction implies that the delegating router will
   have two (non-aggregatable) routes towards a customer: one for the
   link between the requesting router and the delegating router, and one
   for the customer site behind the requesting router.

So we have two RFC's which disagree with your assertation.

RFC 6603 Section 1


   The prefix exclusion mechanism is targeted at deployments where
   DHCPv6-based prefix delegation is used, but a single aggregated
   route/prefix has to represent one customer, instead of using one
   prefix for the link between the delegating router and the requesting
   router and another prefix for the customer network.  The mechanism
   defined in this specification allows a delegating router to use a
   prefix out of the delegated prefix set on the link through which it
   exchanges DHCPv6 messages with the requesting router, and is intended
   for use in networks where each requesting router is on its own
   layer-2 domain.

This makes it very clear that PD_EXLCUDE is needed to work in your 
environment where there is only one interface.

> Side note, I made some test this afternoon with dhclient and it worked, 
> no PD_EXCLUDE warning and the prefix was correctly delegated.

So dhclient allows you to violate RFCs.
dhclient doesn't support PD_EXCLUDE last time I checked.

> > Secondly, if you ran dhcpcd in master mode (ie not specify an interface
> > on the command line or pass the -M flag) it would also fork to the
> > background correctly.
> Is dhcpcd, in this mode,will continue to renew/rebind the prefix? As it 
> didn't take the prefix as a valid address for going to background.

Yes, dhcpcd should continue to renew/rebind the prefix even if it cannot 
delegate it to any interface.

> [1]https://documentation.online.net/en/dedicated-server/network/ipv6/prefix

https://documentation.online.net/en/dedicated-server/network/ipv6/split-subnet

This talks about the /48 allocation where you can split of a /56 for as 
many servers

https://www.lowendtalk.com/discussion/comment/1486492/#Comment_1486492

So, this screenshot tells a story.
It seems like you would request a prefix delegation but not assign it to 
any interface.
This creates the entries in the network management console.
You then assign a /56 from that to each of your servers by some other means.

Does that sound like it might work for you?
I find it a little odd because prefix delegation is meant for *routers*, 
where as you want it on a single interface server.

Another workaround would be to create a tap style interface (you may 
have to bridge it to another tap interface to get a carrier up) and 
delegate your prefix to that interface.

Good luck!

Roy