]> git.ipfire.org Git - thirdparty/kea.git/commitdiff
[master] Merge branch 'trac3070'
authorMarcin Siodelski <marcin@isc.org>
Thu, 11 Jun 2015 05:36:59 +0000 (07:36 +0200)
committerMarcin Siodelski <marcin@isc.org>
Thu, 11 Jun 2015 05:36:59 +0000 (07:36 +0200)
1  2 
src/bin/dhcp6/dhcp6_messages.mes
src/bin/dhcp6/dhcp6_srv.cc
src/bin/dhcp6/dhcp6_srv.h
src/bin/dhcp6/json_config_parser.cc
src/bin/dhcp6/tests/config_parser_unittest.cc
src/bin/dhcp6/tests/dhcp6_client.cc

index 9f9de5626f50b900f8d81c68f1024f5ffece8b68,3fcd1a1745d2c3d3d98c9b7ccc9190793ba94236..a119ae6548c1c625b91e667544c61069e25a86d1
@@@ -463,78 -394,54 +463,85 @@@ of the named configuration element, or 
  parsing actions and committal of changes failed.  The reason for the
  failure is given in the message.
  
 -% DHCP6_PD_LEASE_ADVERT prefix lease %1/%2 advertised (client duid=%3, iaid=%4)
 -This debug message indicates that the server successfully advertised
 -a prefix lease. It is up to the client to choose one server out of the
 -advertised servers and continue allocation with that server. This
 -is a normal behavior and indicates successful operation.
 +% DHCP6_PD_LEASE_ADVERT %1: lease for prefix %2/%3 and iaid=%4 will be advertised
 +This debug message indicates that the server will advertise a
 +prefix to the client in the ADVERTISE message. The client will
 +request allocation of this prefix with the REQUEST message sent
 +in the next message exchange. The first argument includes the client
 +and transaction identification information. The remaining arguments
 +hold the allocated prefix, prefix length and IAID.
  
 -% DHCP6_PD_LEASE_ADVERT_FAIL failed to advertise a prefix lease for client duid=%1, iaid=%2
 +% DHCP6_PD_LEASE_ADVERT_FAIL %1: failed to advertise a prefix lease for iaid=%2
  This message indicates that in response to a received SOLICIT, the
 -server failed to advertise a prefix lease for the client. There may
 +server failed to advertise a prefix lease for a given client. There may
  be many reasons for such failure. Each failure is logged in a separate
 -log entry.
 +log entry. The first argument holds the client and transaction identification
 +information. The second argument holds the IAID.
  
 -% DHCP6_PD_LEASE_ALLOC prefix lease %1/%2 has been allocated (client duid=%3, iaid=%4)
 +% DHCP6_PD_LEASE_ALLOC %1: lease for prefix %2/%3 and iaid=%4 has been allocated
  This debug message indicates that in response to a client's REQUEST
 -message, the server successfully granted a prefix delegation lease. This
 -is a normal behavior and indicates successful operation.
 -
 -% DHCP6_PD_LEASE_ALLOC_FAIL failed to grant a prefix lease for client duid=%1, iaid=%2
 -This message indicates that the server failed to grant (in response to
 -received REQUEST) a prefix lease for a given client. There may be many reasons
 -for such failure. Each failure is logged in a separate log entry.
 +message, the server successfully granted an non-temporary address
 +lease. This is a normal behavior and indicates successful operation.
 +The first argument includes the client and transaction identification
 +information. The remaining arguments hold the allocated prefix,
 +prefix lenngth and and IAID.
  
 -% DHCP6_PROCESS_IA_NA_REQUEST server is processing IA_NA option (duid=%1, iaid=%2, hint=%3)
 +% DHCP6_PD_LEASE_ALLOC_FAIL %1: failed to grant a prefix lease for iaid=%2
 +This message indicates that in response to a received REQUEST, the server
 +failed to grant a prefix lease for the client. There may be many reasons
 +for such failure. Each failure is logged in a separate log entry. The first
 +argument holds the client and transaction identification information.
 +The second argument holds the IAID.
 +
 +% DHCP6_PROCESS_IA_NA_EXTEND %1: extending lease lifetime for IA_NA option with iaid=%2
 +This message is logged when the server is starting to extend the lifetime
 +of the address lease associated with the particular IAID. The first argument
 +includes the client and transaction identification information. The second
 +argument contains the IAID.
 +
 +% DHCP6_PROCESS_IA_NA_RELEASE %1: releasing lease for IA_NA option with iaid=%2
 +This message is logged when the server is trying to release the client's
 +as a result of receiving the RELEASE message. The first argument
 +includes the client and transaction identification information. The second
 +argument contains the IAID.
 +
 +% DHCP6_PROCESS_IA_NA_REQUEST %1: server is processing IA_NA option with iaid=%2 and hint=%3
  This is a debug message that indicates the processing of a received
 -IA_NA option. It may optionally contain an address that may be used by
 -the server as a hint for possible requested address.
 -
 -% DHCP6_PROCESS_IA_PD_REQUEST server is processing IA_PD option (duid=%1, iaid=%2, hint=%3)
 +IA_NA option. The first argument contains the client and the transaction
 +identification information. The second argument holds the IAID of the
 +IA_NA option. The third argument may hold the hint for the server
 +about the address that the client would like to have allocated.
 +If there is no hint, the argument should provide the text indicating
 +that the hint hasn't been sent.
 +
 +% DHCP6_PROCESS_IA_PD_EXTEND %1: extending lease lifetime for IA_PD option with iaid=%2
 +This message is logged when the server is starting to extend the lifetime
 +of the prefix lease associated with the particular IAID. The first argument
 +includes the client and transaction identification information. The second
 +argument contains the IAID.
 +
 +% DHCP6_PROCESS_IA_PD_REQUEST %1: server is processing IA_PD option with iaid=%2 and hint=%3
  This is a debug message that indicates a processing of received IA_PD
 -option. It may optionally contain an prefix that may be used by the server
 -as a hint for possible requested prefix.
 -
 -% DHCP6_QUERY_DATA received packet length %1, data length %2, data is %3
 -A debug message listing the data received from the client or relay.
 +option. The first argument contains the client and the transaction
 +identification information. The second argument holds the IAID of the
 +IA_PD option. The third argument may hold the hint for the server
 +about the prefix that the client would like to have allocated.
 +If there is no hint, the argument should provide the text indicating
 +that the hint hasn't been sent.
 +
 +% DHCP6_QUERY_DATA %1, packet details: %2
 +A debug message printing the details of the received packet. The first
 +argument includes the client and the transaction identification
 +information.
  
 -% DHCP6_RELEASE_MISSING_CLIENTID client (address=%1) sent RELEASE message without mandatory client-id
 -This warning message indicates that client sent RELEASE message without
 -mandatory client-id option. This is most likely caused by a buggy client
 -(or a relay that malformed forwarded message). This request will not be
 -processed and a response with error status code will be sent back.
