Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Proposed design for DHCP4o6 in Kea (Tomek Mrugalski)
2. Re: Proposed design for DHCP4o6 in Kea (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Wed, 19 Aug 2015 18:54:22 +0200
From: Tomek Mrugalski <[email protected]>
To: Francis Dupont <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Proposed design for DHCP4o6 in Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 13.08.2015 20:55, Francis Dupont wrote:
> Tomek Mrugalski writes:
>> Design: http://kea.isc.org/wiki/Dhcp4o6Design
>
> => the main issue in the previous attempt is to pas the decapsulated packet.
> In fact not only the whole packet with the DHCPv6 relay stuff is required
> but some extra infos are needed too: the receiving interface and the
> IPv6 source/client address.
> BTW Unix sockets are again the worst solution. For ISC DHCP I used a
> pair of UDP sockets bound to the loopback. As I explained in this list
> we can use the same format and transport so be able to develop both
> sides (DHCPv6 and DHCPv4) in parallel...
But it's also a solution that does not suffer from security problem:
with UDP sockets open on loopback, any non-root user can send packets
to. But the approach has more long term implications.
CommandSocketFactory is expected to be extended with other communication
methods, not just unix sockets. When this is done, both control channel
for Kea as well as 4o6 communication channel will be extended to cover it.
> A final note: it seems the same format should be used in both way,
> i.e., in DHCPv6 -> DHCPv4 and DHCPv4 -> DHCPv6. And TWO sockets are
> needed if you don't want to read what you've just written.
My intention as to use the same format both ways. If the text is unclear
about it, we need to reword it.
>> If possible, I'd like this design discussion to conclude no later than
>> the next Friday, Aug. 14th.
> => a bit short and BTW I didn't see any contributions...
We had a discussion in Prague that we'll provide a preliminary design
within 2 weeks and a final one within 3-4 weeks. That's where the Aug.
14th came from. However, since Tsinghua team is now on vacation and is
expected to come back on Aug. 20th, we still have couple more days.
Tomek
------------------------------
Message: 2
Date: Wed, 19 Aug 2015 19:30:30 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Proposed design for DHCP4o6 in Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Tomek Mrugalski writes:
> > BTW Unix sockets are again the worst solution. For ISC DHCP I used a
> > pair of UDP sockets bound to the loopback. As I explained in this list
> > we can use the same format and transport so be able to develop both
> > sides (DHCPv6 and DHCPv4) in parallel...
> But it's also a solution that does not suffer from security problem:
> with UDP sockets open on loopback, any non-root user can send packets
> to.
=> not if the port numbers are low enough (BTW as DHCP uses so called
priviledged ports this has no operational impacts).
> But the approach has more long term implications.
> CommandSocketFactory is expected to be extended with other communication
> methods, not just unix sockets. When this is done, both control channel
> for Kea as well as 4o6 communication channel will be extended to cover it.
=> note I shall extend it for Windows which has no Unix sockets.
I have proposed the code for the previous/obsolete version (90%
of the change is about to parse a port number vs. a path).
> > A final note: it seems the same format should be used in both way,
> > i.e., in DHCPv6 -> DHCPv4 and DHCPv4 -> DHCPv6. And TWO sockets are
> > needed if you don't want to read what you've just written.
> My intention as to use the same format both ways. If the text is unclear
> about it, we need to reword it.
=> the note has 2 points: same format *and* two sockets.
> >> If possible, I'd like this design discussion to conclude no later than
> >> the next Friday, Aug. 14th.
> > => a bit short and BTW I didn't see any contributions...
> We had a discussion in Prague that we'll provide a preliminary design
> within 2 weeks and a final one within 3-4 weeks. That's where the Aug.
> 14th came from. However, since Tsinghua team is now on vacation and is
> expected to come back on Aug. 20th, we still have couple more days.
=> what about to reuse the ISC DHCP design? The 2 processes idea is more
natural in Kea so it is more about the communication between them.
Regards
Francis Dupont <[email protected]>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 17, Issue 14
***************************************
