> > > >>> | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits |
> > > >>> +--------+-+----------+---------+---------+----------+
> > > >>> | Prefix |L| Reserved | RIR Num | LIR Num | User Num |
> > > >>> +--------+-+----------+---------+---------+----------+
>
> Something that has been overlooked is the number of bits in each section.
> How was this number determined?
i made it up. beer was involved.
> Is it the right number of bits for each level?
almost certainly not.
> Is there a technical reason for sticking with octet boundaries here?
no. (though nibble boundaries are awful nice for operations folks.)
> Does there need to be an actual boundary between the RIR and LIR section at
> all?
i don't think so. an RIR can allocate blocks-of-adjacent-blocks to LIRs.
> I think that the RIR section has too many bits (there are 5 of them) and
> the LIR section has too few.
you sound like a man ready to make a well reasoned counter proposal. great!
> It seems to me that the boundary between RIR and LIR should be left
> unspecified. IANA can allocate chunks of whatever size is needed to RIRs
> as those needs arise.
ok by me. how's this?
| 7 bits |1| 12 bits | 24 bits | 80 bits |
+--------+-+---------+-----------+----------+
| Prefix |L| RIR Num | Local Num | User Num |
+--------+-+---------+-----------+----------+
this would have IANA handing out blocks of /24's to RIRs who could hand out
/48's to end users or blocks of /48's to LIRs (who would then hand out /48's
to end users). as long as an end user is receiving a /48 and the top 7 bits
are distinctive, it doesn't matter as much what the "middle" looks like.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
