In message <[EMAIL PROTECTED]>, Pekka Savola
writes:
>On Sun, 9 Jun 2002, Ralph Droms wrote:
>> problem. A router can't know when it's forwarding a packet outside of a
>> site unless it's been configured with information about site borders. So
>> network architects and admins have to define what makes up sites and
>> configure the routers at the borders to know about those site
>> borders. And, I don't think there's a good way to define default behavior
>> or auto-discovery for site-local addressing...
>
>Precisely.
Yup -- and now we're elevating it to an architectural principle.
>
>> I don't see much difference between RFC 1918 addresses and site-local
>> addresses in the areas of network design and deployment...
>
>Me neither. More probable outcome is that someone starts to request that
>people implement NATv6, because 1) they're already used to it (and like
>its "security") in v4 world, and 2) they think it's easier for them to do
>NAT than to renumber.
>
>Site-locals were born in the era that not all sites had internet
>connectivity. Now that assumption is not all that valid anymore. It's
>just easier for people to use a global address block (even if we define
>that address block to be 3ffe:eff3::/32 or whatever) even with these
>"internal needs" (note: I believe there should be _something_ that does
>not require you to fill any kind of paperwork).
>
Yah. Let's pick a prefix, and tell folks to pick a random number (more
precisely, use an RFC 1750-compatible RNG) to fill out the rest of the
high-order bits to a /48 or a /64. We encourage ISPs to provide real
prefixes to companies that are using application-layer gateways, and
hence don't "need" a routable prefix. We promise two months of
connectivity to folks using non-conflicting random prefixes when they
connect, while they renumber. We think of other, creative solutions
that exploit the fact that we have a really large address space that
we're not going to exhaust.
In short, that we do *something* that isn't going to cause long-term
architectural and operational pain.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
