Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Mar 2016 16:36:21 +0100

Le 18/02/2016 01:35, Mark Andrews a écrit :
>
> In message
> <[email-masked]>
> , Tom Coffeen writes:
>> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong <[email-masked]>
>> wrote:
>>
>>>
>>>> On Feb 15, 2016, at 23:51 , [email-masked] wrote:
>>>>
>>>>> I believe we should not even suggest that it might be OK to
>>>>> allocate manually. This draft isn't a BCP so we can use
>>>>> normal English, for example:
>>>>>
>>>>> o Prefix generation: prefixes must be randomly generated
>>>>> according to the algorithms defined in [RFC4193]. There are
>>>>> on-line tools available to do this interactively, if not
>>>>> performed automatically by the CPE. Manual assignment of
>>>>> easy-to-remember prefixes must never be done because of the
>>>>> high risk of collision, recreating the problems of
>>>>> [RFC1918].
>>>>
>>>> Assume I want to number my lab using ULA. There's no way I'm
>>>> going to be using randomly generated addresses - I want to have
>>>> an *address plan*, and predictable addresses acording to a
>>>> suitable pattern, just as I would do with regular IPv6
>>>> addresses.
>>>
>>> Youâ€™re supposed to randomly select a /48 from fc00::/7
>>
>> My understanding from RFC4193 is that the L bit (8th MSB) is not
>> yet defined (i.e., not "locally defined") when set to 0. Should
>> this impact at all one's confidence in allocating /48s from
>> fc00::/8?
>
> fc00::/8 is reserved - DO NOT USE fd00::/8 is where you should be
> generating your prefixes in.
>
> If you need to simulate a /32 then generate bits 9..32 randomly and
> prefix with 11111101.  Repeat if you are simulating more than one
> ISP.
>
> There is never a valid case for not generating the high bits
> randomly. You don't get "nice" upper bits from RIR's unless you are
> very lucky.

There is one question of getting "nice" upper bits from RIRs, and there
is another question of getting "nice" intermediary bits from intermediaries.

I managed to persuade my intermediary to give me the intermediary bits
of my choice.  I struggled a lot to decide what would be nice, I used
some generator, some dictionaries, some well-known niceties - and then
the intermediary agreed.

This deliberation of "nice" intermediary did not exist in IPv4, and it
is new in IPv6.  Faceb00c put their names into their addresses, imagine
that.  Google put RFC numbers in theirs too.

Alex

>
> Mark
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Mar 2016 16:40:03 +0100

Le 18/02/2016 01:19, Brian E Carpenter a écrit :
> On 18/02/2016 12:52, Tom Coffeen wrote:
>> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong <[email-masked]> wrote:
>>
>>>
>>>>> I believe we should not even suggest that it might be OK to allocate
>>>>> manually. This draft isn't a BCP so we can use normal English, for
>>>>> example:
>>>>>
>>>>> o Prefix generation: prefixes must be randomly generated according
>>>>>   to the algorithms defined in [RFC4193]. There are on-line tools
>>>>>   available to do this interactively, if not performed automatically
>>>>>   by the CPE. Manual assignment of easy-to-remember prefixes must
>>>>>   never be done because of the high risk of collision, recreating
>>>>>   the problems of [RFC1918].
>>>>
>>>> Assume I want to number my lab using ULA. There's no way I'm going to
>>>> be using randomly generated addresses - I want to have an *address
>>>> plan*, and predictable addresses acording to a suitable pattern, just
>>>> as I would do with regular IPv6 addresses.
>>>
>>> You’re supposed to randomly select a /48 from fc00::/7
>>>
>>
>> My understanding from RFC4193 is that the L bit (8th MSB) is not yet
>> defined (i.e., not "locally defined") when set to 0. Should this impact at
>> all one's confidence in allocating /48s from fc00::/8?
>
> You should only allocate in fd00::/8. fc00::/8 is reserved for future use.
> I think this detail should be added to the IANA registry, which only
> mentions fc00::/7 .

This fd00 vs fc00 ULAs should be clearer than is now and if IANA can 
help then let's ask.

The fd00 vs fc00 difference is too hard to explain for someone who needs 
an address to put there now.

In IPv4 it was simple: just use 192.x, or maybe a 10.y address - a 
simple incantation.

In IPv6 it needs meetings after meetings to explain something that is so 
simple in fact.

Alex

>     Brian
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>