Changes between Version 3 and Version 4 of ClientRequirements


Ignore:
Timestamp:
Aug 13, 2018, 8:59:10 PM (16 months ago)
Author:
vicky
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ClientRequirements

    v3 v4  
    11= Kea Client Requirements =
    22
    3 This page was created as part of a hackathon in Prague during IETF'99. This is '''very early''' version and it will change significantly.
    4 
    5 Requirements:
    6 - MUST support v4 (RFC2131)
    7 - MUST support v6 (RFC3315bis)
    8 - MUST strictly follow 3315bis
    9 - SHOULD long term goal of being a reference implementation, short term no
    10 
    11 - SHOULD be able to detect dynamic interfaces and conduct actions when new
    12   interface appears (MUST in longterm)
    13 
    14 - SHOULD be able to run duplicate address detection and be able to
    15   recover from duplication event
    16 
    17 - MUST be able to receive PD and split it to remaining interfaces
    18   (must be able to determine downlink interfaces on its own) (long term)
    19 
    20 - MUST be capable of understanding prefix hint in its configuration,
    21   MUST send the prefix to the server and handle the responses, even if
    22   the response contains a prefix different than expected.
    23 
    24 - SHOULD add received addresses with dynamic lifetimes
    25 
    26 - MUST support all of the following:
    27    - call a hook
    28    - add address on its own (if the hook didn't do it)
    29    - call external script (via hook)
    30 
    31 - SHOULD be able to detect link flaps and cope with it
    32 
    33 - SHOULD be able to run several copies in parallel on the same physical
    34   interface (Rackspace use case), affects file management (everything
    35   relative)
    36 
    37 - MUST use configuration in JSON
    38 
    39 - SHOULD support custom options
    40 - SHOULD support vendor class options
    41 
    42 - MUST support both v4 and v6 in a single process
    43 
    44 - MUST support rewriting /etc/resolv.conf (must support rewriting on its own,
    45   calling a script, do both, do neither, hook)
    46 
    47 - SHOULD support stateless configuration
    48 
    49 - MAY be able to obey M and O bits (by default not honored, with
    50   obey-ra-bits, they should be)
    51  
    52 - SHOULD support reconfigure (including reconfigure-key)
    53 
    54 - MUST do hooks
    55 
    56 - MAY support CONFIRM (there must be a way to skip Cofirm and start with SOLICIT)
    57 
    58 - SHOULD support DNS Updates
    59 - MAY request hints (hints are mostly deprecated in 3315bis, except
    60   prefix length)
    61 
    62 - SHOULD use bison as parser
    63 
    64 - MUST the binaries should be as small as possible (i.e. push as much as
    65   realistically possible to hooks)
    66 
    67 - MUST NOT use log4cplus (just a very rudimentary logging)
    68 
    69 - MUST work out of the box - a big advantage of dibbler praised by many users was that it "just
    70   works" out of the box (the defaults were reasonable, it was able
    71   to pick the right interfaces and do the right thing on them)
    72 
    73 - Hook: for full PD scenario? upstream side working as client,
    74   downstream working as a server. The configuration is pushed via
    75   control channel. The received prefix must be split into /64s for
    76   every downlink interface.
    77 
    78 - IOT requirement: try to conserve energy (e.g. sleep between
    79   transmissions), minimal functionality
    80 
    81 - Client MAY support performing dynamic DNS updates
     3See https://gitlab.isc.org/isc-projects/kea/wikis/designs/Kea-Client-Requirements