Le 2013-02-07 à 17:55, Doug Barton a écrit :
> On 02/07/2013 06:01 AM, Rémi Després wrote:
>> Besides, these remaining concerns are aside from the question asked by
>> Softwire
>
> Rémi,
>
> Do you admit to the possibility that the design coming from softwire might
> have flaws that should b
2013-02-07 16:34, Ray Hunter :
> Ole Troan wrote:
>> Remi,
...
>>
>> I think our understanding of the IPv6 addressing architecture is
>> incompatible.
>> there are no unused subset or unused ranges of interface-ids in IPv6.
>>
>> cheers,
>> Ole
> FWIW I agree with Ole.
>
> An IID currently o
On 02/07/2013 06:01 AM, Rémi Després wrote:
Besides, these remaining concerns are aside from the question asked by Softwire
Rémi,
Do you admit to the possibility that the design coming from softwire
might have flaws that should be addressed before it proceeds?
I'm not saying necessarily tha
Ole Troan wrote:
> Remi,
>
> with Remi's proposal, a duplicate address will not even be detected.
Correct: even if software is available to detect collisions between 4rd
addresses and RFC 4291-compatible host addresses, it won't detect any.
(Such software, which isn't mandatory
2013-02-07 15:04, Ole Troan :
> I think our understanding of the IPv6 addressing architecture is incompatible.
> there are no unused subset or unused ranges of interface-ids in IPv6.
1. If you interpret RFC 4291 as already permitting to set u=1 in some IIDs
other than derived from IEEE MAC ad
Remi,
with Remi's proposal, a duplicate address will not even be detected.
>>>
>>> Correct: even if software is available to detect collisions between 4rd
>>> addresses and RFC 4291-compatible host addresses, it won't detect any.
>>> (Such software, which isn't mandatory for 4rd, is of cou
2013-02-07 14:41, Ole Troan :
> Remi,
>
>> ...
>>> with Remi's proposal, a duplicate address will not even be detected.
>>
>> Correct: even if software is available to detect collisions between 4rd
>> addresses and RFC 4291-compatible host addresses, it won't detect any. (Such
>> software,
Remi,
> ...
>> with Remi's proposal, a duplicate address will not even be detected.
>
> Correct: even if software is available to detect collisions between 4rd
> addresses and RFC 4291-compatible host addresses, it won't detect any. (Such
> software, which isn't mandatory for 4rd, is of course
2013-02-06 17:28, Ole Troan :
> Fernando,
...
> with Remi's proposal, a duplicate address will not even be detected.
Correct: even if software is available to detect collisions between 4rd
addresses and RFC 4291-compatible host addresses, it won't detect any. (Such
software, which isn't manda
Le 2013-02-06 à 22:12, Roland Bless a écrit :
...
>
>> Nothing new needs to be done in any implementation other than that of a
>> 4rd-supporting devices (4rd CEs and BRs).
>>
>>> In case that they are
>>> not using 4rd, MUST they exclude this IID range?
>>
>> Because of RFC 4291 is as it is,
Hi,
On 06.02.2013 17:55, Rémi Després wrote:
>> Am 06.02.2013 14:52, schrieb Rémi Després:
>>> As already said, the 4rd range only makes a first use of an existing
>>> RFC4291 provision: "The use of the universal/local bit in the
>>> Modified EUI-64 format identifier is to allow development of fut
2013-02-06 17:41, "Bless, Roland (TM)" :
> Hi,
>
> Am 06.02.2013 14:52, schrieb Rémi Després:
>> As already said, the 4rd range only makes a first use of an existing
>> RFC4291 provision: "The use of the universal/local bit in the
>> Modified EUI-64 format identifier is to allow development of
Hi Fernando,
Am 06.02.2013 17:16, schrieb Fernando Gont:
> On 02/06/2013 10:52 AM, Rémi Després wrote:
>>
>> - The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a
>> tool to RESOLVE them when they occur.
>
> DAD *detects* them, but does not resolve them (for instance, the las
Hi,
Am 06.02.2013 14:52, schrieb Rémi Després:
> As already said, the 4rd range only makes a first use of an existing
> RFC4291 provision: "The use of the universal/local bit in the
> Modified EUI-64 format identifier is to allow development of future
> technology that can take advantage of interf
Le 2013-02-06 à 17:16, Fernando Gont a écrit :
> On 02/06/2013 10:52 AM, Rémi Després wrote:
>>
>> - The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a
>> tool to RESOLVE them when they occur.
>
> DAD *detects* them, but does not resolve them (for instance, the last
> "D"
Fernando,
>> - The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a
>> tool to RESOLVE them when they occur.
>
> DAD *detects* them, but does not resolve them (for instance, the last
> "D" stands for detection). As a datapoint, all the v6 implementations I
> know of support DA
On 02/06/2013 10:52 AM, Rémi Després wrote:
>
> - The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a tool
> to RESOLVE them when they occur.
DAD *detects* them, but does not resolve them (for instance, the last
"D" stands for detection). As a datapoint, all the v6 implementat
2013-02-06 à 13:07, "Bless, Roland (TM)" :
> Dear Rémi,
>
> Am 06.02.2013 11:13, schrieb Rémi Després:
>> This is, in my understanding, what should be avoided in 6man, a debate on
>> new 4rd modifications:
>> - The 4rd design has been stabilized for long in Softwire.
>> - The question to 6man
Dear Rémi,
Am 06.02.2013 11:13, schrieb Rémi Després:
> This is, in my understanding, what should be avoided in 6man, a debate on
> new 4rd modifications:
> - The 4rd design has been stabilized for long in Softwire.
> - The question to 6man is ONLY whether the proposed reserved range is
> compa
ns:
> - The 4rd design has been stabilized for long in Softwire.
> - The question to 6man is ONLY whether the proposed reserved range is
> compatible with the IPv6 addressing architecture.
>
> Thanks,
> RD
>
>
>
>> De : Ole Troan
>> Objet : Rép : Keeping
> De : Ole Troan
> Objet : Rép : Keeping the 4rd-range issue separate from the general u/g
> discussion
> Date : 2013-02-05 22:42
> À : "Manfredi, Albert E"
> Cc: "ipv6@ietf.org"
>
>> +1
>>
>> If a better alternative is devised for
> +1
>
> If a better alternative is devised for 4rd, as Roland proposes here, then can
> we deprecate the u/g bit usage? Seems to me that privacy addresses are
> preferable anyway, if not DHCP or statically assigned ones, so any importance
> assigned to u/g surely becomes a historical artifact?
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Bless, Roland (TM)
> Sent: Tuesday, February 05, 2013 12:08 PM
> To: ipv6@ietf.org
> Subject: Re: Keeping the 4rd-range issue separate from the general u/g
> discussion
Hi all,
On 05.02.2013 16:51, Rémi Després wrote:
> Several opinions against a 4rd-range reservation have also been
> expressed, but they concern the purpose of 4rd, or its experimental
> status, or personal feelings against one more specification. They are
> not about technical compatibility with
Bob,
It seems the general discussion on u/g-bits clarification is going to be long.
Fortunately it also appears, for instance in the following, that compatibility
of the 4rd IID-range with the IPv6 addressing architecture doesn't depend on
this work being completed.
2013-02-05 15:36, Brian
25 matches
Mail list logo
