Pekka,
On Aug 31, 2006, at 6:18 AM, Pekka Savola wrote:
On Thu, 31 Aug 2006, Ralph Droms wrote:
Suresh - I think Jinmei-san and I have come to agreement on
replacement text
in section 2.4 (see below).
As a WG participant, if we want to go ahead with the change, I'd
expect WG chairs to is
James Kempf wrote:
I think the proposal was not to keep the router information until it was
explicitly invalidated but rather that the host could individually
solicit prior to the expiration of the lifetime. The router information
state is still soft state, its just that the renewal is differe
A good friend likes to use an anecdote about ignoring advice.
At the top of Yosemite Falls, there a sign that says: "Do not
go beyond this point or YOU WILL DIE" (by falling 3000ft to
the base of the falls below). Sadly, many people have done
just that. Its not about laws; its about common sense.
>> A good friend likes to use an anecdote about ignoring advice.
>> At the top of Yosemite Falls, there a sign that says: "Do not
>> go beyond this point or YOU WILL DIE" (by falling 3000ft to
>> the base of the falls below). Sadly, many people have done
>> just that. Its not about laws; its about
I don't think that analogy is quite accurate, from an official, RFC 2119
standards language viewpoint.
Saying something is default is like saying "You shouldn't go beyond this
point because there is a possibility of a life threatening situation".
Saying "this MUST not be done" is like saying
Like I said, unless the RFC says "MUST", your milage may vary. People often
have all kinds of reasons to ignore recommendations that aren't required.
jak
- Original Message -
From: "Templin, Fred L" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>; "Julien Laganier"
What would you expect from implementations that ignore the
default behavior specified in the RFCs and ignore the advice
they receive in the form of PIOs with 'L' set to 0 in RAs?
I believe that hosts should be intelligent, but not to the
point that they presume they know better than what the
netwo
No, but I think it would be worthwhile to find out what real implemenations
do. Unless an IETF standard has specific RFC 2119 languge in it, your milage
can vary.
jak
- Original Message -
From: "Templin, Fred L" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>; "Ju
> (removing other WGs than NETLMM)
>
>> The default behavior (see
>> Section 5.2) when sending a packet to an address for which no
>> information is known about the on-link status of the address is to
>> forward the packet to a default router;
>>
>> i.e. send packets to the default router.
Basavaraj Patil <[EMAIL PROTECTED]> writes:
> Ignoring cellular hosts for a moment, how are periodic RAs useful for any
> host?
They are part of the basic RS/RA reliability mechanism. Instead of
having hosts periodically poll routers, routers periodically send out
RAs. You need one or the other (
1) Is there an issue with multicast RAs vs. unicast RAs? I.e., would
it help if the RAs were unicast rather than multicast? (Or is there
no true unicast in the networks we are talking about). My
assumption is that use of IP multicast is not an issue here, since
no one has suggested this.
Having just gone through this entire thread, some questions.
1) Is there an issue with multicast RAs vs. unicast RAs? I.e., would
it help if the RAs were unicast rather than multicast? (Or is there
no true unicast in the networks we are talking about). My
assumption is that use of IP mult
Maybe I'm confused, but I don't see what L=0 really means. If ADDRCONF
assigns the prefix to the interface, then the prefix is on link for at least
one node, the node that configured the interface with the prefix. I suppose
one could argue that, even if that node considered the prefix on link, t
In addition to what Julien said, (RFC2461, Section 6.3.4)
also says:
"Prefixes with the on-link flag set to zero would normally
have the autonomous flag set and be used by [ADDRCONF]."
and ([ADDRCONF], Section 5.5.3) looks only at the 'A' bit
for address configuration. Hosts use prefixes wi
Pekka - the discussion has already occurred on the ipv6 WG mailing list and
we have consensus on replacement text. I don't see a need to further waste
the WG's time with additional discussion in a WG last call now that the
interested parties have already come to consensus.
I didn't say the text i
I agree with this resolution.
Fred
[EMAIL PROTECTED]
-Original Message-
From: Ralph Droms [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 31, 2006 5:36 AM
To: Suresh Krishnan
Cc: ipv6@ietf.org; Templin, Fred L; [EMAIL PROTECTED]; JINMEI Tatuya / 神明達哉
Subject: Re: DHCP for privacy addr
> If the text has little relevance, then I don't see why it needs to change.
The current text in (RFC3041(bis), Section 2.4, paragraph 1) is inaccurate as
discussed earlier in this thread.
Fred
[EMAIL PROTECTED]
IETF IPv6 worki
On Thu, 31 Aug 2006, Ralph Droms wrote:
Pekka - I would agree if the text in question were a key component of the
protocol specification. But, because this text is background material and
the discussion has been conducted on the WG mailing list, I don't think a
last call is warranted for this te
Erik,
I think the proposal was not to keep the router information until it was
explicitly invalidated but rather that the host could individually solicit
prior to the expiration of the lifetime. The router information state is
still soft state, its just that the renewal is different. 2641 expl
Pekka - I would agree if the text in question were a key component of the
protocol specification. But, because this text is background material and
the discussion has been conducted on the WG mailing list, I don't think a
last call is warranted for this text.
Of course, there may be other changes
On Thu, 31 Aug 2006, Ralph Droms wrote:
Suresh - I think Jinmei-san and I have come to agreement on replacement text
in section 2.4 (see below).
As a WG participant, if we want to go ahead with the change, I'd
expect WG chairs to issue a last call of some sort for the changes
(giving a good m
Suresh - I think Jinmei-san and I have come to agreement on replacement text
in section 2.4 (see below).
- Ralph
On 8/31/06 2:21 AM, "JINMEI Tatuya / 神明達哉"
<[EMAIL PROTECTED]> wrote:
>> On Fri, 25 Aug 2006 06:13:17 -0400,
>> Ralph Droms <[EMAIL PROTECTED]> said:
>
>> I'm sorry for intr
Hi James,
Just for clarification.
On Thursday 24 August 2006 20:04, James Kempf wrote:
> Fred,
>
> I don't think this quite captures the situation.
>
> [...]
>
> Secondly, exactly what is meant by 'L=0' is underspecified by RFC
> 2461. I think everyone agrees with 'L=1' means, that the prefix is
> On Fri, 25 Aug 2006 06:18:06 -0400,
> Ralph Droms <[EMAIL PROTECTED]> said:
>>> I recommend removing section 2.2 (as I did in the earlier post cited
>>> by Suresh), as experience with IPv4 addressing has little bearing on
>>> IPv6. This observation is bolstered by the text in section 2
24 matches
Mail list logo
