> On Wed, 28 Apr 2004 12:16:15 -0400,
> Ralph Droms <[EMAIL PROTECTED]> said:
> I think the O flag (if we keep it!) should simply specify DHCPv6, with no
> implication about the way in which DHCPv6 is used.
> "Stateless DHCPv6" is simply a way to use some of the messages from the full
>
> On Thu, 29 Apr 2004 11:09:18 -0400,
> "Bound, Jim" <[EMAIL PROTECTED]> said:
> 3315 supports both m and o. just a fact. that I know.
I'm not really sure about the intention of the above statement, but I
guess you made your opinion (fact?) for the following point.
>> - which protocol
(B (BOn Apr 29, 2004, at 10:29 AM, Tim Chown wrote: (B (B (BOn Thu, Apr 29, 2004 at 06:12:02PM +0300, Pekka Savola wrote: (B (BOn Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (B- details of the relationship between each flag and protocol, (Be.
On Thu, Apr 29, 2004 at 06:12:02PM +0300, Pekka Savola wrote:
> On Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H(B wrote:
> > - details of the relationship between each flag and protocol, e.g.
> > whether we should mandate to invoke the protocol or we can just
> > rega
> and so the exchange should fail at this stage.
I just realised some implications of your post. As I wrote in my other
mail, the client indeed does not need to send IA options and hence the
NoAddrsAvail will not be sent to the client in an Advertise message, if
no IA options are used in the first
> I support Christian's suggestion; they should be just hints.
I also support this suggestion.
> No flag is going to force the node to run a protocol. More often than
> not, for implementation simplicity, I'd guess most nodes (especially
> where DHCPv6 is available), the nodes are going to run
> If the client does not want address assignment, is it okay for the
> client to send a Solicit without including an IA option? It's not
That should be possible, yes. The purpose of a solicit message is to
find a DHCPv6 server or a relay agent, there's no implication that it
has some immediate co
29, 2004 11:12 AM
> To: JINMEI Tatuya / çæéå
> Cc: [EMAIL PROTECTED]
> Subject: M/O flags: hints vs more [Re: the protocols for the
> M/O flags (Re: [rfc2462bis] whether we need the M/O flags)]
>
> On Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP]
> [EMAIL PROTECTED]@C#:H
On Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H(B wrote:
> - details of the relationship between each flag and protocol, e.g.
> whether we should mandate to invoke the protocol or we can just
> regard the flag as a hint and let the host decide if it invokes the
> pr
the M/O flags (Re:
> [rfc2462bis] whether we need the M/O flags)
>
> >>>>> On Thu, 29 Apr 2004 14:50:26 +0900, JINMEI Tatuya
> >>>>> <[EMAIL PROTECTED]> said:
>
> > Hmm, despite the notice, people have started and explored
> the spe
> On Thu, 29 Apr 2004 14:50:26 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> Hmm, despite the notice, people have started and explored the
> specific discussion on which protocols should be specified for the M/O
> flags and how we describe it...
> Please recall such a discussion wil
> On Wed, 28 Apr 2004 12:16:15 -0400,
> Ralph Droms <[EMAIL PROTECTED]> said:
> I think the O flag (if we keep it!) should simply specify DHCPv6, with no
> implication about the way in which DHCPv6 is used.
> "Stateless DHCPv6" is simply a way to use some of the messages from the full
>
> On Thu, 29 Apr 2004 00:29:41 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>>> My point in this message is that IMO we should specify the protocols
>>> corresponding to these flags clearly and concretely, without leaving
>>> any ambiguity (I've changed the subject accordingly.) That
ay, April 28, 2004 12:29 PM
> To: JINMEI Tatuya / çæéå; Tim Chown
> Cc: [EMAIL PROTECTED]
> Subject: RE: the protocols for the M/O flags (Re:
> [rfc2462bis] whether we need the M/O flags)
>
> I think a whole lot of the issue has to do with the
> supposedly mandatory nat
; Subject: Re: the protocols for the M/O flags (Re:
> [rfc2462bis] whether we need the M/O flags)
>
> I think the O flag (if we keep it!) should simply specify
> DHCPv6, with no implication about the way in which DHCPv6 is used.
>
> "Stateless DHCPv6" is simply a wa
Behalf Of Ralph Droms
> Sent: Wednesday, April 28, 2004 11:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: the protocols for the M/O flags (Re:
> [rfc2462bis] whether we need the M/O flags)
>
> Well, picking up the thrown gauntlet - can't resist just this
> once - if the IETF
On Apr 28, 2004, at 9:29 AM, Christian Huitema wrote:
I think a whole lot of the issue has to do with the supposedly
mandatory nature of the M flag, which leads to phrases like "do DHCP,
and only if it fails do auto-config." It would be much simpler to
simply define the flags as "announcing an
On 28-apr-04, at 18:29, Christian Huitema wrote:
We should note that, from a protocol point of view, there is no need
to use the M bit to control stateless address configuration. This
function is already achieved by the "Autonomous flag" in the prefix
information option. If the flag is not set,
Ralph,
While the functions may be independent, wouldn't it be better
if we had a unified set of messages for accessing the functions?
(I'm thinking some sort of hybrid fusion of the RFC2461 ND
and RFC3315 DHCPv6 messages.) Perhaps it is too late in the
game to even consider this...
Fred
[EMAIL PRO
Christian,
On Wed, 2004-04-28 at 09:29, Christian Huitema wrote:
> I think a whole lot of the issue has to do with the supposedly mandatory nature
> of the M flag, which leads to phrases like "do DHCP, and only if it fails do
> auto-config." It would be much simpler to simply define the flags as
Christian - where have you seen phrases like "do DHCP, and only if it fails
do auto-config." They are clearly wrong. SLAAC and DHCPv6 are clearly
independent - a host can use neither, one or the other or both - and are
controlled independently. If that independence is not clear in the specs,
tha
On 28-apr-04, at 12:28, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H(B wrote:
(B
(B> For example, if we leave it ambiguous what is the
(B> protocol that should be invoked by the O flag, we'll see many kinds of
(B> host implementations regarding the protocol; one may invoke the full
(B> DHCPv6 (RFC3
I think a whole lot of the issue has to do with the supposedly mandatory nature of the
(BM flag, which leads to phrases like "do DHCP, and only if it fails do auto-config." It
(Bwould be much simpler to simply define the flags as "announcing an available service",
(Bas in:
(B
(B1) The "M" f
I think the O flag (if we keep it!) should simply specify DHCPv6, with no
implication about the way in which DHCPv6 is used.
"Stateless DHCPv6" is simply a way to use some of the messages from the full
specification in RFC 3315. RFC 3376 is a guideline to the implementation of
DHCPv6 that uses jus
> On Wed, 28 Apr 2004 15:46:02 +0300,
> Markku Savela <[EMAIL PROTECTED]> said:
> I believe DHCP for IPv6 is totally incorrect direction. It's a
> leftover dinosaur from IPv4 way of thinking.
> The whole DHCP6 concept should not have been designed. Instead, the
> effort should have gone
> On Wed, 28 Apr 2004 13:28:11 +0100,
> Tim Chown <[EMAIL PROTECTED]> said:
>> My point in this message is that IMO we should specify the protocols
>> corresponding to these flags clearly and concretely, without leaving
>> any ambiguity (I've changed the subject accordingly.) That is, I
Well, picking up the thrown gauntlet - can't resist just this once - if the
IETF hadn't spent so much time deciding how many spokes to put on all the
wheels being reinvented, we'd have a complete and fully operational set of
specs for a deployable IPv6 service by now.
- Ralph
At 03:46 PM 4/28/20
I believe DHCP for IPv6 is totally incorrect direction. It's a
leftover dinosaur from IPv4 way of thinking.
The whole DHCP6 concept should not have been designed. Instead, the
effort should have gone to extend the standard IPv6 configuration
framework: neighbor discovery.
If configuration is need
On Wed, Apr 28, 2004 at 07:28:39PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
>
> My point in this message is that IMO we should specify the protocols
> corresponding to these flags clearly and concretely, without leaving
> any ambiguity (I've changed the subject accordingly.) That is,
29 matches
Mail list logo
