Hi, Brian.
This is for the first issue.
I'm wondering why your box requires to receive RA to continue DHCPv6 service.
Regardless of whether the link is the same or the new,
there is the actual link that the router doesn't send RA
as quoted below.
RFC 4862: IPv6 Stateless Address Autoconfiguration
Subsection 5.5.2.: Absence of Router Advertisements
967 Even if a link has no routers, the DHCPv6 service to obtain addresses
968 may still be available, and hosts may want to use the service. From
969 the perspective of autoconfiguration, a link has no routers if no
970 Router Advertisements are received after having sent a small number
971 of Router Solicitations as described in [RFC4861].
972
973 Note that it is possible that there is no router on the link in this
974 sense, but there is a node that has the ability to forward packets.
975 In this case, the forwarding node's address must be manually
976 configured in hosts to be able to send packets off-link, since the
977 only mechanism to configure the default router's address
978 automatically is the one using Router Advertisements.
So I'm still thinking that Confirm should be transmitted
even when the host doesn't receive RA.
Furthermore, as you know that RFC 4862 removed the text related to M/O bit,
but originaly RFC 2462 said as following.
RFC 2462: IPv6 Stateless Address Autoconfiguration
Subsection 5.5.3.: Router Advertisement Processing
917 On receipt of a valid Router Advertisement (as defined in
918 [DISCOVERY]), a host copies the value of the advertisement's M bit
919 into ManagedFlag. If the value of ManagedFlag changes from FALSE to
920 TRUE, and the host is not already running the stateful address
921 autoconfiguration protocol, the host should invoke the stateful
922 address autoconfiguration protocol, requesting both address
923 information and other information. If the value of the ManagedFlag
924 changes from TRUE to FALSE, the host should continue running the
925 stateful address autoconfiguration, i.e., the change in the value of
926 the ManagedFlag has no effect. If the value of the flag stays
927 unchanged, no special action takes place. In particular, a host MUST
928 NOT reinvoke stateful address configuration if it is already
929 participating in the stateful protocol as a result of an earlier
930 advertisement.
931
932 An advertisement's O flag field is processed in an analogous manner.
933 A host copies the value of the O flag into OtherConfigFlag. If the
934 value of OtherConfigFlag changes from FALSE to TRUE, the host should
935 invoke the stateful autoconfiguration protocol, requesting
936 information (excluding addresses if ManagedFlag is set to FALSE). If
937 the value of the OtherConfigFlag changes from TRUE to FALSE, the host
938 should continue running the stateful address autoconfiguration
939 protocol, i.e., the change in the value of OtherConfigFlag has no
940 effect. If the value of the flag stays unchanged, no special action
941 takes place. In particular, a host MUST NOT reinvoke stateful
942 configuration if it is already participating in the stateful protocol
943 as a result of an earlier advertisement.
I can interpret this text as that
the host doesn't need to receive subsequent RAs to transmit Confirm
because DHCPv6 service was already started.
RFC 2462 doesn't have any effects any more,
but from these points,
I still believe that the test script doesn't need to add the second RA to invoke Confirm.
How do you think?
Regards,
On Wed, 26 Aug 2009 00:46:54 -0500
Brian Jongekryg <bej@us.ibm.com> wrote:
> Hello, thanks for the reply.
>
> I should explain our processing some more. On an ifDown, the DHCPv6 client
> enters a "quiesced" state and remains in that state until the ifUp and a
> subsequent RA w/ M-bit (or O-bit) set is received. Since I may have moved
> to a new link, I rely on the RA again to know whether DHCP is supported on
> this link and to also rebuild the default router list. (RS will be sent
> upon reattaching to the link to speed up receipt of RA.)
>
> > RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
> > 18.1.2. Creation and Transmission of Confirm Messages
> >
> > 2219 Whenever a client may have moved to a new link, the
> > prefixes from the
> > 2220 addresses assigned to the interfaces on that link may no
> longer be
> > 2221 appropriate for the link to which the client is attached.
> ...
> > 2232 In any situation when a client may have moved to a new link,
> the
> > 2233 client MUST initiate a Confirm/Reply message exchange.
>
> I read this to mean I can not continue to use previously obtained
> addresses from DHCP without attempting to Confirm them first. And I will
> initiate a Confirm/Reply exchange if RAs on the new link indicate DHCP
> should be used (M-bit set).
>
> So after true client restart or even just ifDown/Up, the NUT would require
> an RA before initiating the Confirm/Reply exchange and to rebuild the
> default router list. However, for testing, I have an interface to
> "quiesce" the DHCPv6 client and wake it up again, which, to the DHCPv6
> client, is identical to an ifDown/ifUp/RA,M-bit sequence. If that's
> allowable for logo testing, then I don't need the RA.
>
> For the second question, I am referring to Test DHCP_CONF.1.2.4 Part E. I
> will send you the log directly in a separate message. The NUT does send
> the Confirm message but the problem is in the timing of the Echo request
> sent as verification that the NUT continues to use the address.
>
> Thanks.
>
> Yukiyo Akisada <akisada@tahi.org> wrote on 08/25/2009 11:24:02 pm:
>
> > Hi, Brian.
> >
> > For the first question,
> > this test requires to transmit Confirm without restarting DHCPv6
> function.
> >
> > You don't need to initialize DHCPv6 function on your box
> > since Confirm message exchange is performed under running DHCPv6
> service.
> >
> > RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
> > 18.1.2. Creation and Transmission of Confirm Messages
> >
> > 2219 Whenever a client may have moved to a new link, the
> > prefixes from the
> > 2220 addresses assigned to the interfaces on that link may no
> longer be
> > 2221 appropriate for the link to which the client is attached.
> Examples
> > 2222 of times when a client may have moved to a new link include:
> > 2223
> > 2224 o The client reboots.
> > 2225
> > 2226 o The client is physically connected to a wired connection.
> > 2227
> > 2228 o The client returns from sleep mode.
> > 2229
> > 2230 o The client using a wireless technology changes access
> points.
> > 2231
> > 2232 In any situation when a client may have moved to a new link,
> the
> > 2233 client MUST initiate a Confirm/Reply message exchange.
> >
> > As section 18.1.2 said,
> > the trigger of transmitting Confirm depends on the implementation,
> > so you can use any method to transmit Confirm.
> >
> > The test specification also permits other method than network
> > interface down/up.
> >
> > For example, Step 2 of Test DHCP_CONF.1.2.4: Transmission of Confirm
> > messages says,
> >
> > 2. Physically disconnect the NUT interface on Link A. (This can
> > also be achieved by disabling and
> > re-enabling the network interface)
> >
> > Do you still need the additional RA?
> >
> >
> > For the second question,
> > are you talking about Test DHCP_CONF.1.2.4 Part E?
> >
> > If so, this test verifies that
> > NUT continues to use IP address even when Confirm/Reply exchange
> > could not be completed
> > as I quoted below.
> >
> > 18.1.2. Creation and Transmission of Confirm Messages
> >
> > 2278 If the client receives no responses before the message
> transmission
> > 2279 process terminates, as described in section 14, the client
> SHOULD
> > 2280 continue to use any IP addresses, using the last known
> > lifetimes for
> > 2281 those addresses, and SHOULD continue to use any other
> previously
> > 2282 obtained configuration parameters.
> >
> > If you send the actual test log, I could investigate more.
> > But in this moment, I guess that your box didn't transmit Confirm
> Message
> > since this test doesn't forcus on DAD.
> >
> > I hope that this second issue can be solved by solving the first issue.
> >
> > Thanks,
> >
> >
> > On Tue, 25 Aug 2009 01:10:37 -0500
> > Brian Jongekryg <bej@us.ibm.com> wrote:
> >
> > > I'm the running the TAHI DHCPv6 tests, version 1.0.17, against a
> DHCPv6
> > > client end node.
> > >
> > > Most tests I'm not having a problem with, but since the end node
> > > requires a Router Advertisement with the M-bit set before initiating
> > > DHCP, I'm having a problem with the Confirm message tests in the RFC
> > > 3315 section. These tests call for restarting the NUT or forcing an
> > > interface down/up to cause the client to attempt to Confirm its
> addresses.
> > >
> > > The problem I have is that following a node restart or interface
> reset,
> > > the NUT requires another RA with M-bit set before restarting DHCP (and
>
> > > also requires the RA to re-create the default route so that the Echo
> > > reply required by some of the tests can be sent).
> > >
> > > It seems like a new RA should be sent by TAHI in this case, especially
>
> > > when $Send_Initial_RA = 1 is set in the configuration.
> > >
> > > I'm able to complete the Confirm tests by forcing the DHCPv6 client
> > > through the same sequence it would execute following a link down/up
> > > without actually forcing the link down/up. Would that be sufficient
> for
> > > logo testing? It still seems it would be better to test with a real
> > > interface reset however.
> > >
> > > A second Confirm problem I have is that the NUT performs duplicate
> > > address detection on all DHCPv6 addresses when they are started or
> > > restarted. This results in a failure with the DHCPv6 RFC 3315 test #43
>
> > > (no response to repeated Confirm) -- TAHI expects the node to respond
> to
> > > an Echo request sent 10 seconds after TAHI has received the first
> > > Confirm. However, in my case, DAD is only being initiated at this
> point,
> > > so the Echo request is discarded and no response is returned.
> > >
> > > RFC 3315 calls for DAD on addresses following the Reply, but I don't
> > > read it to preclude doing DAD if no Reply is received to the Confirm.
> > >
> > > I'd appreciate any comments on these issues.
> > >
> > > Thanks.
> > > --
> > > Brian Jongekryg
> > >
> > >
> >
> >
> > --
> > Yukiyo Akisada <akisada@tahi.org>
> >
> --
> Brian Jongekryg
>
--
Yukiyo Akisada <akisada@tahi.org>