Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
IANA and IATA options may contain Status Code and IAAddr options.
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Added IAAddress, OneIAAddress, UserClasses, VendorOpts, and changed
Options to MessageOptions in IA_NA and IA_Address options.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Add message types, options, and modifier for handling DHCPv4-over-DHCPv6.
Refer to RFC 7341
Signed-off-by: Mikael Magnusson <mikma@users.sourceforge.net>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Status Code is one of the few options used across many Option types.
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Allow the Options type to have getters for each specific options, in
order to avoid users having to cast options to their specific type.
This commit introduces a getter for exactly one option: the
ClientArchType.
i.e. users can replace
archTypes := msg.GetOneOption(OptionClientArchType).(*OptClientArchType)
with
archTypes := msg.Options.ArchTypes()
Because a few message types and options embed options (normal message,
relay message, IANA/IATA option) and each have a restricted set of
options that can be used inside them, we'll introduce at least 3 or more
Options subtypes:
- MessageOptions
- RelayOptions
- IdentityOptions
Perhaps others will join at a later time, such as VendorOptions or
AddressOptions for the IAAddress options field.
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Set the IPv6 prefix field to zero if the prefix is invalid
or not initialized.
Signed-off-by: Mikael Magnusson <mikma@users.sourceforge.net>
|
|
This allows for multi-NIC DHCPv6 in parallel.
Otherwise:
2020/02/20 05:01:34 Could not configure eth1 for IPv6: listen udp6 %eth1:546: bind: address already in use
2020/02/20 05:01:34 Could not configure eth4 for IPv6: listen udp6 %eth4:546: bind: address already in use
2020/02/20 05:01:34 Attempting to get DHCPv6 lease on eth2
2020/02/20 05:01:34 Could not configure eth0 for IPv6: listen udp6 %eth0:546: bind: address already in use
2020/02/20 05:01:34 Could not configure eth3 for IPv6: listen udp6 %eth3:546: bind: address already in use
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
per https://tools.ietf.org/rfc/rfc4704.txt
Signed-off-by: Xuehao (David) Hu <xuehaohu@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Added support of option OptBootFileParam.
See RFC5970 section 3.2.
Signed-off-by: Dmitrii Okunev <xaionaro@fb.com>
|
|
Signed-off-by: Akshay Navale <navale@dhcp-172-27-23-219.dhcp.thefacebook.com>
|
|
IPv4 Residual Deployment (4RD) is a strategy for providing IPv4
connectivity in IPv6-only networks.
The standard includes autoconfiguration via DHCPv6, as described in
RFC7600. This adds support for the 3 options defined in that RFC
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
This updates the option codes list in dhcpv6/types.go to include all
published option codes as of today. For better formatting of the table,
replace comments indicating undefined options with assignments to the
throwaway variable `_`, which avoids resetting alignment formatting
compared to the comment option.
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
In both ARP and DHCPv6, the hwtype field is 16bits, and the IANA table
has allocated values >255.
(Bootp however uses 1byte so it can't represent everything)
This was discovered by fuzzing, as it causes round-trip mismatches; eg
with this packet (quoted string):
"0000\x00\x01\x00\x0e\x00\x01000000000000"
Input: 303030300001000e0001303030303030303030303030
Round-trip: 303030300001000e0001003030303030303030303030
^
The upper byte of the hwaddress is set
to 0
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
There were missing error checks in the Message and RelayMessage parsers,
so that truncated headers would be incorrectly accepted as valid
messages. For example the single byte "0" (0x30) would be accepted as a
valid message, then reserialized to 0x30,0x00,0x00,0x00,0x00
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
The uio library doesn't report errors on a per-operation basis, but
accumulates them so they can be checked after a batch of operations in a
separate Error() function. Unfortunately this makes it easy to forget,
thus parse incorrect messages
go-fuzz found immediately that an empty message would be parsed without
error, and reserialize to a different message (one with some bytes of
zeros)
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
This adds the required function for running
[go-fuzz](https://github.com/dvyukov/go-fuzz) on the dhcpv6 library.
It tests the following behaviour:
* Parsing messages doesn't crash
* Parsed messages are identical after being serialized and deserialized
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
The concrete type under the interface is known here since we create the
connection in the same function. Since *net.UDPConn implements
net.PacketConn anyway, returning the concrete type here is more powerful
and less risky than having downstream users cast the value themselves
There should be no code change for downstream users, with the exception
of explicit casts (`udpc := conn.(*net.UDPConn)`), which can simply be
removed
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Similar to server4 where the UDP connection is manually created using
the socket interfaces, this creates a connection with adequate options:
* SO_BINDTODEVICE or equivalent if an interface is requested
* V6ONLY when supported by the operating system
* Allows binding to a multicast address specifically instead of
falling back to wildcard
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
Joining a multicast group with an address that can't be received on a
socket is ineffective, at least on linux.
This updates the logic of NewServer in a mostly backwards-compatible
way, to enable listening on arbitrary multicast addresses:
* Unicast addresses see no user-visible change, but don't join a
multicast group for which they don't receive traffic anyway
* Multicast addresses start actually receiving traffic for the group
they represent, and don't join the default group. **this is a
behaviour change**: previously they would receive traffic for the
default group if it was on the same port and **not** for the group
they represent. I consider that previous behaviour a bug
* Wildcard addresses, if on the proper port, will join both
AllDHCPRelayAgentsAndServers and AllDHCPServers **this is a behaviour
change**: previously only AllDHCPRelayAgentsAndServers was joined
* Wildcard addresses on another port: no visible change, same as
unicast case
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
No need to convert here.
|
|
|
|
Mostly addressed missing error checking.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Mostly for dead code and potentially wrong comparisons.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
NewReplyFromMessage creates a reply from a message. With this patch it
can handle Solicit messages with rapid-commit.
RFC3315 states that:
```
If the client has included a Rapid Commit option in its Solicit
message, the client terminates the waiting process as soon as a Reply
message with a Rapid Commit option is received.
```
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|