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

[Nick Buraglio <[e-mail]>]

Sigh. I sat on this for a bit while offline and clearly I still have
vacation brain.
A few of us have a draft that hasn’t been submitted yet that proposes
0200::/7 as for use as a lab prefix. I’m conflating this thread with our
other draft that was submitted (expanded documentation space). The 0200::/7
triggered my thoughts, and now I more clearly understand why the responses
were perplexing to me - I'm talking about something only a few folks have
seen! =)

Carry on, I'll be quiet for a bit now.
nb

On Tue, Jun 1, 2021 at 6:25 PM Brian E Carpenter <
[e-mail]> wrote:

> 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>
> >
>
>