On Mon, 11 Jun 2007 17:28:07 +0200
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
> It seems that what you describe is a prime candidate
> for metro addressing, not for ULAs of any kind. And a metro
> prefix is not really any different from a PA prefix, except
> that it's assigned to a municipality.
>
> ULAs should be kept in-house, literally.
>
While I'm guessing it is way to late to change the name, I've realised
that they probably should have been called "Unique Internal Addresses".
Unfortunately most non-networking people probably won't realise that
"Local" in ULA means local to your network's administrative domain,
however big or small that is.
> Brian
>
> On 2007-06-11 16:21, Paul Vixie wrote:
> >> I suppose most of these users will have big (actually a quite small) flat
> >> infrastructure to keep it simple? Hence what limits them to use just LL?
> >> Why ULA? What would be the residential users benefit? Do you think that
> >> residential users will have small routed networks in the future?
> >
> > i think that the distinction between "provider" and "consumer" will blur in
> > the following ways.
> >
> > first, if everybody in the neighborhood has overlapping wireless clouds, so
> > that neighbor-sets {A B} {B C} {C D} can join clouds owned by neighbors A,
> > B, and C respectively, that D's preferred path to A will in some cases be
> > through C and B rather than through their "providers". this is not just
> > because their providers might not have as much in-neighborhood capacity due
> > to backhauling and provider multiplicity, but because this is the topology
> > many human communities prefer. consider the legal implications for file
> > sharing when there is vs. isn't a "provider" which is regulated and subject
> > to CALEA, as a low hanging example.
> >
> > second, with COMMONS and things like it sprouting up, there will be networks
> > built using city-owned infrastructure where virtually all traffic into/outof
> > that city has a city-owned last mile. the need for a "provider" will only
> > be
> > truly notable for traffic into/outof that city, and it will be impractical
> > for economic reasons ("anti-lockin") to use "provider assigned" addressing.
> > the city would have to become an LIR in today's model. ULA and ULA-C could
> > change all of that, in a bad way, by either requiring a city to run a giant
> > NAT-PT box and breaking end-to-end on intercity traffic, or by requiring the
> > "provider" to do so, or by requiring the "provider" to import ULA routes.
> >
> > to your last question, i do think that residential users will have small
> > routed networks in the future, rather than a flat neighborhood-wide or even
> > city-wide L2, simply because the broadcast domain for things like Bonjour
> > will be too large otherwise, and the market seems to have embraced "routers"
> > as their preferred security perimeter (vs hosts, bridges, or repeaters.)
> >
> > (these are the wages of our sins from not separating routing from identity,
> > and from assuming that the economic principles underlaying IPv4 routing
> > would still apply in an IPv6 world.)
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email protected]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
