On (2012-07-18 00:34 +0200), Jeroen Massar wrote:
Here's a calculator that will generate a random one for you:
does not follow RFC4193 in any way at all. A such do not use it.
Another silly oneliner, not RFC4193.
ruby -e'p (fd+rand(2**40).to_s(16)).scan(/.{1,4}/).join(:)+::/48'
I'm not
On Wed, 18 Jul 2012 10:04:05 +0300, Saku Ytti said:
However I'm not sure what would be good seed? ISO3166 alpha2 +
domestic_business_id + 0..n (for nth block you needed)
You want to roll in at some entropy by adding in the current date or
something, so two Joes' Burritos and Internet in 2
On (2012-07-18 09:10 -0400), valdis.kletni...@vt.edu wrote:
You want to roll in at some entropy by adding in the current date or
something, so two Joes' Burritos and Internet in 2 different states don't
generate the same value. There's a reason that 4193 recommends
a 64bit timestamp and an
On 18-Jul-12 02:04, Saku Ytti wrote:
On (2012-07-18 00:34 +0200), Jeroen Massar wrote:
Here's a calculator that will generate a random one for you:
does not follow RFC4193 in any way at all. A such do not use it.
I'm not sure if RFC4193 is best way to generate random part,
It's not claimed to
On 18-Jul-12 08:25, Saku Ytti wrote:
On (2012-07-18 09:10 -0400), valdis.kletni...@vt.edu wrote:
You want to roll in at some entropy by adding in the current date or
something, so two Joes' Burritos and Internet in 2 different states don't
generate the same value. There's a reason that 4193
On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
it should bepossible to incorporate RFC2777 verifiability to it.
There is no need for that, since your failure to use a good source of
randomness hurts nobody except yourself.
I think you're making fact out of opinion. Maybe SP is
On (2012-07-18 08:47 -0500), Stephen Sprunk wrote:
And, if they did, who cares? It's not like it hurts me for them to do
so--unless I'm dumb enough to do the same thing, happened to get the
same result /and/ happened to merge with them--all of which are still
unlikely events.
In which case,
On 07/18/2012 06:10 AM, valdis.kletni...@vt.edu wrote:
On Wed, 18 Jul 2012 10:04:05 +0300, Saku Ytti said:
However I'm not sure what would be good seed? ISO3166 alpha2 +
domestic_business_id + 0..n (for nth block you needed)
You want to roll in at some entropy by adding in the current date or
Peering Experts,
I am currently working on a BCOP for IPv6 Peering and Transit and
would very much appreciate some expert information on why using
PeeringDB is a best practice (or why its not). All opinions are
welcome, but be aware that I plan on using the responses to enhance
the document,
On Wed, Jul 18, 2012 at 11:43 AM, Chris Grundemann
cgrundem...@gmail.com wrote:
I am currently working on a BCOP for IPv6 Peering and Transit and
would very much appreciate some expert information on why using
PeeringDB is a best practice (or why its not). All opinions are
welcome, but be
On Wed, Jul 18, 2012 at 8:43 AM, Chris Grundemann cgrundem...@gmail.com wrote:
I am currently working on a BCOP for IPv6 Peering and Transit and
would very much appreciate some expert information on why using
PeeringDB is a best practice (or why its not). All opinions are
welcome, but be aware
Sent from my iPad
On Jul 18, 2012, at 8:48 AM, Saku Ytti s...@ytti.fi wrote:
On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
it should bepossible to incorporate RFC2777 verifiability to it.
There is no need for that, since your failure to use a good source of
randomness hurts nobody
On 18-Jul-12 08:48, Saku Ytti wrote:
On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
There is no need for [RFC2777 verifiability], since your failure to use a
good source of randomness hurts nobody except yourself.
I think you're making fact out of opinion. Maybe SP is generating ULAs for
The goal is Source of truth for any peer to know information at the
Exchange points as well as peering coordinator information. I think it is
a great tool for the peering community and definitely useful. Cons: Will
it be the next RADB? There needs to be a sustainable community to keep it
running
On Wed, Jul 18, 2012 at 9:59 AM, Zaid Ali z...@zaidali.com wrote:
The goal is Source of truth for any peer to know information at the
Exchange points as well as peering coordinator information. I think it is
a great tool for the peering community and definitely useful. Cons: Will
it be the
On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
On 18-Jul-12 08:48, Saku Ytti wrote:
Why would they do that? SPs should only be assigning (and routing) GUAs.
Because SP might be tasked to provide network plan for customers L3 MPLS
VPN and customer might get INET from different SP and might
In message 20120718180735.ga11...@pob.ytti.fi, Saku Ytti writes:
On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
On 18-Jul-12 08:48, Saku Ytti wrote:
Why would they do that? SPs should only be assigning (and routing) GUAs.
Because SP might be tasked to provide network plan for
So some comments on the intertubes claim that DoD ok'd use of it's
unadvertized space on private networks. Is there any official reference
that may support this statement that anyone of you have seen out there?
--Andrey
Even if they did OK it (which i doubt), actually using it - especially in a
public/customer facing / visible deployment - is a Bad Idea.
*Traceability fail and possibly creating unreachable networks out there ...*
/TJ
On Wed, Jul 18, 2012 at 9:24 PM, Andrey Khomyakov
khomyakov.and...@gmail.com
I am on sprint and my ip is always in the 20. net even though my wan up is
totally different.
Grant
On Wednesday, July 18, 2012, TJ wrote:
Even if they did OK it (which i doubt), actually using it - especially in a
public/customer facing / visible deployment - is a Bad Idea.
*Traceability
I disagree. I see it as an extra layer of security. If DOD had a network
with address space 'X', obviously it's not advertised to the outside. It
never interacts with public network. Having it duplicated on the outside
world adds an extra layer of complexity to a hacker trying to access it.
Anyone have a way to contact brighthouse network that doesn't end up
in residential support?
Thanks folks
On 7/18/12, Mark Andrews ma...@isc.org wrote:
[snip]
space, you meet the requirements. Toss a coin for each bit. Heads
= 1, tails = 0.
Sure... and if someone says they just happened to toss a coin 128
times, and got 0 all 128 times, therefore legitimately assigned ULA
ID is all zeros,I
On Wed, 2012-07-18 at 22:00 -0500, Jimmy Hess wrote:
Sure... and if someone says they just happened to toss a coin 128
times, and got 0 all 128 times, therefore legitimately assigned ULA
ID is all zeros,I don't believe them.
Um - 40 times, not 128. The first 8 are set, the last 80 are
In message caaawwbxn_zfk86yfd9myg6-hcnwsw2pmuq6yxwpr6b8v4fo...@mail.gmail.com
, Jimmy Hess writes:
On 7/18/12, Mark Andrews ma...@isc.org wrote:
[snip]
space, you meet the requirements. Toss a coin for each bit. Heads
=3D 1, tails =3D 0.
Sure... and if someone says they just happened to
On 7/18/12, Karl Auer ka...@biplane.com.au wrote:
I don't understand the professed need for provable randomness. Without a
number *space* to provide context, randomness is inherently
non-provable. The whole point of the randomness of those 40 bits of ULA
infix is that any number is as likely
On Wed, 2012-07-18 at 23:40 -0500, Jimmy Hess wrote:
When numbers are selected by choosing a random value; certain ratios
of bits set to 1 are more likely to occur than other ratios of bits
set to 1.
True. But you cannot tell, from a sample of one number, whether that
number was chosen
27 matches
Mail list logo
