On Feb 27, 2004, at 5:23 PM, Thomas Narten wrote:
Let me ask you this then. If the word "permanent" is not appropriate,
what word is? To me, "not permanent" means that at some future time an
allocation that has been made to an endsite may be revoked.
The point I'm arguing is that it is not the IETF
Nick 'Sharkey' Moore wrote:
- When configuring a global unicast address, the link-local
address with the same suffix as that address MUST be configured
and tested for uniqueness in order to maintain interoperability
with RFC2462 behaviour.
I think that configuring additional addresses wh
Alain,
> Specifically, the part I object to are:
> - under the FD00::/8 prefix (Locally assigned):
> using the 'all zero' pattern instead of random bits would have the
> exact same effect
>as using the 'site local' address: it would create ambiguous
> addresses. The ipv6
>wg spend o
>Dear ADs, consider this mail as my second step in the appeal chain.
>
>Specifically, the part I object to are:
>
>- under the FD00::/8 prefix (Locally assigned):
>using the 'all zero' pattern instead of random bits would have the
>exact same effect
> as using the 'site local' address: it wo
On Feb 24, 2004, at 10:48 AM, Brian Haberman wrote:
Alain,
At 01:22 AM 2/20/2004, Alain Durand wrote:
Dears ADs,
Since the appeal process starts with the working group chairs, we
are responding as such.
I found it very unfortunate that the chair decided to request to
advance this document
witho
> Which one is correct? Is the length of IF IDs determined by the link
> type, or the address format, or both? If the answer is "both", there
> may be inconsistency in future specification. For example, what if a
> future IPv6-over-FOO document specifies like this?
>
>An IPv6 address prefix
> However, I think the receiving node should still consider the prefix
> as valid in terms of ND (i.e., consider it as "on-link") and modify
> the next-hop determination accordingly.
>
> The questions are:
>
> 1. is this a correct understanding of the intention of RFC2461?
> 2. if yes, is this a
On Fri, 27 Feb 2004, Jun-ichiro itojun Hagino wrote:
> > I've been thinking about this issue for a while. Currently, I'm not
> > sure if we need to do something in rfc2462bis for this issue.
> (snip)
> > Please someone clarify this point. Then I'll consider what is
> > necessary for rfc2462bis (o
> I've been thinking about this issue for a while. Currently, I'm not
> sure if we need to do something in rfc2462bis for this issue.
(snip)
> Please someone clarify this point. Then I'll consider what is
> necessary for rfc2462bis (or whether we need to do something in the
> first place) for thi
(note: this is a long message.)
One major open issue of rfc2462bis is semantics of the M/O bit,
what "stateful configuration" means, etc.
Ralph Droms raised a set of questions in March 2003:
a. the text needs to be updated to use RFC 2119 keywords
b. which keywords?
c. what is "the stateful conf
I've been thinking about this issue for a while. Currently, I'm not
sure if we need to do something in rfc2462bis for this issue.
I originally thought RFC2462 had some sort of assumption that an
interface identifier is 64 bits long at least for some cases.
Looking at RFC2462 again, however, I've
On 2004-02-27, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
> >
> > I'm also dubious about relying on votes at IETF meetings for
> > technical issues ... because often an option which seems 'obvious'
> > at the time actually isn't once the drafts
On 2004-02-27, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
> >
> > * DIID offers less signalling. What advantages does DAD offer?
>
> An obvious advantage is less probability of (missing) duplication (as
> was pointed out even in this thread s
13 matches
Mail list logo
