[ppml] Keeping the story straight

Sun Jun 3 04:17:47 EDT 2007

That's why it is needed ULA-Central, in the sense of a prefix that
*requires* registration in a central registry, so never there is a clash. If
a company uses ULA-Central w/o going to the registry, in case of a clash
that company will be in trouble because did the wrong thing.

Having a volunteer registry service for ULA doesn't mandate everyone to
register, and thus, nobody is doing wrong: it creates the wrong impression
that you're safe, but not really, because it is not part of the "protocol".

Regards,
Jordi

> De: John Santos <JOHN at egh.com>
> Responder a: <JOHN at egh.com>
> Fecha: Sat, 2 Jun 2007 22:50:45 -0400
> Para: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> CC: <ppml at arin.net>
> Asunto: Re: [ppml] Keeping the story straight
> 
> On Sun, 3 Jun 2007, JORDI PALET MARTINEZ wrote:
> 
>> Hi Jeroen,
>> 
>> Is nothing personal. I can trust you, many people can trust many volunteer
>> services, but for something that big enterprises need to have the security
>> of a 0% collision chances, they will not trust a volunteer service. There is
>> NO warrantee for them that this will keep running forever.
> 
> I don't see why it is necessary that it run forever.  If enterprise A
> and Enterprise B and Enterprise C all register unique addresses with
> SixXS' server,  SixXS could vanish into the great bit bucket 5
> seconds later, and there would still never be a collision between A,
> B or C.
> 
> If Enterprises D and E created their own ULA addresses and did not register
> with SixXS, then there is no guarantee there won't be a collision between
> D and A, B, C or E, or between E and A, B, C or D, whether or not SixXS
> continues to exist.  The only difference if SixXS goes away and A wants
> to interconnect with D or E, they will have to use other means to verify
> uniqueness (like ask each other what addresses they are using.)  This is
> exactly the current state of affairs without SixXS.  For as long as SixXS
> continues to exist, D and E would have the option of registering with it,
> and ensuring uniqueness (but possibly having to renumber if they have
> already used colliding ULAs.)  If SixXS goes away, they would no longer
> have this option, but this could not suddenly cause A, B or C to collide
> with each other.
> 
> Neither Enterprise A nor B nor C needs any promise that SixXS will continue
> to exist after they register with it to know they are still unique
> within the set of SixXS' registerees.  (Unless of course they want to
> register *additional* ULA space, which puts them in the same position
> as D & E with respect to the new space but doesn't affect the existing
> space.)
> 
>> 
>> Is nothing related to you work, is just the way enterprises work.
>> 
>> Is nothing related to you offering this service, it can be another volunteer
>> team, it will be the same.
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>>> De: Jeroen Massar <jeroen at unfix.org>
>>> Organización: Unfix
>>> Responder a: <jeroen at unfix.org>
>>> Fecha: Sat, 02 Jun 2007 21:02:26 +0100
>>> Para: <jordi.palet at consulintel.es>
>>> CC: <ppml at arin.net>
>>> Asunto: Re: [ppml] Keeping the story straight
>>> 
>>> JORDI PALET MARTINEZ wrote:
>>>> Unfortunately volunteers offering a service can't be trusted by
>>>> organizations, as the service can vanish and then you're in trouble.
>>> 
>>> Ehmm. Hold on there for a few seconds. That subject really doesn't
>>> match the content, but lets make it match quite a bit more.
>>> 
>>> Are you implying that SixXS can't be trusted!? I am really wondering
>>> what you are trying to imply with that statement.
>>> 
>>> Did you notice that http://www.sixxs.net/tools/grh/ula/ contains a
>>> list of all the allocations that have been made? (inet6num.txt)
>>> Do you realize that that list is VERY easy to mirror.
>>> Do you realize that that list is nicely mirrored into Google and
>>> various other crawler bots who crawl the web?
>>> 
>>> Claiming that it can 'vanish' is just pathetic. SixXS won't 'vanish',
>>> there are too many people very happily using the services that it
>>> provides, and actually we are more than enjoying ourselves in
>>> providing the various great services that it provides to the
>>> community. Neither Pim or I have any intentions of letting the project
>>> vanish. As long as people have a need for free help in getting IPv6
>>> going in their organizations we are ready to assist them with the help
>>> and experience that we can provide them.
>>> 
>>> I've also stated, but I'll do it again, that if/when one of the
>>> RIR/IETF/IANA has a registry for these things that we can provide them
>>> with the current list, and redirect the page to that resource.
>>> Those are the 'authoritive' places, and we play in that game.
>>> 
>>> Next to that, you are definitely mixing up ULA-C with normal ULA's.
>>> Normal ULA's, according to RFC4193 don't have any registered part.
>>> ULA-C's are not accepted by the registry we run, which is not so
>>> strange as there is no RFC covering fc00::/8. The ULA registry that
>>> currently is at http://www.sixxs.net/tools/grh/ula/ allows people
>>> merely to register their ULA's so that it might decrease the chance of
>>> collisions a little bit more.
>>> 
>>>> Sorry, but this ULA-Central need a serious proven and stable service
>>> 
>>> And are you implying here that SixXS is not a proven and not stable
>>> service?
>>> 
>>> I do sincerely hope that you are not trying to insult all the hard
>>> work that has gone and more that will go into into this project by a
>>> lot of people and several great companies that have been supporting
>>> this project for the last couple of years. I feel _very_ insulted by
>>> the statements you are making here and I really hope that you are
>>> meaning something completely different.
>>> 
>>> What are you going to claim next, that Team Cymru, who also are doing
>>> great work, should not maintain bogon lists because they are not a
>>> company?
>>> 
>>>> and the RIRs are already doing so for other kinds of addresses.They are the
>>>> perfect fit, and the alternative is IANA or a third party organization.
>>> 
>>> How is SixXS not a "third party organization"?
>>> 
>>>> Of course, if the community prefers going that way and have a third party
>>>> organizations running that registry, I'm fine and all will pay the
>>>> consequences sooner or later.
>>> 
>>> Sorry, but all of this coming from someone who is abusing his
>>> "Experimental IPv6 Allocation", thus avoiding paying of LIR fees, so
>>> that it can be used to do an "Experimental IPv6 ISP Service" as you
>>> described it last week on these lists, sounds really really bad.
>>> 
>>> Greets,
>>>  Jeroen
>>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Bye 6Bone. Hi, IPv6 !
>> http://www.ipv6day.org
>> 
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>> 
>> 
>> 
>> _______________________________________________
>> This message sent to you through the ARIN Public Policy Mailing List
>> (PPML at arin.net).
>> Manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> 
>> 
> 
> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.