Subject: RE: Limiting the Use of Site-Local

From: "Bound, Jim" <[email-masked]>
Date: Mon, 28 Oct 2002 12:42:11 -0500

Michael,

Comments below.

/jim
[Have you ever seen the rain coming down on a sunny day]

> 
> Margaret,
> 
> > Besides, it would be possible (although perhaps not
> > adviseable) to enforce this restriction.  Nodes could immediately 
> > deprecate site-local addresses whenever a global address is 
> > configured.
> 
> I think this is a terrible idea. I can envision many 
> situations where a host would need both a site-local and a 
> global address.

I think this is a wonderful idea and would like to see it applied to src
address selection as MUST.

> 
> 
> > In fact, I am suggesting that all routers and hosts treat 
> site-local 
> > unicast addresses exactly like global unicast addresses, 
> and that we 
> > administratively restrict the use of site-local unicast 
> addresses to 
> > non-globally-connected networks.
> 
> I am comfortable with this. It's roughly what we do with 
> RFC1918 addresses today, and it has worked fine for many 
> people. Link-locals are not routable, but site-locals are 
> within the site, and since hopefully nobody will invent IPv6 
> NAT, filtering site-local addresses at the edge of the site 
> seems the appropriate solution to me.

RFC 1918 has caused a disaster in most networks that want e2e out of the
site because NAT is required.  1918 was a band-aid because of shortage
of IPv4 address space and because we did not get IPv6 done quick enough.
I want SLs removed precisely because of what I have seen from 1918.  I
am speaking of the user of private addresses not CIDR.  That was a good
idea but actually illegal with IPv4 IMHO.

/jim

> 
> My $0.02
> 
> Michel.
> 
> 
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------
> 

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

---

From: Mark Smith <[email-masked]>
Date: 29 Oct 2002 10:52:11 +1100

Hi All,

> address selection as MUST.

I agree.

When I first put NAT in place for a customer (way back in 1995), I
thought it was great ... until we tried to push Netbios packets through
the NAT device, which it didn't understand. It was only after
understanding what was happening did I realise the issues with NAT, at
which point it was too late.

The problem with NAT today is that it appears to work, and appears to
work well. It is only getting "better" as more and more application
handing code is put in NAT devices. By the time you find its
limitations, it can be too costly to replace, either in terms of time,
money, or just trying to motivate the "powers that be".

I'd hate for the same thing to happen with SL under IPv6.

While a number of people are posting to this list showing how Site
Locals could work in conjunction with Globals, I think the question is
just because SLs could work with Globals, _should_ they work with
Globals ?

In my experience, most network admins today tend to have a view that if
it appears to be working, it must be ok to use it that way. I fear that
SLs and Global combinations will fit into this category.

Non-obvious reasons to avoid it just aren't a factor. I've met very few
network admins that have ever read BCPs, let alone know they exist.

I'd like to see the combination of SLs and Globals fail as per
Margaret's suggestion. If necessary an override switch could be put in
the device to disable this behaviour.

At least this would provide a higher hurdle for less informed net admins
to jump when trying to implement something that isn't the best thing for
their network.

Mark.