BIND 10 #991: Method to send a IPv4 packet to a client without an address

[BIND 10 Development]

#991: Method to send a IPv4 packet to a client without an address
-------------------------------------+-------------------------------------
            Reporter:  shane         |                        Owner:
                Type:  enhancement   |  UnAssigned
            Priority:  medium        |                       Status:
           Component:  dhcp4         |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-DHCP-20130411
         Sub-Project:  DHCP          |                   Resolution:
Estimated Difficulty:  0.0           |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by marcin):

 * owner:  marcin => UnAssigned
 * status:  assigned => reviewing


Comment:

 Adding support to respond to clients without address requires use of raw
 sockets. Such sockets can be only created by privileged user. Therefore,
 there is no easy way to unit test this code. The likely approach is to
 create mock object that mimics the operation of the raw socket. This would
 eliminate the need to open a real socket in unit tests. Also, it is
 desired to keep existing implementation around which doesn't use raw
 sockets for the OSes that don't have support for anything else (yet). This
 caused a need to make !IfaceMgr a little bit more modular and abstract the
 code which opens sockets and sends/receives packets into a separate
 (replaceble) class. This required significant number of changes to
 !IfaceMgr, so I decided not to do further implementation (of raw sockets
 etc.) in this ticket. Otherwise it would grow too large and would cause
 serious difficulties to review it.

 Apart from the changes described above  I implemented the short path to
 respond to the client, not having an address, by responding to broadcast
 address. This is proposed by RFC 951 if there is no way to respond
 directly. Obviously, once we implement direct responses they will take
 precedence over responding to broadcast address. Nevertheless, the
 approach has been tested on my local machine and it worked fine.

-- 
Ticket URL: <https://bind10.isc.org/ticket/991#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development