Hello,
I've noticed that the latter of Section 7.2.5 of 2461bis was improved
very much in the 02 version:
===
If the target's Neighbor Cache entry is in any state other than
INCOMPLETE when the advertisement is received,
Sure, this is fine with me. Will add it to the next rev.
(B
(BHesham
(B
(B -Original Message-
(B From: [EMAIL PROTECTED]
(B [mailto:[EMAIL PROTECTED]
(B Sent: Wednesday, April 27, 2005 4:21 AM
(B To: Soliman, Hesham
(B Cc: ipv6@ietf.org
(B Subject: Forward: Re: IPv6 WG
On Tue, 15 Feb 2005, Erik Nordmark wrote:
So I'd suggest adding a sentence at the start of the second paragraph:
This specification has no explicit support for hosts to perform
inbound load balancing.
and rewording the rest to start with
Routers can perform inbound load
[EMAIL PROTECTED])
To: Erik Nordmark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; IPv6 WG ipv6@ietf.org; Pekka Savola
[EMAIL PROTECTED]
Sent: Saturday, February 12, 2005 1:40 AM
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt
Catching up a possibly minor point of an old thread...
On Thu
Sent: Friday, February 11, 2005 3:11 PM
(B To: Erik Nordmark
(B Cc: Pekka Savola; Soliman, Hesham; IPv6 WG
(B Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt
(B
(B
(B Catching up a possibly minor point of an old thread...
(B
(B On Thu, 13 Jan 2005 10:39:15 -0800
Catching up a possibly minor point of an old thread...
On Thu, 13 Jan 2005 10:39:15 -0800 (PST),
Erik Nordmark [EMAIL PROTECTED] said:
== AFAICS, you can remove 'both the Override flag is clear and' here,
because the same result happens if the Override flag is set.
No. The but do not
Pekka, all,
Sorry for the delay in resolving this but there were too many comments
and too little time! Seems like most of your comments were clearly addressed
by me or other people on the list and most are being put in the next rev
(thanks).
But I'm going to address the unresolved ones so
Jinmei,
On Thu, 2005-01-13 at 21:48, JINMEI Tatuya / wrote:
BTW: do we really need this level of detailed inspection to meet the
two-implementation requirement for a DS? When I raised a similar
question when we discussed how we should deal with the M/O flags in
rfc2462bis wrt this
[This got stuck in my outbox]
- a time that decrements in real time,
that is, one that will result in a
Lifetime of zero at the specified
time in the future,
On Thu, 13 Jan 2005, Erik Nordmark wrote:
A proxy MAY multicast Neighbor Advertisements when its link-layer
address changes or when it is configured (by system management or
other mechanisms) to proxy for an address. If there are multiple
nodes that are providing proxy services
On Tue, 14 Dec 2004, Pekka Savola wrote:
I went through one implementation and have a couple of additional
comments wrt suitability for DS/clarify.
1) section 6.2.5: when AdvSendAdvertisements changes to FALSE, you
SHOULD send a final RA with zero Router Lifetime.
At least a couple of
== 'or the source chooses to ignore unauthenticated Redirect
messages' smells quite a bit from a leftover of IPsec
AH times. Reword?
Can't SeND nodes choose to ignore redirects that aren't
protected by SeND?
Sure. I was just referring this editorially, that
Pekka Savola wrote:
It is an odd SHOULD in that it doesn't add a requirement on
implemetors of
ND, but instead states a requirement on some potential other protocol
which
uses proxy NAs.
But I do think that MIPv6 is an example of this. Even with multiple
Home Agents
on the same home link, MIPv6
Hi Pekka,
On Thu, 13 Jan 2005, Pekka Savola wrote:
...snipped...
That approach is correct, but beacause the two hour rule applies to
the on-link prefixes, it's not immediately.
Not really. This two hour minimum applies only to stateless autoconf.
Cheers
Suresh
On Thu, 13 Jan 2005 10:39:15 -0800 (PST),
Erik Nordmark [EMAIL PROTECTED] said:
- a time that decrements in real time,
that is, one that will result in a
Lifetime of zero at the specified
time in the future, or
- a fixed time that stays the same in
consecutive advertisements.
==
On Fri, 14 Jan 2005, JINMEI Tatuya / [ISO-2022-JP] ¿ÀÌÀãºÈ wrote:
BTW: do we really need this level of detailed inspection to meet the
two-implementation requirement for a DS?
That is a matter of interpretation. Traditionally, the ADs have not
required them, but personally I think the spirit of
Hi Jinmei,
(B
(B BTW: do we really need this level of detailed inspection to meet the
(B two-implementation requirement for a DS? When I raised a similar
(B question when we discussed how we should deal with the M/O flags in
(B rfc2462bis wrt this requirement, I was told that we usually only
Inline..
On Sat, 18 Dec 2004, Soliman, Hesham wrote:
substantial
---
== this spec needs at least an IANA Considerations section,
stating at
least:
1) the allocation guidelines for ND option types/codes
(Standards Action?
IETF Consensus?)
2) that no IANA action is required
On Dec 22, 2004, at 15:07, Pekka Savola wrote:
Inline..
On Sat, 18 Dec 2004, Soliman, Hesham wrote:
substantial
---
== this spec needs at least an IANA Considerations section,
stating at
least:
1) the allocation guidelines for ND option types/codes
(Standards Action?
IETF
Pekka,
Thanks for the comments.
My response inline. If I don't address a comment below, it means
I have no problem updating the draft with the comment.
Others please take a look and voice opinions if you have them.
We should try to make this LC have a deadline :)
substantial
---
Pekka,
At 12:40 AM 12/15/2004, Pekka Savola wrote:
On Tue, 14 Dec 2004, Pekka Savola wrote:
In short, this still needs at least one revision. Jinmei also had some
O/M/DHCPv6 consistency issues which probably need to be addressed. There
is some specification which I don't think has been
On Tue, 14 Dec 2004, Pekka Savola wrote:
In short, this still needs at least one revision. Jinmei also had some
O/M/DHCPv6 consistency issues which probably need to be addressed. There is
some specification which I don't think has been implemented and should be
removed unless anyone jumps up.
On Mon, 1 Nov 2004, Brian Haberman wrote:
This begins a 2 week IPv6 working group last call on recycling:
Title : Neighbor Discovery for IP version 6 (IPv6)
Author(s) : T. Narten, et al.
Filename: draft-ietf-ipv6-2461bis-01.txt
Pages :
Thanks for the comments.
(B
(B
(B at Draft Standard. Substantive comments should be directed to
(B the mailing list. Editorial comments can be sent to the document
(B editor. This last call will end on 11/15/2004.
(B
(B I've not gone through the entire document (it's so
at Draft Standard. Substantive comments should be directed to
the mailing list. Editorial comments can be sent to the document
editor. This last call will end on 11/15/2004.
I've not gone through the entire document (it's so huge...), but I'd
like to make some points at this
On Mon, 1 Nov 2004 09:43:39 -0500,
Brian Haberman [EMAIL PROTECTED] said:
This begins a 2 week IPv6 working group last call on recycling:
Title : Neighbor Discovery for IP version 6 (IPv6)
Author(s) : T. Narten, et al.
Filename:
All,
This begins a 2 week IPv6 working group last call on recycling:
Title : Neighbor Discovery for IP version 6 (IPv6)
Author(s) : T. Narten, et al.
Filename: draft-ietf-ipv6-2461bis-01.txt
Pages : 86
Date:
27 matches
Mail list logo
