Jeroen Massar <[EMAIL PROTECTED]>: > > Paul Vixie <[EMAIL PROTECTED]>: > > > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > > +--------+-+----------+---------+---------+----------+ > > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > > +--------+-+----------+---------+---------+----------+ > > Looks okayish but does bring back the idea of sTLA's a bit. But there is > another thing that this causes: it sort of allows aggregation.
i'd say deliberately not. if LIR's receive /48's then when they hand out address space to end sites it'll be in groups of 5 and 10 /64's. we can add text recommending that RIR's and LIR's deliberately randomize or skip even/odd or something to prevent accidental or opportunistic aggregation, though. > How is this any different at all from what I proposed in another > message: One setups an organization called "Local IP Addresses Org" and > sets up an LIR, requests a /32, one one has 65k /48's to provide to > endusers. you are so prolific here that your own words got lost in your own torrent? > Members have a share in the org, and each and every single one > of them can already make sure that the LIR fees are paid (there are no > equipment or transit etc fees) and presto. You have EXACTLY what you > have above, but with the added benefit that it is globally unique > address space with full RIR support. except that payments and shares are out of scope, you might be right. > Another problem with the above is that it doesn't allow for direct > end-user assignments. Folks still have to go through a LIR. This thus > doesn't provide these people with a "direct assignment" and they are > still bound to the LIR. then you didn't read my text, because it says the opposite of that assertion. > As such, if you really want to have ULA-C (which I really think is > unnecessary because of arguments I've reiterated a couple of times > already also in other messages and the above) I would at least propose: > > | 7 bits |1| 8 bits |16 bits| 16 bits | 16 bits | 64 bits | > +--------+-+--------+-------+---------+-----------+-----------+ > | Prefix |L|Reserved|RIR ID | Site ID | Subnet ID | Iface ID | > +--------+-+--------+-------+---------+-----------+-----------+ > | /48 for the end-site | > +-----------------------+ i don't use /64's for my links. EUI64 is going to die, and die hard. let's not overspecify the mantissa. i said "80 bits for User Num" and i meant that. (if someone wants to use /64's for their links, they can do that under this proposal, but we can't reasonably require it, and the recommendations for it are already present in plenty of other RFCs.) > Same scheme of allocation, but takes out the LIR portion and thus allows > RIR's to delegate this directly to endusers. read my text. direct allocations are already possible. > > third, replace section 7.0 with the following: > > Don't agree at all. (btw it is fc00::/7 not fc::/7 :) i've seen plenty of people say fc00::/7 and i just don't get it. you might as well say fc00:0000:0000:0000:0000:0000:0000:0000/7. when i wrote the reference implementation of inet_ntop(), i only emitted the part of the mantissa that was actually covered by the cidrlen. this isn't scientific notation where you want to show the degree of accuracy of your measurements. > The moment you introduce support for IP6.ARPA (not IN-ADDR.ARPA) and > require delegations to be possible there really is no difference between > PI and this kind of address space (except the prefix from which they are > allocated, they can be filtered on that but still). fred made a compelling case for why ad-hoc ULA-C routing precluded the kind of resolver config overrides that we're supposed to use for RFC 1918. any ULA-C user who doesn't want their PTR's in the global DNS should not put any there, but it's not our place here and now to tell them that they just can't. > If one *really* requires that there will be reverse that is 'automatically > setup' (ignoring that you still have to do it for the forward) then define > in the draft the method that James Woodyatt proposed of using synthesized > reverse records for 0.0.c.f.ip6.arpa. And then simply declaring that the > highest subnet (::ffff:<64bits>) contains at ::53 a DNS server serving > reverse ip6.arpa for that zone. this is attractive, but it's an architectural change that we'd have to review for other connectivity realms, like the DFZ, and i don't want to argue it as part of settling the ULA-C question. if you like this idea, propose it and let's get into its merits and implications. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
