On 8-nov-04, at 14:28, Bill Manning wrote:
RIRs will apply a minimum size for IPv6 allocations, to facilitate prefix-based filtering.
The minimum allocation size for IPv6 address space is /32."
the "problem" is that folks seem to have a different take on the word FACILITATE in the above section.
If you mean that the RIRs don't tell people they must or even should filter, that's of course true. Quite the opposite: RIRs are very reluctant to tell people what to do (except jump through enormous amounts of administrative hoops, of course).
However, I take the text I quoted to mean "it's ok to reject all prefixes longer than 32 bits". And I don't see how any other meaning could make sense.
facilitate != mandate.... e.g. one could expect that delegations made from the RIRs -when this policy was/is in force- to be on /32 alignments.
Yes. Which the microallocations aren't.
for delegations made under different regimes, the delegation sizes may be different... like the /35s that were popular from the RIR community before the /32 agreement was reached. Or the /48s that predated the /35s...
Don't you agree that IF it's possible for prefixes longer than a /32 to show up in the IPv6 routing table by design (= not because of some uni/bilateral operator action), then the section that I quoted doesn't make sense and leads people to do the wrong thing?
it is important to remember that neither the IETF nor the RIR can manage/conserve the entries in anyones routing/forwarding tables.
No, but the RIRs can sure get in the way. For instance, RIRs have certain minimum allocation sizes in certain IPv4 address blocks. But they also give out larger blocks from those ranges. (I.e., if the minimum for 96.0.0.0/8 is a /21, they also give out /19s and so on from that block.) This means operators only get to filter on the minimum and anyone with more than the minimum gets to deaggregate to a certain degree. If they would use a fixed size for each of their blocks instead, people who want to filter out deaggregated blocks get to do so.
This is just one example.
The IETF (imho) should confine itself to protocol work,
So are you saying the operations and management area should go away? Historically, the IETF has done a lot of non-protocol work.
The RIRs should confine themselves to being wise stewards of the addressing
resources, and the ISPs need to worry about the operational coordination of routing... such is not the perview of either the IETF, the IANA task,
or the RIRs. ....
Unfortunately address policy sets limits on what operators can do, so it's never going to work this way. And since all of this stuff is going to end up in routing tables world wide, regardless of the point of origin, it really makes no sense to decide on address policies for each region individually.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf