On Fri, 24 Oct 2003, jspark wrote:
> > But it is mandated by the specs. So
> > these addresses are
> > *not* truly, completely, totally, unique.
>
> In our spec.
> The uniqueness of LL unicast address is verified by DAD procedure.
> And then, EUI-64 IID (or other) is extracted from LL Unicast add
Hi
I don't get:
1°) The need for such link-local adresses. Maybe it should be
described in the document (saying you will not need any allocation
server or equivalent is not enough I think). What type of applications
you think will need these link-local adresses?
2°) Why to use the flag bi
-Original Message-
From: jspark [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 7:51 PM
To: 'Pekka Savola'
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Hi Pekka.
On Fri, 24 Oct 2003, Pekka Savola wrote:
> First, there is typically just one link-local address.
> Either it
On Fri, 24 Oct 2003, jspark wrote:
> Section 3 of our spec says:
> ---
> "Interface ID field is used to distinguish each host from others. And
>this value is obtained from the IEEE EUI-64 based interface
>identifier of the link-local unicast IPv6 address."
> ---
>
> Ou
> Hi, Pekka.
>
> >>>Pekka Savola wrote:
> >> > First, there is no guarantee of uniqueness in the first place, as
> >> > DAD on the IPv6 link-local unicast address was performed on the
> >> > address, not the Interface-ID. In practice, the
> collisions should be
> very rare, though.
My understa
Hi, Pekka.
>>>Pekka Savola wrote:
>> > First, there is no guarantee of uniqueness in the first place, as
>> > DAD on the IPv6 link-local unicast address was performed on the
>> > address, not the Interface-ID. In practice, the collisions should be
very rare, though.
>>Myung-Ki Shin wrote:
>>
On Thu, 23 Oct 2003, Myung-Ki Shin wrote:
[...]
>As Erik said, I think that this draft has benefits over unicast-prefix for
>scope <=2.
>Each node can allocate group ID (32 bits) independently (without any user
>input, without a fear of collision or any additional mechanisms).
The
Hi, Pekka.
Pekka Savola wrote:
> There are a large number of things to be said, but I'll just stick to two
> main points. I've never seen much use for this specification, and I do
> not believe this specification is useful as is.
As Erik said, I think that this draft has benefits over unicas
Erik Nordmark wrote:
> > In my memory,
> > IPv6 guys also agreed on our view during the 54th IETF meeting.
> >
> > I think ..
> > RFC3306 needs allocation server of 32bit goup ID
> > in order to support the uniqueness in the site.
> > This site is identified by network prefix.
> >
> > But,
> > Gro
On Wed, 22 Oct 2003, Pekka Savola wrote:
> - put it in RFC3306 address, like FF32:40:fe80:: or
>FF32:A:fe80::.
>this would leave 64 bits space to generate an address, assuming the
>group-id is 32.
> - the 64 bits () could be the interface ID of the link-local
>address, or someth
Hi,
On Tue, 21 Oct 2003, Bob Hinden wrote:
> This is a IPv6 working group last call for comments on advancing the
> following document as an Proposed Standard:
>
> Title : Link Scoped IPv6 Multicast Addresses
> Author(s) : J. Park, et al.
> Filename: dra
> In my memory,
> IPv6 guys also agreed on our view during the 54th IETF meeting.
>
> I think ..
> RFC3306 needs allocation server of 32bit goup ID
> in order to support the uniqueness in the site.
> This site is identified by network prefix.
>
> But,
> Group ID Autoconfiguration in link-scope w
Please ignore this message. The correct Last Call announcement is
in a separate message.
Brian
Brian Haberman wrote:
This is a IPv6 working group last call for comments on advancing the
following document as an Proposed Standard:
Title: IPv6 Scoped Address Architecture
Author(s)
Hi Erik
Thanks for your comments.
> I'm trying to understand why the RFC 3306 are so broken for scope <=2
> that they can not be used.
> While using the new address format for scope <= 2 would presumably be
>preferred I don't see why prohibiting
> (as the "MUST" above does) the use of RFC 3306
Please ignore this message. The correct Last Call announcement is
in a separate message.
Brian
Brian Haberman wrote:
This is a IPv6 working group last call for comments on advancing the
following document as an Proposed Standard:
Title: Deprecating Site Local Addresses
Author(s)
This is a IPv6 working group last call for comments on advancing the
following document as an Proposed Standard:
Title : IPv6 Scoped Address Architecture
Author(s) : S. Deering et al.
Filename: draft-ietf-ipv6-scoping-arch-00.txt
Pages
This is a IPv6 working group last call for comments on advancing the
following document as an Proposed Standard:
Title : Deprecating Site Local Addresses
Author(s) : C. Huitema, B. Carpenter
Filename: draft-ietf-ipv6-deprecate-site-local-01.txt
The document says:
scop <= 2. The value of this multicast address is necessary to
distinguish between an Interface ID-based multicast address and a
unicast-prefix-based multicast address. If scop <= 2, the former MUST
be used. That is, this document updates the [RFC 3306], which
d
This is a IPv6 working group last call for comments on advancing the
following document as an Proposed Standard:
Title : Link Scoped IPv6 Multicast Addresses
Author(s) : J. Park, et al.
Filename: draft-ietf-ipv6-link-scoped-mcast-03.txt
Page
19 matches
Mail list logo
