I share your concern about mandating the implementation of a possibly
extraneous state variable. Perhaps replacing your suggested text:
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
into ManagedFlag, which
Christian Huitema wrote:
>>> On receipt of a valid Router Advertisement (as defined in
>>> [DISCOVERY]), a host copies the value of the advertisement's M bit
>>> into ManagedFlag, which saves the mostly recently received value of
>>> the M bit. The details of how the host us
James,
At 02:40 PM 5/18/2004, James Kempf wrote:
Is there an RFC or a technical document somewhere with a concise, bulleted
list of technical differences between IPv6 and IPv4?
There is a short list in the introduction section of RFC2460 "Internet
Protocol, Version 6 (IPv6) Specification". There
> I'm certainly not implying any API.
> Why do you think the text with the forward reference to "a separate
> document"
> implies any API?
The forward reference is asking the implementers to manage an extraneous state
variable. As far as ND is concerned, the host can be enti
Is there an RFC or a technical document somewhere with a concise, bulleted
list of technical differences between IPv6 and IPv4?
jak
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: ht
> Well, I for one would rather leave the entire handling of the Managed flag
> to the to-be-written RFC. I see the point of assuming that the flag will be
> visible through some kind of API for the DHCPv6 process, but I would rather
> not build a dependency to another document.
I'm certainly not
> >Better. But how about also stating that it might be useful to detect
> >when the flag values change. For instance,
> > On receipt of a valid Router Advertisement (as defined in
> > [DISCOVERY]), a host copies the value of the advertisement's M bit
> > into ManagedFlag, wh
Erik - your proposed text looks good to me...
- Ralph
At 10:23 AM 5/18/2004 -0700, Erik Nordmark wrote:
Better. But how about also stating that it might be useful to detect
when the flag values change. For instance,
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a h
> > Loosing the above setence means that implementations might not
> ^^^ you meant "Losing" here, didn't you?
Yes.
(I'm assuming we'll have a separate document to describe the details.
But if we cannot agree on this path, we'll need to revise the proposed
text above accordingly.)
That assu
Jinmei/Brian,
I agree with Brian's comments. RFC 3587 is very clear that unless the first
three bits of the address are set to 0, the interface id is required to be
64 bits. So there should be no conflict.
jak
- Original Message -
From: "Brian E Carpenter" <[EMAIL PROTECTED]
JINMEI Tatuya wrote:
> [Note: if you've forgotten the discussion, please first refer to the
> following URL (and its followups if necessary):
> https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ]
>
> In this message, I pointed out that there might be possible conflict
> b
No opinions, so I'll adopt the resolution of "do nothing" as
I proposed on the list, and close this issue.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ip
No opinions, so I'll adopt the resolution of "do nothing" as
I proposed on the list, and close this issue.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ip
[Note: if you've forgotten the discussion, please first refer to the
following URL (and its followups if necessary):
https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ]
In this message, I pointed out that there might be possible conflict
between the IPv6 address architec
Yes - mobility (and DNAv6?) would be good topics for a BCP doc...
- Ralph
At 11:52 AM 5/18/2004 +0100, Tim Chown wrote:
On Tue, May 18, 2004 at 06:32:26AM -0400, Ralph Droms wrote:
> Your list of behaviors is a good starting point for a BCP document. As you
> point out, if we know there is rough c
Regarding the last paragraph of suggested text:
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
into ManagedFlag. If the value of ManagedFlag changes from FALSE to
TRUE, it indicates DHCPv6 becomes available fo
Christian Huitema wrote:
The downside with speculative text is that it creates a weak spot in the
RFC. Ask yourself how much of the text will still be valid in 5 years,
when have more operation experience. The normative text will probably
still be, but there is a high likelihood that the speculati
On Tue, May 18, 2004 at 06:32:26AM -0400, Ralph Droms wrote:
> Your list of behaviors is a good starting point for a BCP document. As you
> point out, if we know there is rough consensus in support of writing such a
> doc, RFC 2462bis can proceed without explicit prescription of client
> behavior
> [EMAIL PROTECTED] - Mon Feb 09 06:37:31 2004]:
>
> Proposed Resolution (revised): revise the latter part of
> Section 5.4.2 as follows:
The proposed change was incorporated in the latest draft (00),
and I've not seen any objections to it. I now conclude
everyone is fine with the resolution and
> [EMAIL PROTECTED] - Mon Feb 09 06:37:31 2004]:
>
> Proposed Resolution (revised): revise the latter part of
> Section 5.4.2 as follows:
The proposed change was incorporated in the latest draft (00),
and I've not seen any objections to it. I now conclude
everyone is fine with the resolution and
Your list of behaviors is a good starting point for a BCP document. As you
point out, if we know there is rough consensus in support of writing such a
doc, RFC 2462bis can proceed without explicit prescription of client behavior.
I remember (my memory, of course, may be faulty) that the behavior o
At 06:00 PM 5/17/2004 -0700, Erik Nordmark wrote:
> I think Jinmei-san suggested deleting the whole notion of an
> internal-to-the-implementation ManagedFlag and OtherConfigFlag. I
> extrapolated from that suggestion that the host would (in a stateless way)
> base its behavior on the most recently
Hi, all.
I found a problem in RFC2460, about error processing of Routing Header.
It does not define the behavior of End Node when the End Node received
the packet which has odd Hdr.Ext.Len.
(Section 4.4)
>A Routing header is not examined or processed until it reaches the
>node identified
Christian,
> When writing standards, less is more. If we are not sure about
> something, it is probably better to just leave it out.
yes, I agree with you. That's why I suggested to use the text only if
the "may"s as Tim suggested seem to be an appropriate choice. But I see
your point in leaving t
> Let me check...this should apply to the current RFC2462, shouldn't it?
> I'm not sure why you are making this point in this context...
No, I was referring to your suggestion of writing a document (standard
or BCP) about the details of the protocol interaction which I believe is
a good idea becaus
> On Tue, 18 May 2004 09:09:16 +0200,
> "Christian Strauf (JOIN)" <[EMAIL PROTECTED]> said:
>> - how a host that implements DHCPv6 should behave. The host would
>> have an internal (conceptual) variable, controlling the policy about
>> autoconfiguration, which should have at least three
> Of course there are other ways of reacting to M/O flags that switch to
> unflagged but I think that the above behaviour is reasonable.
The problem with this approach is that it is speculative. The text is
not particularly wrong, but other behaviors may also make sense, e.g.
sticking to the leas
> - how a host that implements DHCPv6 should behave. The host would
> have an internal (conceptual) variable, controlling the policy about
> autoconfiguration, which should have at least three values:
> 1: it should invoke DHCPv6 for address autoconfiguration regardless
> of the content
> On Mon, 17 May 2004 09:18:23 -0700 (PDT),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> - remove "requirement" sentences like the following one
>> If the value of ManagedFlag changes from FALSE to TRUE,
>> and the host is not already running the stateful address
>> autoconfiguration prot
> On Mon, 17 May 2004 18:00:48 -0700 (PDT),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> I think Jinmei-san suggested deleting the whole notion of an
>> internal-to-the-implementation ManagedFlag and OtherConfigFlag. I
>> extrapolated from that suggestion that the host would (in a statel
30 matches
Mail list logo
