Hi,
My name is Razvan Becheriu and I am a contributor to the ISC KEA DHCP
server.
I have implemented RFC7618 and draft-ietf-dhc-dhcp4o6-saddr-opt and posted
the implementation in the pull request:
https://github.com/isc-projects/kea/pull/72
You can also find the implementation on my github branch (as specified in
the previous mail):
https://github.com/razvan-becheriu/kea.git
the branch is:
draft-ietf-dhc-dhcp4o6-saddr-opt
I have also provided a separate pull request for the RFC7618 only:
https://github.com/isc-projects/kea/pull/63
You can also find the implementation on my github branch:
https://github.com/razvan-becheriu/kea.git
the branch is:
ipv4_addr_plus_port
The implementation of RFC7618 consists in storing the IPv4 address as a 64
bit integer, the data being comprised of:
8 bits: the offset of the PSID
8 bits: the PSID len
16 bits: the PSID value
The implementation has added this schema modification for the Cassandra and
MySql backends, as the PostgreSql already stores the address as a 64 bit
integer.
This feature has not been implemented for the memfile backend yet.
This implementation keeps backward compatibility for the already assigned
addresses.
The new allocated addresses using IPv4 address plus port will have the Most
Significant Bits (first 32 MSB) non zero (PSID offset, which might be 0,
PSID len, which must NOT be 0, and PSID which might me 0).
All the addresses which no not use IPv4 address plus port will have all
these 3 fields (PSID offset, PSID len and PSID) set to 0.
The following configuration options for the DHCP4 subnet have been added:
"v4-psid-offset"
"v4-psid-len"
"v4-excluded-psids"
All addresses allocated from a subnet with these options set, will be
served to the client as described in RFC7618 (by including the PSID offset,
PSID len and PSID in the DHCPv4 OPTION_V4_PORTPARAMS option: code 159).
This is done only if the client has requested for address plus port
allocation by inserting the request for OPTION_V4_PORTPARAMS in the
DHO_DHCP_PARAMETER_REQUEST_LIST option: code 55, and the server is
configured to honor such requests.
The addresses are allocated sequentially, by increasing the PSID value
starting from 0, to the maximum value of the PSID which is 2 ^ (PSID len) -
1.
Only if all the PSIDs have been allocated, the IPv4 address is incremented
and the PSID is reset to 0.
The configuration option "v4-excluded-psids" can specify a list of PSID
values that should not be allocated to any client (they might be reserved
for other purposes, effectively reserving a port range in the network).
The implementation of the draft-ietf-dhc-dhcp4o6-saddr-opt consists in
adding the 'sw_4o6_src_address' parameter beside the IPv4 address in the
database schema.
The implementation has added this schema modification for the Cassandra,
MySql and PostgreSql backends.
This feature has not been implemented for the memfile backend yet.
The implementation has used the following unassigned options and values:
DHCPv4 option: DHO_S46_SADDR code 201 (option OPTION_DHCP4O6_S46_SADDR in
the draft)
DHCPv6 option: D60_S46_BIND_IPV6_PREFIX code 200 (option
OPTION_S46_BIND_IPV6_PREFIX in the draft)
As mentioned in the document, the client will always receive the value
which he provided in the DHO_S46_SADDR option.
This value is updated in the database as stated in 8.1 from the draft.
The following case in 8.1 from the draft is not currently implemented on
the server side:
The server MAY implement a policy enforcing a minimum time interval
between a client updating its softwire source IPv6 address. If a
client attempts to update the softwire source IPv6 address before the
minimum time has expired, the server can either silently drop the
client's message or send back a DHCPACK message containing the
exisiting IPv6 address binding in OPTION_DHCP4O6_S46_SADDR.
The case stated in 7.5 from the draft is never achieved in the current
implementation.
From my perspective, the implementation of the draft is straightforward and
does not require many changes in the server.
Treating the spacial case of 8.1 and 7.5 might require extra effort,
depending on the actual requirements of the server behavior, as these
details are not specified in the draft.
In the case of sending back the stored value from the database, a time
stamp of the pair (IPv4 address, sw_4o6_src_address) must be also stored.
This is required by the server to know when to update the stored
sw_4o6_src_address value and send the new value or to send the old stored
sw_4o6_src_address value back.
For any comments or implementation details, feel free to contact me.
Regards,
Razvan
Hi,
As a co-author, I support this draft moving forward. RFC7341 and 7618 have
been published for some time now, and this draft describes the final piece
necessary for DHCP4o6 based softwire provisioning.
For reference, we are currently updating and finalising implementations of
https://github.com/razvan-becheriu/kea.git
draft-ietf-dhc-dhcp4o6-saddr-opt
https://github.com/tlabs-openrouter/terastream/tree/bb-
draft-d4o6-saddr-hint/
Thanks,
Ian
The authors have requested a WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt.
Please review this document and provide your comments and whether you
support the document moving forward or not, by April 10th, 2018 (23:59
UTC).
Please see https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-03
.
There are no IPR notices filed against this work (as of this writing).
Thank you!
- Tomek & Bernie
_______________________________________________
dhcwg mailing list
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
https://www.ietf.org/mailman/listinfo/dhcwg
--
razvan becheriu
[image: qualitance.com]
senior software engineer
+40 (746) 090 415 <+40+(746)+090+415>, qualitance.com
<https://www.qualitance.com/>