Register 200::/7 with IANA and IESG?

[agowa]

Hi, are there plans to register the used prefixes 200::/7 (and maybe also 300::/8 as more specific separate allocation) with IANA Internet Protocol Version 6 Address Space?
Doing so would require IESG Approval IESG Members.

This would be necessary to avoid future standards from conflicting with yggdrasil as well as to show that the 200::/7 is not just for the in 2004 deprecated OSI NSAP-mapped prefix set RFC4548.

Also on another note, have you considered looking into the RFC3972 Cryptographically Generated Addresses, RFC7343 ORCHIDv2, or in more general way Host Identity Protocol? These standards, and ORCHIDv2 especially, could be a big help to this project (Note, ORCHIDv2 already has an assigned prefix of 2001:20::/28 and is designed for overlay routing).

[neilalexander]

We have no plans to attempt to register address space at this time.

There are a few reasons for this:

1. IP addresses are largely meaningless in the Yggdrasil protocol design itself — the native identifier for a node is its public key and the translation between IPv6 addresses and public keys is mostly a convenience function so that existing IPv6-capable software can work unmodified;
2. It's not clear that the allocation of an entire /7 or /8 (even if it is from deprecated space) is justifiable to an experimental project that has had absolutely no prior interaction with the IANA and doesn't perform any of its design activities through the recognised RFC process;
3. We don't know that Yggdrasil's future is constrained to IPv6 translation and the 200::/7 range.

CGAs refer mostly to link-local address assignment and ORCHID-style allocation is perhaps more interesting if not for the significant loss of public key bits in each address going from a 200::/7 to 2001:20::/28 and a rather uncertain collision risk.

[agowa]

Understood. But it probably also wouldn't hurt to just send the iesg a mail to inform them about the existence of this project and the use of the 200::/7.
And as ORCHID already exists. Maybe others have also a need for more public key bits within the address? That way the 200::/7 may become the new 2001:20::/28? At least it has the potential to become an real world and a somewhat bigger implementation of this standard.

Also at least from my point of few keeping compatibility with IPv6 is desirable even if it is "just" so that it can be integrated into sites by using all of the established IPv6 software, standards and protocols, like e.g. with routing. Also don't underestimate the value to new "network admins" that not yet have their own AS and address space allocated and want to experiment with routing and peering. The current design of yggdrasil by "free of charge" allocating an (at least within yggdrasil) public ipv6 that can be used to toy with BGP and "advanced stuff".
It's just more satisfying to use yggdrasil than to use some other random prefix that won't be reachable from anywhere else and thereby also hide some errors. Basically with yggdrasil you only need a standard "advertising prefix" setup as the upstream router. Without changing anything else and it will be actually functional/reachable (at least for everyone that also uses yggdrasil ofc).

Btw, regarding CGAs. As yggdrasil is an overlay. Technically it could be seen as link-local. But on 2nd thought it will only work for the /128 from the 200::/8 only and would require some addition to also provide the subnets from the 300::/8...

And technically the fc00::/7 (ULA) range could also be an option. It is already defined as "mostly unique" ("Private internets") but may have issues with address selection as it is lower priority than IPv4 in many cases (but one may say that that's even desirable as it won't cause applications trying to reach GUA addresses to try to use yggdrasil addresses as their source address). We probably wouldn't even have to change anything about the address generation to align with that standard.

[majestrate]

technically the fc00::/7 (ULA) range could also be an option

An anecdote: historically (if i recall it correctly) the use of 200::/7 was done at my suggestion instead of fc00::/8 so that people could run both yggdrasil and cjdns since cjdns uses that.

I don't think anyone in the project is in a position to contact IESG Members and tell them we're squatting on 200::/7 that would come off as a bit jarring.

(yes this was my "fault")

[agowa]

contact IESG Members and tell them we're squatting on 200::/7 that would come off as a bit jarring.

The horse kinda already left the barn on that one. However NOT informing and talking to them and someday potentially having some yggdrasil users shout at them for breaking the project (without them even knowing it exists) when they reassigned that address space to something else that may also get wider adoption is probably way way way worse...

I think "coming clean" early is better and more appreciated then doing so once everything is on fire (and the yggdrasil user base also has increased significantly over time then probably, so IF decided to switch it would be way worse then too).

@majestrate would you yourself be willing to contact the IESG Members? Or maybe even better write to the WG mailing list first, as it probably will end up there for discussion and feedback anyway.

Relevant WGs are probably "Routing Area (rtg)" and "Internet Area (int)" but writing to either one of them is probably enough. The topic here is kinda in between these two working groups. I'd suggest going with int as "identifier-locator separation" is part of their agenda already. So Yggdrasil would fit right in.

[majestrate]

I wouldn't feel right being the guy in charge of contacting some standards body as I am only tangentially affiliated with yggdrasil as I run public peers and have a technical opinion occasionally. That being said, feel free to CC me in any discussions relating to this manner.

[Saiv46]

@majestrate Hi, I'm not a guy affiliated with Yggdrasil development either. But I joined v6ops IETF mailing list in 2021 and told about our project. You can see archived messages here.

Also my apologies to @neilalexander for introducing it like that.