with all due respect. rfc 1918 was a hack and never would pass the IESG today IMO they are doing a far better job these days causing us to detail our network views and development of protocols. 1918 has wrecked the Internet. /jim
> -----Original Message----- > From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]] > Sent: Sunday, June 09, 2002 10:17 AM > To: Pekka Savola > Cc: Ralph Droms; [EMAIL PROTECTED] > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
