[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stateful != M , Stateless != O

Hi Jinmei,

JINMEI Tatuya / ???? wrote:
>>>>>>On Wed, 11 Aug 2004 14:16:03 +1000, 
>>>>>>Greg Daley <greg.daley@eng.monash.edu.au> said:
>>This is a bit of a rant.
>>Please accept my apologies. I'm quite concerned by
>>the form of the document at the moment, although I
>>think that the function needs to be available.
> No need to apologize, I know the proposed concept described in the
> draft is still immature and needs further detailed discussion.  Any
> positive or negative comments are appreciated.
>>I think that the problems with the draft are not
>>the policies themselves, but the distinction between
>>"Stateless DHCPv6" and "Stateful IPv6"
>>Where these are identified synonymously with 3315 (Stateful)
>>and 3736 (Stateless).
> [... snipped]
> I now feel I get understanding the point...to make it sure, let me try
> to rephrase that.
> Assume we have a "stateful" DHCPv6 server (that implements RFC3315)
> running.  The server should support both
> Solicit/Advertise/Request/Reply(/and Renew) and
> Information-request/Reply exchanges.
> Then the administrator would send Router Advertisement with the M flag
> being ON and the O flag being OFF.  (The O flag is OFF since there is
> no server that only supports RFC3736).
> Now consider a host that only implements (the client side of) RFC3736,
> configures global addresses via stateless address autoconfiguration
> (assuming the RAs provide global prefixes for this), and wants to
> configure recursive DNS server addresses using RFC3736.  However,
> since the O flag is OFF in advertised RAs, the host would not be able
> to invoke the RFC3736 procedure and therefore cannot configure DNS
> server addresses.  This should be a suboptimal scenario.
> Is this what you're mainly worrying about?

I think that's one of the issues.

It leads to the idea that M|O = 1 can be used to invoke Information-Request.

So in this case, the policy shouldn't be called M policy
and O policy since either the M or O flag can be used to
invoke Information-Request.


(where ==> is implies)

If we assume that the O=1 ==> Information Request is available,
and we assume that M=1 ==> Rebind/Renew/Request is available,

then the flags have distinct functions which are tied to
separate classes of host responses, and the O-Policy, M-Policy
are actually "Information-Request" Policy and "Rebind/Renew/Request"
Policy, (but are unambiguously named with the O and M, so the
names are OK).

I have no problem with this, although it implies that
M=1 and O=0 is not a valid advertisement state.

It's important to relize though that a host doesn't invoke
RFC 3736 procedures though.  The host only cares that it wants to
do an Information-Request.  3736 is an implementation hint for
DHCPv6 servers and relays, not hosts.


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6