No.
The all-routers anycast address is resolved and creates a single Layer 2
neighbor entry - it may change, but there's no packet duplication issue here
because routing of an individual packet will only ever go to a single host at
L2, There is a difference between Multicast and Anycast.
Regards,
Oliver
This gets a lot easier if you use the tools site:
https://tools.ietf.org/html/rfc4291
- --
If you're never wrong, you're not trying hard enough
For those with PA space https://tools.ietf.org/html/rfc6144 should be a
good solution.
Doug
Don't, because there's already a /10 defined for such things. It's
called ULA (unique local address) aka RFC 4193. ULAs are not globally
routable.
Here's a calculator that will generate a random one for you:
~Seth
[..]
Don't, because there's already a /10 defined for such things. It's
called ULA (unique local address) aka RFC 4193. ULAs are not globally
routable.Here's a calculator that will generate a random one for you:
A random one indeed, because the javascript for it is just:
8<-----------------------------------------------------
var calc_private = function() {
var str = "fd";
for(i = 0; i<10; i++) {
str = str + toHex(Math.floor(Math.random()*16));
if (i % 4 == 1) str = str + ":";
}
$("#private_subnet").html("Your private subnet is:
<code>"+str+":/48</code>");
$("#multicast1").val(str+":/48");
calc_multicast1();
------------------------------------------------------->8
does not follow RFC4193 in any way at all. A such do not use it.
The original real RFC4193 ULA generator script can be found at:
http://www.kame.net/~suz/gen-ula.html
google(ipv6 ula) for another page, that has been referenced often enough
on this very list already, if you want to 'register' it there to avoid
another small chance of collision, that page also uses the script from
the above site for a true RFC4193 prefix.
Greets,
Jeroen
Oh well, so much for the googles. Still, don't make up your own squat
range for "private" IPv6 space. Use ULA if you really want such a thing.
~Seth
[..]
Here's a calculator that will generate a random one for you:
A random one indeed, because the javascript for it is just:
[..]
does not follow RFC4193 in any way at all. A such do not use it.
The original real RFC4193 ULA generator script can be found at:
http://www.kame.net/~suz/gen-ula.htmlgoogle(ipv6 ula) for another page, that has been referenced often enough
on this very list already, if you want to 'register' it there to avoid
another small chance of collision, that page also uses the script from
the above site for a true RFC4193 prefix.Oh well, so much for the googles.
Yes, it is a shame that the bitace thing references RFC4193 and then
does not use it. Lets Bcc: them and see if they act upon, you never know
if they fix things or not, there are good guys still left on these
Internets.
Still, don't make up your own squat
range for "private" IPv6 space. Use ULA if you really want such a thing.
I am wondering what you meaning with 'squat', note that what I reference
above is real full RFC4193 calculated ULA.
The optional registration thingy is just optional for those that don't
trust probability and want to have a little more security. Also lots of
folks like to claim something as their own and well storage bits are
cheap for that little amount of info and reassures a lot of folks.
Greets,
Jeroen
[..]
Here's a calculator that will generate a random one for you:
[..]
Yes, it is a shame that the bitace thing references RFC4193 and then
does not use it. Lets Bcc: them and see if they act upon, you never know
if they fix things or not, there are good guys still left on these
Internets.
So much for gmail never fails:
<info@bitace.com>: host aspmx.l.google.com[173.194.70.26] said:
550-5.1.1 The
email account that you tried to reach does not exist. Please try
550-5.1.1
double-checking the recipient's email address for typos or 550-5.1.1
unnecessary spaces. Learn more at 550 5.1.1
Fix bounced or rejected emails - Gmail Help
p20si34103229wiv.37 (in reply to RCPT TO command)
If anybody does have a contact @bitace.com don't hesitate to forward
them this discussion.
Now also bcc'd to the contact in whois for the domain.
Greets,
Jeroen
I am wondering what you meaning with 'squat', note that what I reference
above is real full RFC4193 calculated ULA.
By "squat" I meant take a random chunk of IPv6 space and use it as
"private" address space. He said:
[..]
> Don't, because there's already a /10 defined for such things. It's
> called ULA (unique local address) aka RFC 4193. ULAs are not globally
> routable.
>
> Here's a calculator that will generate a random one for you:
>
> http://bitace.com/ipv6calc/A random one indeed, because the javascript for it is just:
8<-----------------------------------------------------
var calc_private = function() {var str = "fd";
for(i = 0; i<10; i++) {
str = str + toHex(Math.floor(Math.random()*16));
if (i % 4 == 1) str = str + ":";
}$("#private_subnet").html("Your private subnet is:
<code>"+str+":/48</code>");
$("#multicast1").val(str+":/48");
calc_multicast1();
------------------------------------------------------->8does not follow RFC4193 in any way at all. A such do not use it.
If you have a true random number source you don't need to use the
method in RFC4193. The method in RFC4193 is designed to get produce
a good enough pseudo source of randomness.
Another silly oneliner, not RFC4193.
ruby -e'p ("fd"+rand(2**40).to_s(16)).scan(/.{1,4}/).join(":")+"::/48"'
I'm not sure if RFC4193 is best way to generate random part, it should be
possible to incorporate RFC2777 verifiability to it. It would allow
operators to prove people who got memorable addresses were not favoured and
it would allow the people who generated them to prove they used accepted
methods to generate them.
However I'm not sure what would be good seed? ISO3166 alpha2 +
domestic_business_id + 0..n (for nth block you needed)
In practice I'm sure we'll notice bias in random numbers towards 0. As many
people who've not been through painful enough M&A renumbers will opt for
memorable addresses.
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 EUI64.
I assume business ids are federal not state, as IRS is federal? Anyhow I'm
not saying 'this is how it should be done', I'm saying maybe there is way
to do this in a way which is verifiably random.
64b timestamp and EUI64 make it non-verifiable. I think it would be nice,
that people who play by the rules are able to prove they did. Otherwise you
can generate it any way you want and claim you did it the right way.
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 be the "best" way, just one of many possible good
ways. If you can demonstrate that your way is at least as good, go for it.
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.
If you're too lazy to come up with a good method yourself, as most
people are, there are several online RFC 4193-compliant prefix
generators that will save you the effort. At least one even includes
the ability to record your results and be assured (within the margin of
best-effort service) that you will not collide with anyone else who does so.
S
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 EUI64.
I assume business ids are federal not state, as IRS is federal? Anyhow I'm not saying 'this is how it should be done', I'm saying maybe there is way to do this in a way which is verifiably random.
US EINs/SSNs, and various state-level ID numbers, are not random; given
our problems with identity theft, they're not guaranteed to be unique,
either. I assume the same is true for identification numbers in most
other countries.
64b timestamp and EUI64 make it non-verifiable.
If you publish the numbers you used, then others can verify that those
values are reasonable. I doubt anyone would sift through billions of
reasonable timestamps combined with the thousands of EUI64s at their
site just to find a result that was "memorable".
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.
S
I think you're making fact out of opinion. Maybe SP is generating ULAs for
their customers. Maybe they'd like to be able to prove in case of dispute
that other customer with memorable ULA was not favoured.
Maybe someone claims I'm not using BCP methods for ULA selection, and I'd
like to be able to falsify those claims.
Obviously I could come up with some own RRFC2777 style algo to generate
ULA, but if it would be internally documented it would hardly be provable,
as I couldn't prove I haven't come up with the algo after generating the
prefix.
Maybe this is not practical enough concern, but I'm wondering, what is the
downside? What is the benefit of recommending method which is not
testable/provable.
In which case, you could prove you did the right thing. I'm not disagreeing
with you that benefits are marginal (I think most 'randomly' choose 0
anyhow).
I'm asking, what would the recommend method lose by being verifiable?
ulamart.com is available for the enterprising amongst us...
Mike
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 generating ULAs for
their customers. Maybe they'd like to be able to prove in case of dispute
that other customer with memorable ULA was not favoured.
Maybe someone claims I'm not using BCP methods for ULA selection, and I'd
like to be able to falsify those claims.
SP should never do that. SP should provide GUA. ULA should be local to the customer and not used between customers unless the customers specifically agree to do so. In that case, the customers can handle the coordination and there is no need for the SP to be involved in any dispute.
Owen
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 their customers.
Why would they do that? SPs should only be assigning (and routing) GUAs.
ULAs are for /local/ use within the customer site, so customers can and
should generate their own locally. An SP should never see those
addresses and can safely ignore their existence, aside from a generic
filter on the entire ULA range.
Maybe this is not practical enough concern, but I'm wondering, what is the downside? What is the benefit of recommending method which is not
testable/provable.
Those were not considered requirements for the algorithm in RFC 4193
since there is no scenario /where RFC 4193 addresses are a valid
solution in the first place/ for which testability or provability of the
algorithm's results are important or even useful.
S