Hello,
On a linkDown/ifDown, addresses obtained through DHCPv6 are removed (at
least as far as user/application is concerned) -- the actual addresses and
their lifetimes are kept internally by the system so that if the
link/interface comes back up before the address lifetime expires (and we
receive an RA with the ManagedFlag set), we can attempt to confirm the
previously acquired DHCPv6 addresses. Following the Confirm procedure, if
we didn't get a NotOnLink response, the previously acquired addresses are
restored. So, yes, if we don't receive an RA telling us to use DHCPv6, the
previous addresses would be/remain removed.
Yukiyo Akisada <akisada@tahi.org> wrote on 09/30/2009 12:28:14 am:
> Hi, Brian.
>
> Now I'm getting close to your opinion.
>
> In fact, keeping DHCPv6 service with the absence of on-link prefix
> information and default router information has problem
> for the interoperability.
>
> IETF DHC WG charter is also mentioning as quoted below.
>
> "* Hold a discussion whether on-link prefix information and default
> router information is needed in DHCP in addition to router
> advertisements. Actual solutions are out of scope for the WG,
> however."
>
> If a implementation re-builds prefix list and default router list
> by re-attaching to the new link,
> it is reasonable to invoke CONFIRM by RA,
> now I think.
>
> Adding the procedure to send RA explicitly when the receipt of RS
> makes the test procedure more realistic.
>
> But please let me ask more.
>
> When your box couldn't send CONFIRM in the current test case,
> does the box remove its address obtained previously?
>
> Anyway, to change the test sequence,
> we must convince IPv6 Ready Logo Committee.
>
> Fortunately,
> now IPv6 Ready Logo Committee calls the public review for
> DHCPv6 new test specification.
>
> I recommend you to post this issue as the public comment.
> The vendor's comment will be really appreciated.
>
> Thanks,
>
>
> On Tue, 29 Sep 2009 09:24:22 -0500
> Brian Jongekryg <bej@us.ibm.com> wrote:
>
> > Hello,
> >
> > If no RA is received from the beginning, the link will have only its
> > link-local address. DHCPv6 will not be attempted to obtain addresses.
> >
> > Yukiyo Akisada <akisada@tahi.org> wrote on 09/29/2009 01:17:02 am:
> > > Hi, Brian.
> > >
> > > I understand what you said, but please let me ask more.
> > >
> > > When RA is absent from the begining,
> > > what will happen on your box?
> > >
> > >
> > > On Mon, 31 Aug 2009 11:58:18 -0500
> > > Brian Jongekryg <bej@us.ibm.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > RFC 4862, Subsection 5.5.2 : Absence of Router Advertisements
states
> > that
> > > > a host "may" use the DHCPv6 service to assign addresses, not that
it
> > must
> > > > or even that it should. And TAHI appears to acknowledge this since
it
> > has
> > > > the $Send_Initial_RA configuration flag to force an RA at the
> > beginning of
> > > > the test. We chose not to use DHCPv6 for automatic configuration
of
> > > > addresses in the absence of a router (RAs) because having a global
> > address
> > > > is of little use without additional manual configuration of
routes. It
> >
> > > > can't even be used for on-link communications since RFC 4861 has
> > removed
> > > > the "on-link assumption" of RFC 2461 if there is no default route
(and
> > in
> > > > the absence of RAs, we have no prefix list either).
> > > >
> > > > If we actually have an ifDown/ifUp cycle, we don't know that we're
> > > > connected to the same network and it doesn't seem unreasonable to
> > expect
> > > > to receive an RA to rebuild the prefix list and default router
list,
> > and
> > > > to also rely on that RA to tell us whether we should attempt
stateful
> > or
> > > > stateless DHCPv6.
> > > >
> > > > I guess the reason our box requires an RA to continue DHCPv6
service
> > is
> > > > because in this situation it also needs an RA to rebuild any
prefix
> > list
> > > > and default router list. Having DHCPv6 continue without an RA in
that
> > > > situation didn't seem reasonable.
> > > >
> > > > As I read the RFC 2462 section you pointed out, this is discussing
> > changes
> > > > to the ManagedFlag due to receipt of an RA. In that case, we
should
> > > > continue DHCPv6 if an RA is received with the M-bit off when
> > previously it
> > > > was on. I don't read this as having anything to say about what
happens
> >
> > > > following an ifDown.
> > > >
> > > > So I still think that if a node requires RA (with M-bit set)
before
> > using
> > > > stateful DHCPv6, it's reasonable to require an RA following
> > ifDown/ifUp
> > > > before continuing DHCPv6.
> > > >
> > > > I'm not sure where we go from here if I haven't convinced you of
my
> > > > position. I can change my DHCPv6 client implementation to continue
> > without
> > > > the RA, but I'd still fail the DHCP_CONF.1.2.4, Part E test that
> > requires
> > > > an Echo request/response exchange following the Confirm because at
> > that
> > > > point we also have no default route or prefix list and would be
unable
> > to
> > > > send our Echo response. (Assuming my 2nd issue is resolved also.)
> > > >
> > > > What do you think?
> > > >
> > > > Thanks.
> > > >
> > > > Yukiyo Akisada <akisada@tahi.org> wrote on 08/31/2009 02:51:35 am:
> > > >
> > > > > 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>
> > > > >
> > > > --
> > > > Brian Jongekryg
> > > >
> > > >
> > >
> > >
> > > --
> > > Yukiyo Akisada <akisada@tahi.org>
> > >
> >
> > --
> > Brian Jongekryg
> >
> >
>
>
> --
> Yukiyo Akisada <akisada@tahi.org>
>
--
Brian Jongekryg