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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf