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.
 
> 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).

> At 09:04 AM 6/9/2002 +0300, Pekka Savola wrote:
> >On Sun, 9 Jun 2002, Bill Sommerfeld wrote:
> > > > - With an RFC 1918 host behind a firewall, compromising the firewall is
> > > > enough to grant that host outside access. Single point of failure.
> > > >
> > > > - With a site-local only host behind a firewall, this become a double
> > > > hack thing: you need to reconfigure the firewall _and_ reconfigure the
> > > > host to give it a public IP.
> > >
> > > Why do you believe this makes a difference?  Wouldn't site-local
> > > traffic be just as likely to leak into an ISP as RFC1918 traffic?
> > > Better isp's will filter it out in their border routers; others won't
> > > bother.
> >
> >Well, addr-arch states that routers MUST drop traffic with site-local
> >source address at the edge of a site.
> >
> >But as site is rather vaguely defined, I think many vendors just skip this
> >little detail..
> >
> >--
> >Pekka Savola                 "Tell me of difficulties surmounted,
> >Netcore Oy                   not those you stumble over and fall"
> >Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> >
> >--------------------------------------------------------------------
> >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]
> --------------------------------------------------------------------
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to