[retronet] RetroNet globally-routable address allocation policy

[Grant Taylor]

On 09/02/2018 01:22 PM, Michael Kjörling wrote:
> I think it makes sense to allow for allocation of address space in 
> different protocols. If we agree on that, then the only issue is the 
> allocation strategy.

I don't think there is a strict reason other than uniformity to make 
things easier for humans.

> If there is no strong reason that all allocations must use an identical 
> network number, which they can't anyway (cough decnet cough), then they 
> probably don't need to be allocated all together, or identically.

Fair point.

> I'm not too familiar with IPX network addressing, and couldn't quite 
> wrap my head around it based on the little recent discussion here, 
> so I figured I'd cover all the bases. :)
> 
> Looking again at RFC 4193, it seems I misremembered slightly; it has 8 
> bits of IPv6 prefix, followed by a 40 bit "global ID", followed by a 
> 16 bit "subnet ID", followed by the 64 bits interface ID. By picking 
> one or two 40 bit global IDs for RetroNet according to the method 
> described in that RFC, each 16-bit member number can map to one /64 by 
> default. That doesn't allow for subnetting that allocation further, 
> but additional allocations can be requested as with other protocols.

Aside:  I've subdivided a /64 without any problems before.  I think the 
issue is around some things like SLAC not working correctly on something 
other than a /64.

> One global ID could be for "subnet ID is member number", the other could 
> be for extra assignments.

True.

> There's link local, but that's really _link_ local, akin to 169.254/16 in 
> IPv4, as opposed to RFC 1918 which can be routed. Routing of link-local 
> traffic "to other links" is expressly forbidden.

Ya.  That's why I was looking at "site local" and what I thought was 
"enterprise local".  (I'm using the wrong term, but I thought there was 
something larger than site that would apply.)

> Yeah, I'd really rather avoid appropriating some random currently-unused 
> portion of the address space.

Yep.

> Actually, yes and no.

Okay.  /me puts on his reading glasses and thinking cap to learn from 
Michael.

> I'm not arguing that RetroNet traffic should be routed outside of 
> RetroNet. So I firmly believe that we're in agreement there. If RetroNet 
> is to serve as a safe playground or experimentation network, then it 
> should be contained.

100% agreed.

> However, I don't think it would be fair to assume that no RetroNet host 
> will ever benefit from being able to _also_ route traffic to and from 
> the Internet, if for no other reason then to tunnel traffic to other 
> RetroNet hosts for RetroNet routing purposes.

Okay.

I think I failed to properly articulate what I was meaning.  I'll try 
again.  Please keep me honest or question me if you see flaws in my idea.

Quick aside:  RetroNet is functionally two things; virtual circuits and 
service provider.

I want the RetroNet Service Provider (RNSP if you will) to NOT transit 
traffic for non-RetroNet addresses.

That being said, RetroNet Virtual Circuits (RNVC if you will) will 
easily provide virtual circuits, a.k.a. tunnel, between two members 
(independently of RNSP).  These virtual circuits will be under the 
complete control of the two members and completely independent of RNSP. 
So the members are free (and encouraged) to run what ever they want to 
over said VCs.  (I have previously referred to these Virtual Circuits as 
Virtual Private LANs as in VPLS.)

Aside:  The desire to support such a topology is one of the reasons for 
specifically choosing MPLS as a core transport, the ability to have 
multiple virtual circuits between members.

With this in mind, I'm still of the opinion that RetroNet Service 
Provider should not be a transit network for non-RetroNet addresses.

RetroNet will help and encourage the communications path to directly 
connect two (or more) members, independently of RetroNet Services.

How does that sound?

> So it's not so much hosts multihomed on RetroNet (those could be covered 
> by having multiple assignments within RetroNet space), as it is about 
> hosts that have connectivity to both RetroNet _and_ the Internet.

Okay.

I think such "gateway" systems are worth talking about.  There has been 
discussion of the RetroNet Service Provider running some gateways (SMTP 
smart host, HTTP(S) reverse proxy, NNTP feed, etc) exactly like this.

I don't see any reason that members can't run such gateways themselves 
if they want to.

I do think we, the RetroNet community, need to collectively monitor and 
report problems / abuse so we can resolve it as early as possible to 
keep RetroNet as friendly as possible.

In short, I feel no reason to prevent or dissuade such gateways.  I 
don't know how to handle them at this time, so I suggest proceeding with 
caution.

> If we're willing to rule out the possibility of RetroNet hosts also having 
> Internet connectivity, then all of the address space in each protocol is 
> available for assignment, and there is no need to limit to, for example, 
> only 100.64/10 in IPv4.

I agree that you are technically accurate.

That being said, if there are simple best practices that we can do 
inside of RetroNet, like using 100.64.0.0/10, I think we should do so.

I think that this also enables members to have an idea that 
100.64.0.0/10 is a RetroNet IP and not something for the open Internet.

> So, I guess this boils down to: Is the idea for RetroNet hosts to be 
> able to participate on the Internet, or should any host that exists 
> on RetroNet be completely isolated from the Internet? If the latter, 
> how to route traffic between RetroNet hosts?

I think I've answered this.  Please let me know if I have not.

TL;DR:  RetroNet should NOT be a transit.  Well behaved Application 
layer gateways between networks are okay.

> Site local was described in RFC 3513, and later deprecated by RFC 
> 3879. It used a 10-bit fixed prefix of fec0::/10 plus a 54-bit 
> locally assigned "subnet ID".

*nod*

I think RetroNet could easily fall under the guise of a "site".  Or at 
least the larger "site" being the ""enterprise that is RetroNet and 
using subsets there in for member "sites" / networks.

> Link-local is similar, except it uses fe80::/10 with all subnet ID 
> bits set to zero, hence the oft-seen fe80::mmmm:nnnn:oooo:pppp/64.

ACK

> The big problem, from my understanding, is that nobody ever defined what 
> constituted a "site".

Agreed.

I feel like we are effectively using two different definitions for site:

1)  RetroNet "enterprise" network.  -  Umbrella that encompass everything.
2)  Member "site" network.  -  Member's network on their premise.

> RFC 4193 is fc00::/7 with a grand total of 48 bits global ID (including 
> the 8 bits of IPv6 prefix) and another 16 bits subnet ID, as discussed 
> above.

ACK



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.chivanet.org/pipermail/retronet/attachments/20180902/977fe8ec/attachment-0001.bin>