> On Wed, 14 Jul 2004 04:56:40 +0900 (JST),
> [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
>> The simplest resolution would be to add a qualifier like this:
>>
>> If the address is a link-local address formed from an interface
>> identifier based on the hardware address which shoul
> > On Tue, 13 Jul 2004 10:23:01 +0900,
> > [EMAIL PROTECTED] said:
>
> >>> ok, from the attached message, i can see which direciton you are going
> >>> to. i'll wait for the next revision.
> >>
> >> The proposed revised text (the entire Section 5.4.5) is attached
> >> below. Is this a
> On Tue, 13 Jul 2004 10:23:01 +0900,
> [EMAIL PROTECTED] said:
>>> ok, from the attached message, i can see which direciton you are going
>>> to. i'll wait for the next revision.
>>
>> The proposed revised text (the entire Section 5.4.5) is attached
>> below. Is this acceptable?
>
>> ok, from the attached message, i can see which direciton you are going
>> to. i'll wait for the next revision.
>
>The proposed revised text (the entire Section 5.4.5) is attached
>below. Is this acceptable?
basically i'm happy with the text. one thing boggles me is that
> On Thu, 08 Jul 2004 14:32:08 +0900,
> [EMAIL PROTECTED] said:
>>> i would like to see your clarified text and then i may comment.
>>
>> The last one (see also a previous message of mine in this thread -
>> attached below). Or perhaps even more - for example, if a router
>> finds dupli
(text cut)
> yes, that is what i want to see. however, even in this case,
> "disable" has multiple interpretations:
> - disable the address which failed DAD
> - disable the address which shares the same interface ID as the
> DAD-failed linklocal
The 2nd choice s
>> i would like to see your clarified text and then i may comment.
>
>The last one (see also a previous message of mine in this thread -
>attached below). Or perhaps even more - for example, if a router
>finds duplication on an interface, it won't forward packets to or from
>that interface.
> On Thu, 8 Jul 2004 14:04:42 +0900 (JST),
> [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
>> >moreover, if MAC address is under collision, IPv4 does not work,
>> >Appletalk does not work (i guess). so there's no point in IPv6
>> >making a judgement call to disable *int
> Besides, the current text of rfc2462bis actually says "based on the
> hardware address" instead of assuming EUI-64 unconditionally:
>
>If the address is a link-local address
>formed from an interface identifier based on the hardware address
>(e.g., EUI-64), the interface SHOULD be di
> On Wed, 07 Jul 2004 17:38:29 +0900,
> [EMAIL PROTECTED] said:
>> Meanwhile, we could also make a more fundamental question on whether
>> the analysis that Thomas provided (i.e., DAD failure for EUI-64 based
>> address probably means MAC collision) is valid. If not, this can be
>> anoth
> On Tue, 6 Jul 2004 12:08:49 +0900 (JST),
> [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
> i have objection to 5.4.5 "when duplicated address detection fails".
> the text suggest that hardware-address-based linklocal address fails
> on DAD test, "the interface SH
>The main point Thomas made is that DAD failure for an EUI-64 based
>address is likely to indicate MAC address collision, in which case
>disabling the entire interface is better rather than trying hopeless
>recovery which may even make it harder to diagnose the real problem.
>(I believe the current
> On Tue, 6 Jul 2004 12:08:49 +0900 (JST),
> [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
> i have objection to 5.4.5 "when duplicated address detection fails".
> the text suggest that hardware-address-based linklocal address fails
> on DAD test, "the interface SH
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Version 6 Working Group Working Group of the
> IETF.
>
> Title : IPv6 Stateless Address Autoconfiguration
> Author(s) : S. Thomson, et al.
> Fi
All,
This note starts a 2 week IPv6 Working Group Last Call on:
Title : IPv6 Stateless Address Autoconfiguration
Author(s) : S. Thomson, et al.
Filename: draft-ietf-ipv6-rfc2462bis-02.txt
Pages : 30
Date: 200
> On Fri, 18 Jun 2004 11:54:48 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> As you may have noticed, a new revision of the rfc2462bis document
> has been issued. (During the attempt to fix the truncation in
> rfc2462bis-01, I needed to increment the version number. So please
> jus
Hello,
As you may have noticed, a new revision of the rfc2462bis document
has been issued. (During the attempt to fix the truncation in
rfc2462bis-01, I needed to increment the version number. So please
just ignore the incomplete 01 revision).
I believe I've solved all known issues identified s
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : IPv6 Stateless Address Autoconfiguration
Author(s) : S. Thomson, et al.
Filename
18 matches
Mail list logo
