Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations

[Alexandru Petrescu <[e-mail]>]

Le 21/07/2015 18:28, Mark Andrews a écrit :
>
> In message <[e-mail]>, Alexandru Petrescu writes:
>>
>>
>> Le 21/07/2015 16:53, Brian E Carpenter a crit :
>>> On 22/07/2015 02:18, Alexandru Petrescu wrote:
>>>> 1. Brian suggested to recommend that globals should be there on
>>>> the machines having ULAs as well, if I understand correctly.
>>>>
>>>> But I think so only on some Hosts, mainly the Hosts of end users.
>>>
>>> All hosts that need external communication.
>>
>> I agree, all hosts that need external communication.
>>
>>
>>>> 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC
>>>> address.  That sixxs implementation does it.  Except it takes it
>>>> too serious: it does not accept a MAC address which is not a real
>>>> MAC address - in that oui.txt.  And random MAC addresses (for
>>>> privacy) certainly are not in that oui.txt.
>>>>
>>>> I think this is an undesirable situation to be in: unable to
>>>> generate ULAs because the only tool out there (sixxs) can't refuses
>>>> a copy paste a MAC address from the widely used windows 7 laptops.
>>>
>>> That isn't a standards issue, but I agree that operationally, there
>>> needs to be a viable way for anyone to generate a random number. Wait
>>> a minute, that doesn't seem hard.
>>
>> It's easily done centrally, but in a distributed manner it's harder -
>> how am I sure the network I connect to has ULAs generated such that they
>> dont clash with mine?
>
> *YOU* generate you ULA properly.

You for single or plural?

Until now I was saying to my peers: I take 192.168.1.1 please take 
something else and I'll route to you.

Now I am saying: generate ULA properly, make it truly random.  But how?

>>>> I am not sure what the problem is, but it's very good to have a
>>>> very easy way to generate ULAs.
>>>>
>>>> 3. in an enterprise deployment there was a problem of ULAs deployed
>>>> in a intra-network and another ULA space in another intra-network,
>>>> of the same enterprise.  So we wanted to make sure two things: the
>>>> two ULA spaces are distinct, or otherwise make sure the gateway
>>>> router does not route between the two intranets' ULAs (but yes,
>>>> route between their respective GUAs).
>>>
>>> Why not? ULA to ULA routing on a private link might be desired (e.g.
>>> after two networks merge without renumbering). From a routing PoV
>>> there is nothing special about a ULA prefix; we just need to
>>> configure carefully where it is routed and where it is not routed.
>>
>> Yes, private routing should be ok, but only if these ULAs are unique.
>> If people on different networks use different generation methods then
>> it's dubious to be sure of the uniqueness.  Maybe I choose fd00:1::/64
>> being sure that no random generator will make it, and it happens my
>> neighbors does the same.  That leads to conflict on fd00:1::/64 and we
>> dont want routing enabled between the two.
>
> Generate.  Don't choose.  If you generate then you should be ok.

Ok.

But it's much easier to choose.

We want simple ULA addresses, simple to remember, simple to type, 
ideally based on a dictionary.

This is something everybody building even the simplest IPv6 network has 
to do: what simple ULA IPv6 addresses to put there to not break something.

Alex

>
>>> Anyway - I'd like to see the draft progress. Has it already had a
>>> WGLC?
>>
>> I agree, it already has advice in it worth progressing.
>>
>> Alex
>>
>>>
>>> Brian
>>>
>>>> I am not sure how to translate that into advice, because I am not
>>>> sure how it will unfold in the near future.
>>>>
>>>> Alex
>>>>
>>>> Le 21/07/2015 16:02, Fred Baker (fred) a crit :
>>>>> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations
>>>>>
>>>>>
>>>>
>>>>>
>> "Considerations For Using Unique Local Addresses", Bing Liu, Sheng
>>>>> Jiang, 2015-05-03
>>>>>
>>>>> This draft came up from the floor this afternoon. I think we
>>>>> need some concentrated constructive conversation regarding it -
>>>>> we have had a lot of the other kind.
>>>>>
>>>>> What issues do we need to address to complete it. and what
>>>>> specific recommendations would that include?
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ v6ops mailing
>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>>
>>>> _______________________________________________ v6ops mailing list
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>