> 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 May 3, 2004, at 5:59 AM, Bernie Volz wrote:
You can certainly have hosts that always run DHCPv6, or at least policy
settings that would allow it on a host.
Or the opposite... That is, hosts that have a policy to not turn DHCPv6
on
even when receiving O or M.
- Alain.
> Why have hosts needless generate periodic DHCP traffic when
> there is no DHCP server present? True that in DHCPv6 the
> impact is much more minor as multicasting is used (in DHCPv4
> all hosts on the network receive the packets because they are
> broadcast), but it still seems better to me
allow it on a host.
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Soliman Hesham
> Sent: Monday, April 26, 2004 9:55 PM
> To: Alain Durand; IETF IPv6 Mailing List; JINMEI Tatuya /
> Subject: RE: [rfc2462bis] whether
> 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
>
EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Alain Durand
> > Sent: Wednesday, April 28, 2004 2:37 PM
> > To: Tim Chown
> > Cc: IETF IPv6 Mailing List
> > Subject: Re: [rfc2462bis] whether we need the M/O flags
> >
> >
> > On Apr 2
> On Wed, 28 Apr 2004 11:11:11 -0700,
> Alain Durand <[EMAIL PROTECTED]> said:
>> Hmm, this message of yours seems to have been sent just after my
>> latest one...so, please let me confirm your intention. Can you or
>> can't you live with my revised proposal (attached below)?
> see prop
> 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
DHCPv6 is secure read the spec.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Alain Durand
> Sent: Wednesday, April 28, 2004 2:37 PM
> To: Tim Chown
> Cc: IETF IPv6 Mailing List
> Subject: Re: [rfc2462bis] whether
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 Apr 27, 2004, at 2:21 AM, Tim Chown wrote:
On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote:
Let me try to explain why I, as an implementor, do not like the M/O
bits very much.
...
Alain,
Could you explain how the functionality of the O/M bits will be
replaced
within the ND/etc pr
(B (BOn Apr 27, 2004, at 11:49 PM, JINMEI Tatuya / (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (BOk, thanks for the clarification. IMHO, it is not OK (Bto keep (B (Bthe document as DS with O&M given the general lack of implementation. (B (B (B (BHmm, this message of yours seems to have be
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,
Note: I'm responding to an old message not to restart the
"deprecation" discussion, but to make progress on how we can clarify
the things about these flags, assuming we have agreed on keeping them.
My point in this message is that IMO we should specify the protocols
corresponding to these flags cl
> On Tue, 27 Apr 2004 09:06:06 -0700,
> Alain Durand <[EMAIL PROTECTED]> said:
>> I would first like to be sure if it is okay to recycle the document as
>> DS even with the lack of implementation on a part of the protocol
>> description (in this case, the receiving side of the M flag),
>>
On Apr 27, 2004, at 2:39 AM, Iljitsch van Beijnum wrote:
Now at present, it doesn't support DHCPv6. But suppose in the next
version of my favorite OS DHCPv6 is supported, and I decide I want to
run it. So far so good. But if I now take my laptop to a place where
there is no DHCPv6 server, I eit
(B (BOn Apr 26, 2004, at 11:29 PM, JINMEI Tatuya / (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (BI would first like to be sure if it is okay to recycle the (Bdocument as (B (BDS even with the lack of implementation on a part of the protocol (B (Bdescription (in this case, the receiving side
> On Tue, 27 Apr 2004 06:21:24 -0400,
> Brian Haberman <[EMAIL PROTECTED]> said:
> As a I stated in an earlier message, I believe it is okay to recycle
> at DS given the granularity of detail in the interoperability reports.
> http://www.ietf.org/IESG/Implementations/nd-auto-implementatio
I fully agree with the chair's decision to leave the M/O bits unchanged
for now.
I would like to quickly address (comments inline) the security argument
that was raised by Alain.
Alain,
> It is not that DHCPv6 cannot be made secure, it is that the M/O bits are
> an automatic and insecure way to
JINMEI wrote:
On Mon, 26 Apr 2004 22:28:05 -0700,
Alain Durand <[EMAIL PROTECTED]> said:
My biggest question is: can we recycle rfc2462bis as DS despite fact
3?
I failed to see what is wrong with the unused feature elimination
Christian described
when moving along the standard track.
Not
Alain Durand wrote:
On Apr 26, 2004, at 2:50 PM, Brian Haberman wrote:
At this time, the chairs believe that there is code that
sets the M&O bits and at least one implementation that reads and acts
on these bits.
This is certainly not enough to claim interoperability.
No one is claiming inte
On 26-apr-04, at 22:53, Alain Durand wrote:
It is not that DHCPv6 cannot be made secure, it is that the M/O bits
are
an automatic and insecure way to trigger an external configuration
mechanism.
So you object to the security level of DHCPv6 rather than that of the
M and O bits?
You should rea
On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote:
> Let me try to explain why I, as an implementor, do not like the M/O
> bits very much.
> ...
Alain,
Could you explain how the functionality of the O/M bits will be replaced
within the ND/etc protocols? Or should they not be replaced
> On Mon, 26 Apr 2004 22:28:05 -0700,
> Alain Durand <[EMAIL PROTECTED]> said:
> My biggest question is: can we recycle rfc2462bis as DS despite fact
> 3?
> I failed to see what is wrong with the unused feature elimination
> Christian described
> when moving along the standard track.
No
On Apr 26, 2004, at 10:02 PM, S. Daniel Park wrote:
To give a hint that DHCPv6 is present?
Don't you consider this useful?
I have no hard stance whether to remove M&O bits
or not at this stage, however if we remove it, I
guess somebody will sporadically define similar
flags into the RA repeatly so
(B (BOn Apr 26, 2004, at 10:09 PM, JINMEI Tatuya / (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (B (BMy biggest question is: can we recycle rfc2462bis as DS (Bdespite fact (B (B3? (B (B (B (BI failed to see what is wrong with the unused feature elimination (BChristian described (B (Bwh
> On Mon, 26 Apr 2004 17:28:02 -0700,
> Alain Durand <[EMAIL PROTECTED]> said:
>> At this time, the chairs believe that there is code that
>> sets the M&O bits and at least one implementation that reads and acts
>> on these bits.
> This is certainly not enough to claim interoperability.
> >> To give a hint that DHCPv6 is present?
> >
> > Don't you consider this useful?
I have no hard stance whether to remove M&O bits
or not at this stage, however if we remove it, I
guess somebody will sporadically define similar
flags into the RA repeatly so as to perform that
kind of operatio
ilto:[EMAIL PROTECTED]
(B > Behalf Of Alain Durand
(B > Sent: Monday, April 26, 2004 1:14 PM
(B > To: IETF IPv6 Mailing List; JINMEI Tatuya / ????
(B > Subject: Re: [rfc2462bis] whether we need the M/O flags
(B >
(B >
(B > Let me try to explain why I, as an implementor, do n
On Apr 26, 2004, at 2:50 PM, Brian Haberman wrote:
At this time, the chairs believe that there is code that
sets the M&O bits and at least one implementation that reads and acts
on these bits.
This is certainly not enough to claim interoperability.
- Alain.
JINMEI wrote:
On Sat, 24 Apr 2004 22:08:28 -0700,
"Christian Huitema" <[EMAIL PROTECTED]> said:
Some people commented that we needed to clarify what's bad with the
M/O flags if we want to deprecate (or remove) them.
(folding a long line)
The normal IETF practice is that when a document pr
On Apr 26, 2004, at 1:10 PM, Iljitsch van Beijnum wrote:
On 26-apr-04, at 19:14, Alain Durand wrote:
Let me try to explain why I, as an implementor, do not like the M/O
bits very much.
It is not that DHCPv6 cannot be made secure, it is that the M/O bits
are
an automatic and insecure way to tri
On 26-apr-04, at 19:14, Alain Durand wrote:
Let me try to explain why I, as an implementor, do not like the M/O
bits very much.
It is not that DHCPv6 cannot be made secure, it is that the M/O bits
are
an automatic and insecure way to trigger an external configuration
mechanism.
So you object t
Let me try to explain why I, as an implementor, do not like the M/O
bits very much.
It is not that DHCPv6 cannot be made secure, it is that the M/O bits are
an automatic and insecure way to trigger an external configuration
mechanism.
The are security implication for the hosts in implementing t
> Baseline is, it would be good to postpone the deprecation discussion and
(B> at the same time update the definition of the use of the M/O bits. I can
(B> think of scenarios where M/O is useful but the mental picture of these
(B> is not clear enough yet to really make a point. Deciding upon
(
> (Note: In this message, I'm basically speaking just as an individual
> in this list. I'll propose an action as a 2462bis editor after the
> entire discussion; it may or may not be same as what I'm going to say
> below)
I think your approach to look at the two sides of the medal is very
useful, b
> On Sat, 24 Apr 2004 22:08:28 -0700,
> "Christian Huitema" <[EMAIL PROTECTED]> said:
>> >> Some people commented that we needed to clarify what's bad with the
>> >> M/O flags if we want to deprecate (or remove) them.
(folding a long line)
> The normal IETF practice is that when a docum
> >> Some people commented that we needed to clarify what's bad with the
(B> >> M/O flags if we want to deprecate (or remove) them.
(B
(BThe normal IETF practice is that when a document progresses from PS do DS and then to
(Bstandard, parts of the specification that are not actually present in
On 24-apr-04, at 7:46, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H(B wrote:
(B
(B>> You only discuss "what would break if we deprecate these flags". I
(B>> have
(B>> no problems with the text that follows, but I DO have a very big
(B>> problem with changing these flags. You can't just go around a
> On Fri, 23 Apr 2004 23:24:19 +0200,
> Iljitsch van Beijnum <[EMAIL PROTECTED]> said:
>> Some people commented that we needed to clarify what's bad with the
>> M/O flags if we want to deprecate (or remove) them.
> You only discuss "what would break if we deprecate these flags". I have
(BAs a general comment, IMHO we're wasting cycles on this
(Bdiscussion and I agree with Iljitsch's email on this.
(BSpecific comments below
(B
(B
(B > Some people commented that we needed to clarify what's bad with the
(B > M/O flags if we want to deprecate (or remove) them. That's a fair
On 23-apr-04, at 17:05, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H(B wrote:
(B
(B> Some people commented that we needed to clarify what's bad with the
(B> M/O flags if we want to deprecate (or remove) them.
(B
(BYou only discuss "what would break if we deprecate these flags". I have
(Bno proble
7;B?A
Cc: [EMAIL PROTECTED]
Subject: Re: [rfc2462bis] whether we need the M/O flags
Jinmei,
I agree with your analysis, except that I'm not so much worried about
breaking somebody's assumption in designing an hypothetical client
dealing with the O/M bits. The definition of those bits
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alain
Durand
Sent: Friday, April 23, 2004 11:19 AM
To: JINMEI Tatuya / ?_-?'B?A
Cc: [EMAIL PROTECTED]
Subject: Re: [rfc2462bis] whether we need the M/O flags
Jinmei,
I agree with your analysis, except that I'm n
Jinmei,
I agree with your analysis, except that I'm not so much worried about
breaking somebody's assumption in designing an hypothetical client
dealing with the O/M bits. The definition of those bits was obscure
in 2462 anyway.
I would be more worried if this was to result in demonstrated
operat
Hi Jinmei,
(B
(B
(B> Now let's think about cons of deprecating these flags.
(B>
(B> The obvious one is that this action may break existing
(B> implementations. In fact, this is the most typical objection I've
(B> seen in this thread.
(B
(BI'd like to withdraw my original objection to thi
> On Thu, 15 Apr 2004 20:40:14 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> As I just said in a separate message, one big question had been raised
> about rfc2462bis. It was, in my understanding,
> whether we need the M/O flags for the "stateful" protocol(s) in the
> first pl
> On Fri, 16 Apr 2004 02:10:29 -0400,
> "Soliman Hesham" <[EMAIL PROTECTED]> said:
>> One thing we may have to care, however, is that the lack of
>> implementation might be a barrier of recycling the spec as a
>> DS, since
>> we'd need to show interoperable implementations.
> => Good po
On 15-apr-04, at 17:13, Tim Hartrick wrote:
I don't know of any implementations which depend on these bits for
DHCPv6 invocation or termination. That doesn't mean that none exist.
Also, the whole "other config" issue is still very much in a state of
flux. Since those mechanisms haven't been defi
(B
(B > One thing we may have to care, however, is that the lack of
(B > implementation might be a barrier of recycling the spec as a
(B > DS, since
(B > we'd need to show interoperable implementations.
(B
(B=> Good point. It would be good to get some clarification on whether
(Bthis is an
> On 15 Apr 2004 08:13:33 -0700,
> Tim Hartrick <[EMAIL PROTECTED]> said:
>> Just out of curiosity, what exactly do you mean by "running, shipping
>> code that makes use of these bits." In particular, are you referring
>> to particular implementations that
>>
>> - invoke DHCPv6 on the r
(B
(B > I think that deprecating the O & M bits will be good.
(B > I'm not too worried about incompatibility, as most code
(B > do not support those bits anyway.
(B
(B=> I'm sorry, "most" is not good enough. If there is one implementation
(Bthat supports it then we have _no_ right to do th
Jinmei,
>
> > I believe that it is entirely too late in the life of this protocol
> > to be removing these bits. If there is in fact confusion over their usage
> > then the usage should be clarified. The original intent of this revision was
> > to clarify portions of the specification whi
> On Thu, 15 Apr 2004 12:08:44 -0700 (PDT),
> Tim Hartrick <[EMAIL PROTECTED]> said:
> I believe that it is entirely too late in the life of this protocol
> to be removing these bits. If there is in fact confusion over their usage
> then the usage should be clarified. The original
Ok, what would break if we were to declare the O & M bit historic
and issue a BCP recommending not to set them in RA?
It is unclear to me what part of existing code would break
- Alain.
On Apr 15, 2004, at 12:08 PM, Tim Hartrick wrote:
I believe that it is entirely too late in the life of t
All,
I believe that it is entirely too late in the life of this protocol
to be removing these bits. If there is in fact confusion over their usage
then the usage should be clarified. The original intent of this revision was
to clarify portions of the specification which were not clear
I am not sure whether this is a deficiency in this model. Currently,
even if M/O is turned off, the nodes which had triggered stateful
protocol will continue using it. Unless or otherwise you reboot all the
nodes in the link, you cannot make the nodes to switch to stateless
autoconf. This could be
On Apr 15, 2004, at 10:14 AM, Alain Durand wrote:
A good design is not one where there is no extra feature to remove,
not one where there is no new feature to add.
This of course should read:
A good design is one where there is no extra feature to remove,
not one where there is no new feature to
I think that deprecating the O & M bits will be good.
I'm not too worried about incompatibility, as most code
do not support those bits anyway. Also, it is mostly an
operational issue. All we need to do is to publish
a BCP saying essentially: "Do not set the O & M bits in RA"
and we are done.
In t
At 08:40 PM 4/15/2004 +0900, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
[...] As far as I know, no host implementation supports the M flag.
Regarding the O flag, I've implemented the host side of the flag,
which invokes a DHCPv6 client upon receiving an RA with the O bit.
But I'
(B
(B > > FWIW, I really think that there is no point in going round
(B > and round again
(B > > in this discussion when there is no harm done by keeping them.
(B > > Removing them is not backward compatible for 2461 anyway.
(B > > So I recommend we leave them as defined.
(B >
(B > I s
> On Thu, 15 Apr 2004 08:49:53 -0400,
> "Soliman Hesham" <[EMAIL PROTECTED]> said:
>> As I just said in a separate message, one big question had
>> been raised
>> about rfc2462bis. It was, in my understanding,
> => The question you raise affects 2461 and as a consequence it affects 24
Hi all,
(B
(B> > As I just said in a separate message, one big question had been raised
(B> > about rfc2462bis. It was, in my understanding,
(B>
(B> => The question you raise affects 2461 and as a consequence it affects 2462.
(B> FWIW, I really think that there is no point in going round
(B
(B > As I just said in a separate message, one big question had
(B > been raised
(B > about rfc2462bis. It was, in my understanding,
(B
(B=> The question you raise affects 2461 and as a consequence it affects 2462.
(BFWIW, I really think that there is no point in going round and round
88 matches
Mail list logo
