dhcpcd-discuss

On Fri, 17 Jan 2014 11:50:02 +0000
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> 
> In DHCPv6, VendorClass ID does exist, but it requires an IANA assigned 
> enterprise number and thus has a different option.
> 
...
> 
> What could do with some improving is indicating in the man page which 
> are DHCPv4 only and DHCPv6 only options as that is non clear and the doc 
> assumes you know a little of either spec.
> 

Yeah, guess I should've looked up the specs too, but given that these
vendor-things look very similar in packets, didn't get a clue that they
might correspond to diff options.

Just stating which of these vendor-things is 4 and/or 6 would definitely
have eliminated the issue for me.


> 
> waitip 46
> is equivalent to
> waitip 4
> waitip 6
> 
> I have deliberately not documented that behavior though because one day 
> protocol 46 or 64 might exist!
> I have no idea if DHCP would still be relevant then though ....
> 

Wouldn't it be easy to just ignore old and never-to-be-used again "4"
then though (maybe with a warning) without any real downside?

Also, I assumed comma as a separator due to its usage in other options,
which makes lack of details here especially confusing.
Maybe just change from "waitip [4 | 6]" to "waitip [4 | 6 | 46]" would
do it without any extra hints (if you think it should be documented at
all, of course)?


> 
> This configuration is invalid. dhcpcd.conf(5) needs to explicitly state 
> that ia_pd should fall inside an interface scope option
> AND not to assign the delegated prefix to itself.
> 

Oh, ok, that makes sense.

Though I'm using dhcpcd for a single interface specified on a
commandline along with a separate config (just for that interface), so
it looks a bit redundant to mention it in the config again.

But I see that it might be a bit of an oddball case, though limiting
dhcp client explicitly to where (of 9 interfaces on that machine) it
needs to be seem like a sane thing, especially since just running
dhcpcd without specifying one interface explicitly iirc just kills all
network instantly and kinda-irreversibly (paaaaain!) ;)

Maybe also state that on a separate line in dhcpcd.conf(5), because
word "interface" is used in description of that option like 5 times,
and (at least I assume) means different thing in each of them (ia_pd
argument), so separating from that context might be useful.


> > Since ia_na and ia_pd can't seem to be used together (resulting in
> > "dhcpcd[4030]:  cannot specify a different IA type" error), is there
> > any other way to pass ia_pd parameters from DHCPv6 to hook script on
> > address assignment?
> 
> So basically dhcpcd is designed to work with either PD or NA/TA.
> I don't see a good reason for allowing PD and NA/TA on the same 
> interface.
> 

ISP here actually didn't seem to allow using IA_PD without IA_NA until
the first of last october and implemented that due to complaints from
Mikrotik router owners, which seemed to do just that.

I'd link an official support thread via google translate, but
apparently it's not accessible from the outside and translate fails.

What they literally say there is "Ok, so we will implement changes
that will allow users to use the delegated prefix (IA_PD) with Mikrotik
even without an address request (IA_NA) for WAN-interface".

Guess it would've been impossible to use with dhcpcd before that date,
but of course maybe it's just an ISP bug not worth adapting to.

Given that IA_NA seem to hand out an IP from delegated range anyway, I
don't see much point in using it with IA_PD here either, at least now.


> > 
> > There seem to be ROUTERADVERT events a bit later, but they come a bit
> > too late, and clearly dhcpcd has that address/range way before them.
> > 
> > Also, dhcpcd output shows two "delegated prefix" lines, for some 
> > reason:
> > 
> >   dhcpcd[5044]: ext1: delegated prefix 2a02:17d0:3b0:a500::/56
> >   dhcpcd[5044]: ext1: delegated prefix 
> > 2a02:17d0:3b0:a500:1ebd:b9ff:fe86:f439/56
> >   dhcpcd[5044]: ext1: adding address 
> > 2a02:17d0:3b0:a500:1ebd:b9ff:fe86:f439/56
> > 
> > But looking at actual traffic, I can't seem to find that second prefix
> > anywhere, and it clearly corresponds to MAC, so I assume generated by
> > dhcpcd and not a bug?
> 
> A lack of scope :)
> 
> Let me draw you a picture
> 
> ext1 == connected to ISP
> int1 == internal LAN
> 
> Your config, based on above should look like so:
> 
...
> 
> So the last block says "the below config is for ext1 only. We will use 
> an IAID of b9:86:fe:39 to request a PD and then assign the result to 
> interface int1 with a /56 prefix length"
> 

That certanly clears up the confusion here, thanks.

Will try fixing it now, should probably work for my case, but I still
wonder - shouldn't there be a hook when this delegation happens anyway?

Currently I have different (from 4to6 days) IPv6 addresses in the LAN,
and would actually prefer to keep them for now, because they are static
and used now in IPSec, internal DNS and a lot of other configs.

So to reconcile some routing issues between the two IPv6 ranges used
(with IA_NA I've been able to do it via static "ip rule"), I'd think it
might be helpful to have some configurable action when new IPv6 range
gets added.

Not sure if I just didn't get that hook due to that misconfiguration
though, so pls nevermind if that should be the case.


Thanks a lot for your help.


-- 
Mike Kazantsev // fraggod.net

Attachment: signature.asc
Description: PGP signature