HYUN WOOK CHA <[EMAIL PROTECTED]> writes:
Hello, Thomas Narten and 6MAN folks.
I made a presentation for our draft "draft-cha-ipv6-ra-mo-00.txt" at
the 6MAN session in Dublin IETF. This draft aims to clarify the
handling of the M/O flags of IPv6 RA. Though I got several comments
during my presentation, I could not figure out what you really
pointed out. So, I decided to ask you again why you think that the
issues which the draft addresses are neither clear nor considered as
worthy to be discussed in the 6MAN wg.
Meta point. This WG has (multiple times) over the last few years had
discussions about what the best semantics for the M&O bits should
be. Despite hundreds of emails, and multiple drafts, there was not
(and still is not) consensus on what the exact semantics should be.
If you look at the history, RFC 2462 had text about the M&O bits. It
basically said that if the M or O bit was set, a client should invoke
DHC. Note: the wording was "should" not "must". When 2462 was reissued
as RFC4862, all the wording about the M&O bits was removed. The change
section says:
o Removed the text regarding the M and O flags, considering the
maturity of implementations and operational experiences.
ManagedFlag and OtherConfigFlag were removed accordingly. (Note
that this change does not mean the use of these flags is
deprecated.)
This was done because the WG could not agree on alternative wording on
how to define the M&O bits.
Thus, my main comment at the microphone was that unless something has
changed (and I have seen no indication of this), the WG should not
take on this topic or discuss it further because there is no consensus
to make any changes.
First of all, I would like to give a brief summary for the draft.
Existing specification (RFC2462) does not give a method on how to
revoke DHCPv6 clients once they were invoked by the M or O flags of
RA messages.
Personally, I do not believe this is wrong or a problem. IMO, it is
just fine that there is no way to revoke an earlier hint that DHC is
available and clients should use it. (DHC has its own ways for dealing
with unresponsive servers -- clients will retransmit at a very low
rate, in such a way that such retransmissions do not cause operational
problems.)
Let us think about the case that a administrator wants to change
network policy from stateful addressing via DHCPv6 to stateless
one.
It can do so by simply starting to send out RAs with the relevant
information. There is no need to disable DHC in order to switch to
stateless configuration. (It would of course be foolish for the
information sent out via RAs to conflict with the DHC advertised
information.)
Although the admin clears M flag of RA messages and reconfigure(or
shutdown) the DHCPv6 server, the DHCPv6 clients keep operating. Even
after all bindings expire and stateful addresses are invalidated,
the client will keep searching another stateful servers by sending
SOLICITs, because the DHCPv6 protocol does not care about values of
RA flags.
As stated before, I do not consider this to be a problem.
If the intention of the restriction that DHCPv6 clients should be
invoked at the transition from FALSE to TRUE of the M or O flag of
RA is that waste of resources of network infrastructure and host
devices caused by useless DHCPv6 operation can be prevented and
stateful addresses can be configured automatically by the
administrative policy, we believe that our draft has value to
supplement missing parts which existing specification and
implementations have.
Note: there is not WG consensus that if the M/O bits are cleared that
one MUST NOT invoke DHC. Routers could be misconfigured and leave the
bits cleared, even though DHC is to be used. Or there may not even be
a router on the link! Thus, some persons argue that they want the
freedom to ignore the M&O bits and invoke DHC anyway. That said,
others (just as strongly) feel that a client MUST NOT invoke DHC if
the M/O bits are cleared. This is a point on which the WG simply does
not have consensus. I do not believe anything has changed in the WG to
suggest that the WG could reach agreement now, if it were to reopen
discussion on the matter.
The second issue (which is likely less important) is concering
conflicts M/O flags from different routers which belongs to differnt
administrative domains.
This type of environment is problematical and there are no good
solutions. If two routers are sending out conflicting information
(intentionally), there is little a client can do to "make things
right".
Existing IPv6 stack implementations such as linux are assumed to
comply with handling of the M/O flags of RA in the RFC2462. So, they
just keep the most recent M/O values without considering senders of
RA messages.
In this type of environment, you would presumably want clients to
continue using DHC even if an RA was received with the M&O bits
cleared. That is precisely the behavior that is defined/implemented
today per existing RFCs.
Your proposal would differ and (from what I can tell) cause DHC to be
enabled/disabled/enabled/disabled/etc/ over and over again. This seems
like a bad solution in this case.
This point does not expose serious problems though it does not
provide consistent informations about the availability of the DHCPv6
service. Since we would like to support revocation of DHCPv6 clients
at the transition of M or O flag from TURE to FALSE, the handling of
the flags is reworked in our draft to avoid the iteration of
invoking and revoking of the clients.
I do not agree with your problem statement that there is a need to
revoke DHC.
IMO, the WG should first discuss the actual problem statement. That
is, discuss what exactly is broken that needs to be fixed. Only if
there is agreement that we have a problem that needs fixing should the
WG revisit this topic.
Thomas
_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/dhcwg
