I'm not sure we need to debate the subnet vs. bridging
question. Of course bridging will go a long way; yet I
don't think anyone on this thread wants to claim that
we should limit home networks to it.
The crux of the issue is the unpredictability of what
will happen with technology, a particular type of a
site, and a specific user. We give an allocation to
someone right now, what will happen in five years?
How big has his network grown, and what technology
does it use? If we guessed wrong and gave the user
too small prefix, there will be pain -- new requests
for space to the ISP, restricted growth of the user's
network, renumbering, multiple routing entries
instead of one, etc.
If we guess wrong the other way and give the user
too much, this either does not matter at all, or we
waste addresses, depending on whether the
allocations cause actual address shortage. It is
obvious that allocations need to be tailored
to the need -- I don't want DSL users assigned
as many addresses as providers or multi-national
corporations get. But the question is at what
granularity are we doing this, and at what point
do we stop caring about the details? Personally,
I think the 48 bit boundary works pretty well and I
do not see a real-life reason to worry about address
shortage. Having said that, something slightly more
fine grained would work too, e.g., 48 or 56, or
what Iljitsch proposed. Tuning the policy every
few bits seems unnecessary, IMHO.
A couple of relevant IETF links:
http://tools.ietf.org/html/rfc3177
http://tools.ietf.org/id/draft-narten-ipv6-3177bis-48boundary-02.txt
(currently in state Dead)
Finally, I hope this thread does not stay only within the
IETF list and that some of you actually voice your opinions
in the ARIN process. (But as Tony noted, ARIN just makes
policy with respect to how it hands out addresses -- its
the actual providers that sell the service to customers.
Neither the IETF or ARIN have direct control of this,
though of course we like to encourage ease of address
allocation.)
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf