Subject: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

From: HYUN WOOK CHA <[email-masked]>
Date: Tue, 30 Sep 2008 00:30:32 +0000 (GMT)

Hello, Thomas and Ted.

Please see my inline comments.

<snipped from Ted's posting>

On Sep 18, 2008, at 6:01 AM, Thomas Narten wrote:
>> Perhaps this point might be a major conflict. As we both know,
>> consecutive DHCPv6 SOLICIT messages are sent exponentially
>> back-offed if no valid replies are received within timeouts. Since
>> this always holds, I would like to ask you why M/O flags should not
>> be deprecated.
>
> Because the WG doesn't feel that the flags were so problematic that
> they needed to be deprecated? There certainly has been concern that
> existing implementations that do support the M&O bits should not
> become non-complient through deprecation of the M&O flags.

Why would they become non-compliant?   I think it's because DHCPv6  
clients would not attempt to discover DHCPv6 servers if the managed  
bit wasn't set.  So there's an easy solution: deprecate the bits, but  
require that both the M and O bits be set in all RA messages.

(Joseph) What if DHCPv6 service is not provisioned for the link? For existing implementations which do not provide user interface for manual(or static) configuration, iit might be desirable that M/O bits in RA messages should be cleared. 

> IMO, if we were to start over knowing what we know today, I'd be in
> favor of not having the M&O bits at all. But we are not starting from
> scratch...

It's never too late.   It's simply unclear what the M&O bits do right  
now.   By leaving this lack of clarity, we practically guarantee that  
interoperability problems will arise, because the RFCs provide no  
guidance on how the implementor should deal with transitions or  
conflicts in M&O bit settings.

(Joseph) I agree. I pointed out that DHCPv6 client in the Vista behaves poorly when there exists conflict in M & O bits in RA messages from different routers int the Philadelphia meeting.

>> Sure, this would work. Though one can question whether the additional
>> implementation complexity is worth the benefit.

Deprecating M&O would definitely be simpler.

> If your real concern is that DHC continues to be invoked forever (even
> when no DHC servers are available), wasting network resources, IMO,
> the better place to make changes is in the DHC specification. I.e.,
> the DHC client should backoff more aggressively and "poll" for the
> appearance of a new server very infrequently.

I don't know what Joseph's objections are, but my reason for being  
interested in this is that I see a potential dead zone in the protocol  
that clients can get into but can't get out of.   Because DHCP relay  
is required for a solicit to go off-network, if no DHCPv6  
infrastructure exists at a site, there will be no concentration of  
solicits on a central server, and the number of packets per second  
will be fairly small even on a crowded network.

So my reason for wanting to address the problem Joseph is talking  
about is simply that as it stands, there is no clear recommendation  
for implementors as to how to handle transitions, and I suspect that  
some implementations will wind up doing the wrong thing, because in  
fact the implementor may not even think about the problem Joseph has  
raised.

I would actually prefer your solution to Joseph's: just deprecate the  
M&O bits, and require that they be set on to prevent whatever old  
implementations are already deployed from failing to attempt DHCPv6.

But if the IPv6 WG does have consensus that DHCPv6 should not happen  
if the M bit isn't set, and that DHCPv6-lite shouldn't happen if the O  
bit isn't set, then I think something is needed to address the concern  
that Joseph has identified.   And if the IPv6 WG cannot reach  
consensus on this point, I don't think that's a reason to leave things  
as they are, because things are broken as they are.

(Joseph) Ted, I appreciate your opinion.
Thomas, I would like to request your answer on this point. 

The main reason, I think, that the DHCPv6 WG doesn't have a consensus  
on this is that the RFC that's supposed to address this problem is not  
a DHC RFC.

> This would be appear to be as simple as changing the value of  
> SOL_MAX_RT:
>
>   Parameter     Default  Description
>   -------------------------------------
>   SOL_MAX_RT      120 secs  Max Solicit timeout value
>
> See Section 17.1.2 in RFC 3315.

This would make DHCPv6 recover very slowly from a server outage, and I  
don't think it's necessary - 120 seconds is a pretty long time.   If  
you have 200 clients on a link, that's fewer than 2 solicits per  
second.   However, I am definitely sympathetic to those who would  
prefer not to see these solicits at all.

(Joseph) Agreed.

Joseph
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Sep 2008 17:36:18 -0700

Joseph, to summarize, it sounds like you believe that the ability to  
stop DHCP clients broadcasting on a link is a requirement.   And you  
therefore think that deprecating the M&O bits is not the right  
answer.   Is that correct?