> >
> > Assuming that the pool size is "n", where n = 2^40.
> >
> > As per your formula the probability of choosing two unique numbers is (n-
> 1)/n,
> > and of three unique numbers is ((n-1)/n)*((n-1)/n).
> >
> > As per Geoff, the probability of choosing two unique numbers is (n-1)/n,
> and
> > o
> Hi Margaret, thanks for your prompt response.
> I still do not understand how does the fact that a Hinden/Haberman address
> is globally unique, removes the need for a zone id/ site id. How does it
> settle with paragraph 6 of the Hinden/Haberman ID? ("site boarder routers
> SHOULD NOT forward an
in this regards.
CP
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Francis Dupont
> Sent: Thursday, August 28, 2003 2:30 PM
> To: Chirayu Patel
> Cc: [EMAIL PROTECTED]; 'Derek Fawcus'; 'Joshua Graessley'
> Subje
> > Note that one of the exception cases is stateless addr conf when
> > configuring multiple addresses using the same IID. Is node-requirments
> > trying to override this exception? If so, it should be explicit about
> > it. Otherwise, I'm not sure why the above sentence is included in
> > node-re
Hi John,
Just finished. Please see below for comments.
CP
General comments:
=
I am slightly confused about the philosophy behind organization of the
content. I would expect a requirements draft of this sort to contain points of
the following nature.
a) All sections of
> The usage that is actually envisaged is more limited: an identifier that
> provides disambiguation in a limited environment, normally a single
> site, possibly a small number of sites directly linked by VPN-like
> relations. In that scenario, the collisions that matter are those that
> occur with
Hi Fred,
I did a quick comparison with my set of comments, and I am happy. :-)
Just one minor point.
I had asked for adding text that would make it mandatory for each proposal to
include statistical analysis for
1) Probability of collision when "x" networks are merged, when "n"
addres
> I would rather like to see some text like:
> The following section of RFC x,y,z are obsoleted:
>
> section a.b.c of RFC
> .
That would be difficult. Text about Site-locals not localized. Maybe we can
rephrase the last sentence to
"Henceforth the prefix MUST be treated as an unass
> Whether I should process, If the IPv6 packet contains hop limit field is not
> equal to 255 and link Local as a destination address.(one of my link local
> Addr)
Routers will anyways not forward messages to LL dst address, so you may assume
that a message received with a LL dst address has been
> > Nothing breaks (wrt normal LL address usage) if those 54 bits have non
> > zero
> > values.
>
> Actually, you'll run in to some issues with any IPv6 stack based on
> Kame's implementation. Kame makes use of some of those bits to embed
> the scope id in some places while packets are handled in
If the next 54 bits are always expected to be zero then the prefix should be
declared to fe80::/64, and RFC 3513 should be corrected.
Do any of the old timers have a take on this one? Jim, Keith, Tony, Brian.
anyone? :-)
CP
>
> On Aug 27, 2003, at 9:19 AM, Derek Fawcus wrote:
>
> > On Wed,
I was always under the assumption that the prefix is fe80::/64, and not
fe80::/10. However, the latest and the best version of the Addressing
Architecture [RFC 3513] states the prefix as fe80::/10. Does it mean that
fe81::/16 can also be used as a link local prefix (note : section 2.5.6 in RFC
351
> >>That is what the hain/templin draft is about! The title of the draft is:
> >>
> >> "Addressing Requirements for Local Communications within Sites"
> >
> >Is the title supposed to be a pun? I.e., do you mean "to find solutions
> >to requirements for local communications .." or "finding requir
> > > |- If there is no match (I have only PUPI and DNS returns PA, or vice
> > > |versa), I would suggest to fail the connection by default (even though
> it
> > > |might work), but I am not sure.
> > >
> > > As long as this default can be changed without the cooperation on the
> > > applications
Hi,
I am quite satisfied with the coverage of the requirements for local
addressing. That said, I have a few questions, and comments.
Questions
-
1) What does the 3rd sentence in the 2nd para in section 3.4 mean? The
sentence I am referring to is "Given the presence of the well-known pre
> |- If there is no match (I have only PUPI and DNS returns PA, or vice
> |versa), I would suggest to fail the connection by default (even though it
> |might work), but I am not sure.
>
> As long as this default can be changed without the cooperation on the
> applications (i.e., a global option f
> - If there is no match (I have only PUPI and DNS returns PA, or vice
> versa), I would suggest to fail the connection by default (even though it
> might work), but I am not sure.
.maybe not. Failing connections is too drastic. You never know if the site
operator has set up an internal route
> The solution that will work for now is make a statement in the
> IETF and in industry IPv6 implementation documentation that
> link-local addresses SHOULD not be used as an IPv6 address
> type by applications. That link-local addresses SHOULD not be
> included in the DNS. That link-local adddr
> If the order of the addresses matters to any significant degree, no matter
> who
> decides what that order is or what mechanism is used to set that ordering,
> it
> will hamper applications. So I don't see it as useful to build mechanisms
> to
> allow sites to set that ordering. It's solving th
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-
> [EMAIL PROTECTED] On Behalf Of Bound, Jim
>
> The solution that will work for now is make a statement in the
> IETF and in industry IPv6 implementation documentation that
> link-local addresses SHOULD not be used as an IPv6 a
Hello,
I have submitted a new draft that specifies a procedure to automate the
updates to the policy table used in hosts for auto configuration.
The draft is available at
http://www.chirayu.org/I-D/draft-cpatel-ipv6-automated-policy-table-cfg-00.t
xt
The abstract of the draft gives more detail
My understanding is that the workgroup has voted to deprecate site-locals
unconditionally (having no dependency on the development and acceptance of
alternatives). Thus, I vote for A.
Apart from the above reason, I feel that deprecating site-locals ASAP will
lead to a rapid development of alter
> That's an interesting expectation. As co-author of the planned
> deprecation draft, I'd been assuming a more classical deprecation
> action, in which we would simply state the previous semantics of
> FEC0::/10, state that the prefix SHOULD NOT be used, but leave it
> permanently assigned by IANA.
Hi Nir,
My thoughts... Add the validation check! It does not seem to be expensive.
One scenario where is this check might be useful is to prevent
identification of the OS running on the router; the assumption is that not
checking the mapping is/will be atypical behavior. :-)
CP
-Original Me
[EMAIL PROTECTED] [mailto:owner-
> [EMAIL PROTECTED] On Behalf Of Chirayu Patel
> Sent: Tuesday, July 22, 2003 8:06 AM
> To: 'Suresh Krishnan (QB/LMC)'
> Cc: [EMAIL PROTECTED]
> Subject: RE: RFC 3513 EUI-48/MAC-48 confusion
>
> Hi,
>
> Can you quote the text fr
Hi,
Can you quote the text from
(http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) which you think
is contradicting Appendix A of RFC3513.
As per my understanding, the two match. Section "Encapsulated MAC-48 values"
in the tutorial says the same thing as Appendix A, which is to place th
Hi,
Can you quote the text from
(http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) which you think
is contradicting Appendix A of RFC3513.
As per my understanding, the two match. Section "Encapsulated MAC-48 values"
in the tutorial says the same thing as Appendix A, which is to place th
27 matches
Mail list logo
