> > where "Prefix" and "L" are defined as shown in central-02, and the other > > fields are defined as follows: > > striks me as almost the same as the good old sTLA...
as with many other old things that become new, we know a lot more now about what we're trying to do than we did before, and the "almost" is important, this isn't sTLA. > > third, replace section 7.0 with the following: > > > > --- > > > > 7.0 IANA Considerations > > > > IANA is hereby instructed to reserve address block FC::/7 for private > > unique addresses, and to allocate /32 blocks to Regional Internet > > Address Registries (RIRs) who request same after adopting policies > > consistent with this specification. Allocation shall be similar in > > all ways to normal IANA address allocation to RIRs, including but not > > limited to IN-ADDR.ARPA delegations and WHOIS records. > > > > --- > > so we are talking about full reverse control delegated to the person that > get this ULA-C block? yes. > except this piece about DNS mention above it look more promissing than the > original draft. fred templin has made a compelling case here that the ad-hoc nature of ULA-C routing precludes the normal "put override configs in every resolver" logic described in RFC 1918. for PTR lookups to work in fred's case, there has to be global DNS. note that global DNS isn't a requirement -- anyone with ULA-C who prefers to use RFC 1918-like overrides in all their own resolvers can do that. the instructions in the replacement for section 7.0 above are there to ensure that those who want their ULA-C PTRs to be in the global DNS can have that. (if you don't like it, then don't use it, but don't tell others they can't have it either, please. if they want it, let them have it, please.) -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
