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

["Eric Vyncke (evyncke)" <[e-mail]>]

Humm it smells like HIP and the RFC 7343 Orchid prefix 2001:20::/28

-----Original Message-----
From: v6ops <[e-mail]> on behalf of Brian E Carpenter <[e-mail]>
Date: Wednesday, 2 June 2021 at 01:26
To: "[e-mail]" <[e-mail]>, Mark Smith <[e-mail]>
Cc: v6ops list <[e-mail]>, Александр Иванов <[e-mail]>
Subject: Re: [v6ops] Reused deprecated prefix (0200::/7)

    To which draft? I'm not aware of an Yggdrasil draft.

    Note that they use all 121 bits after the /7 prefix, I think for cryptographic reasons. So a ULA prefix wouldn't actually do what they want, as I understand it.

    Regards
       Brian Carpenter

    On 02-Jun-21 10:16, Nick Buraglio 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 <[e-mail] <mailto:[e-mail]>> wrote:
    > 
    > 
    > 
    >     On Wed, 2 Jun 2021, 07:54 Nick Buraglio, <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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/>) <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
    >             > [e-mail] <mailto:[e-mail]>
    >             > https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
    >             >
    > 
    >             _______________________________________________
    >             v6ops mailing list
    >             [e-mail] <mailto:[e-mail]>
    >             https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
    > 
    >         _______________________________________________
    >         v6ops mailing list
    >         [e-mail] <mailto:[e-mail]>
    >         https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
    > 

    _______________________________________________
    v6ops mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/v6ops