[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.


Alternatively,

(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.

Greg



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