DHCPv4 V-I Vendor Class with multiple ENs overwrites the EN values

[rmarioe]

Hi,

I see when defining the vendclass two times with different EN, the first one is overwritten and the second one is actually part of the data.
In the manual I see:

[vendclass] en data
Add the DHCPv6 Vendor Indetifying Vendor Class with the IANA assigned Enterprise Number en with the data. This option can be set more than once to add more data, but the behaviour, as per RFC 3925 is undefined if the Enterprise Number differs.

However the RFC states:

This option contains information corresponding to one or more
Enterprise Numbers. Multiple instances of this option may be present
and MUST be concatenated in accordance with [RFC 3396]. An
Enterprise Number SHOULD only occur once among all instances of this
option. Behavior is undefined if an Enterprise Number occurs
multiple times. The information for each Enterprise Number is
treated independently, regardless or whether it occurs in an option
with other Enterprise Numbers or in a separate option.

Does this not mean that having multiple enterprise numbers that differ should be supported but repeating an already seen enterprise number is undefined?

[rsmarples]

This isn't very well done I have to confess I probably haven't implemented this very well.
Currently you cannot specify different EN values, only the first one is used.

[rmario1]

One more thing is the formatting as per https://mailarchive.ietf.org/arch/msg/dhcwg/B4fNsvUR0EHxcrKDsKCf7lBrc3s/ where each instance the vendor-class-data needs to have a length. Since the packet sent does not include it (but includes the total length) the packets are seen as malformed.
Should we track this as two issues even though one commit could fix both of them?

[rsmarples]

One commit can fix two issues, sure.

[rsmarples]

This will be fixed in #383 with a new option.