Re: [v6ops] Reused deprecated prefix (0200::/7)

On 03-Jun-21 10:45, Fred Baker wrote:
> The writer indicated that some of the addresses in question were being used for business-related traffic. If that's the case, it should be a prefix allocated according to standard procedures, not squatted on.

The way Yggdrasil is designed, that would only work if the IETF instructed IANA to give them a /7.

    Brian

> 
>> On Jun 1, 2021, at 3:16 PM, Nick Buraglio <buraglio@es.net> wrote:
>>
>> I agree, and pretty much my point. The project is self described as "proof-of-concept", and as it appears to be  using a deprecated range within a private overlay, it should not in itself be an impediment to this draft.
>>
>> nb
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 5:01 PM Mark Smith <markzzzsmith@gmail.com> wrote:
>>
>>
>> On Wed, 2 Jun 2021, 07:54 Nick Buraglio, <buraglio@es.net> wrote:
>> Did we ever see a response to this? My take is that if the prefix is not being used for its original intended purpose, then it is functionally squatting on deprecated address space. A read of the project notes looks as if it is still pre-production code similar in nature to ZeroTier or the Slack nebula, the former of which is able to leverage both rfc4193 and 6plane as its addressing schema. While no one can expect to control what is used on private networks and projects, I don't see this particular issue as a show stopper for this particular draft, assuming this is in use as a private addressing schema and not as rfc4548. Based on the site, that 
appears to be the case:
>>
>> Yggdrasil uses the 0200::/7 range, which is a range deprecated by the IETF. It has been deprecated since 2004, pending changes to an RFC which simply never materialised 14 years later. It was decided to use this range instead of fc00::/7 (which is more typically allocated to private networks) in order to prevent conflicts with existing ULA ranges.
>>
>> This last statement doesn't make sense and isn't justification for using this deprecated range.
>>
>>  ULAs have a 40 bit random number in them "to prevent conflicts with existing ULA ranges."
>>
>>
>>
>> nb
>>
>>
>>
>> On Sun, May 23, 2021 at 3:51 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> Alexander,
>>
>> Do you mean that the prefix is being used as specified in RFC1888 or in some other way?
>>
>> On a technical detail, the prefix is marked as "reserved" by IANA. The 
logic for that is that if anybody is using 0200::/7 on the public Internet for its original experimental purpose, it cannot also be used for any other purpose. What is "deprecated" is the method in RFC1888.
>>
>> Regards
>>    Brian Carpenter
>>
>> On 23-May-21 21:47, Александр
>> Иванов wrote:
>>> Hello, v6ops maillist members,
>>>
>>> I want to talk about the 0200::/7 prefix, which is officially deprecated (RFC4048), but actually used from 2017 to now.
>>>
>>> There's a project called Yggdrasil Network - a self-arranging encrypted
>> IPv6 network (https://yggdrasil-network.github.io/) <https://yggdrasil-network.github.io/)> which utilizes this deprecated prefix ...and its network already has members that use it for business purposes.
>>>
>>> How do you think about allocating that prefix as a software-routed global unicast address? A future RFC can be merged with draft-horley-v6ops-expand-doc-00.
>>>
>>> I highly appreciate any feedback and help for new to the IETF.
>>>
>>> Regards,
>>> ~ Alexander Ivanov, Russia
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 