+ % DHCP6_RAPID_COMMIT %1: Rapid Commit option received, following 2-way exchange
+ This debug messgage is issued when the server found a Rapid Commit option
+ in the client's message and 2-way exchanges are supported by the
+ server for the subnet on which the client is connected. The argument
+ specifies the client and transaction identification information.
 -% DHCP6_RELEASE_NA address %1 belonging to client duid=%2, iaid=%3 was released properly
 +% DHCP6_RELEASE_NA %1: binding for address %2 and iaid=%3 was released properly
  This debug message indicates that an address was released properly. It
  is a normal operation during client shutdown.
  
index 9adda172d2f59586bea4611c0628799884a09473,8c7ff070aacb33a0e205e52e33cae2233c584606..a57f1f539d181c1c50830630af251ea6d5719b83
@@@ -1373,17 -1298,32 +1373,18 @@@ Dhcpv6Srv::assignIA_NA(const Pkt6Ptr& q
          return (ia_rsp);
      }
  
-     // "Fake" allocation is processing of SOLICIT message. We pretend to do an
-     // allocation, but we do not put the lease in the database. That is ok,
-     // because we do not guarantee that the user will get that exact lease. If
-     // the user selects this server to do actual allocation (i.e. sends REQUEST)
-     // it should include this hint. That will help us during the actual lease
-     // allocation.
-     bool fake_allocation = false;
-     if (query->getType() == DHCPV6_SOLICIT) {
-         /// @todo: Check if we support rapid commit
-         fake_allocation = true;
 -    // Check if the client sent us a hint in his IA_NA. Clients may send an
 -    // address in their IA_NA options as a suggestion (e.g. the last address
 -    // they used before).
 -    boost::shared_ptr<Option6IAAddr> hint_opt =
 -        boost::dynamic_pointer_cast<Option6IAAddr>(ia->getOption(D6O_IAADDR));
 -    IOAddress hint("::");
 -    if (hint_opt) {
 -        hint = hint_opt->getAddress();
--    }
 -
 -    LOG_DEBUG(dhcp6_logger, DBG_DHCP6_DETAIL, DHCP6_PROCESS_IA_NA_REQUEST)
 -        .arg(duid ? duid->toText() : "(no-duid)").arg(ia->getIAID())
 -        .arg(hint_opt ? hint.toText() : "(no hint)");
 -
+     // "Fake" allocation is the case when the server is processing the Solicit
+     // message without the Rapid Commit option and advertises a lease to
+     // the client, but doesn't commit this lease to the lease database. If
+     // the Solicit contains the Rapid Commit option and the server is
+     // configured to honor the Rapid Commit option, or the client has sent
+     // the Request message, the lease will be committed to the lease
+     // database. The type of the server's response may be used to determine
+     // if this is the fake allocation case or not. When the server sends
+     // Reply message it means that it is committing leases. Other message
+     // type (Advertise) means that server is not committing leases (fake
+     // allocation).
+     bool fake_allocation = (answer->getType() != DHCPV6_REPLY);
  
      // Get DDNS update direction flags
      bool do_fwd = false;
@@@ -1542,13 -1458,32 +1543,18 @@@ Dhcpv6Srv::assignIA_PD(const Pkt6Ptr& q
          return (ia_rsp);
      }
  
-     // "Fake" allocation is processing of SOLICIT message. We pretend to do an
-     // allocation, but we do not put the lease in the database. That is ok,
-     // because we do not guarantee that the user will get that exact lease. If
-     // the user selects this server to do actual allocation (i.e. sends REQUEST)
-     // it should include this hint. That will help us during the actual lease
-     // allocation.
-     bool fake_allocation = (query->getType() == DHCPV6_SOLICIT);
 -    // Check if the client sent us a hint in his IA_PD. Clients may send an
 -    // address in their IA_PD options as a suggestion (e.g. the last address
 -    // they used before).
 -    boost::shared_ptr<Option6IAPrefix> hint_opt =
 -      boost::dynamic_pointer_cast<Option6IAPrefix>(ia->getOption(D6O_IAPREFIX));
 -    IOAddress hint("::");
 -    if (hint_opt) {
 -        hint = hint_opt->getAddress();
 -    }
 -
 -    LOG_DEBUG(dhcp6_logger, DBG_DHCP6_DETAIL, DHCP6_PROCESS_IA_PD_REQUEST)
 -        .arg(duid ? duid->toText() : "(no-duid)").arg(ia->getIAID())
 -        .arg(hint_opt ? hint.toText() : "(no hint)");
 -
+     // "Fake" allocation is the case when the server is processing the Solicit
+     // message without the Rapid Commit option and advertises a lease to
+     // the client, but doesn't commit this lease to the lease database. If
+     // the Solicit contains the Rapid Commit option and the server is
+     // configured to honor the Rapid Commit option, or the client has sent
+     // the Request message, the lease will be committed to the lease
+     // database. The type of the server's response may be used to determine
+     // if this is the fake allocation case or not. When the server sends
+     // Reply message it means that it is committing leases. Other message
+     // type (Advertise) means that server is not committing leases (fake
+     // allocation).
+     bool fake_allocation = (answer->getType() != DHCPV6_REPLY);
  
      // Use allocation engine to pick a lease for this client. Allocation engine
      // will try to honour the hint, but it is just a hint - some other address
Simple merge
Simple merge
Simple merge