On 9/29/11 06:20 , Dan Lanciani wrote:
> Jeroen Massar <[email protected]> wrote:
> 
> |On 2011-09-29 09:20 , Roland Bless wrote:
> |> Hi Brian,
> |> 
> |> Am 28.09.2011 23:07, schrieb Brian E Carpenter:
> |>> On 2011-09-28 23:08, Roland Bless wrote:
> |>> ...
> |>>> The current ULA-C...
> |>>
> |>> What do you mean? There is no current definition of ULA-C.
> |> 
> |> That's right :-)
> |> I was referring to the definition in RFC 4193 with L=0, i.e.,
> |> centrally assigned ULAs. I know that the registry and assignment
> |> procedure for ULA-C are not defined yet, but the basic format will be
> |> the same as in RFC 4193. The few I-D proposals for ULA-Cs seemed
> |> to suggest allocating /48s and not larger address blocks and I could
> |> very well imagine, that this will be the case if we ever define ULA-Cs.
> |
> |You do realize that the RIRs are providing exactly what you describe? :)
> 
> Except that RIRs generally charge a high rent for those addresses and/or
> impose constraints on how they can be used.  ULAs were supposed to be a
> replacement for site local addresses, available to anyone for any purpose.

Even a cursory glance at RFC 4193 would cause you to conclude that they
are not in fact to be used for any purpose.

if you're refering to having the L bit set to 1 that hasn't been defined
yet. ULA-C was proposal to do that. but that's just it, a proposal.

joel

> | - globally guaranteed unique (due to registry) large address prefixes
> |Which is why from my information ULA-C has also been abandoned, as it
> |already is something that has already been resolved.
> |
> |What makes me wonder though, is why you would want to have different
> |prefixes in different locations that never ever ever will talk to each
> |other directly using those prefixes.
> 
> And so we come full circle.  Site local addresses existed for that kind of
> situation.  Now why again was it so critical to get rid of them? :)
> 
>                               Dan Lanciani
>                               ddl@danlan.*com
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to