The first question that comes to mind here then is - why would we need a /10 for this? That more than the currently totally allocated address space....My memory of the discussions accords with the summary given by KeithSo the remaining question besides the PI issue would be to define "limit" then?
above. In addition, the general tenor of the discussion indicated to me
that the two issues were linked: that consensus on limiting site-locals
was contingent upon initiation of an effort to design a workable scheme
for privately-routable PIs, with the global routing of PIs left for
subsequent discussion.
I had proposed limiting the use of site-locals to completely isolated networks (i.e. test networks and/or networks that will never be connected to other networks). This would give administrators of those networks an address space to use (FECO::/10) for those networks
that wouldn't conflict with anyone else's and could be filtered by ISPs,
etc. (in case anyone ever makes a mistake and connects an "isolated"
network to the Internet). This is actually what site-local addresses
(and RFC 1918 addresses) were originally invented for...
Yes, but that didn't really stop anyone....
If we limit site-locals to this case, they can be treated _exactly_ likeThe problem I see (and have been beaten to death here) is that people WILL connect them to the Internet. We have applications that can't handle this and that will break, and we will have really hard times implementing them.
globals in all implementations (since they will be global to any network
where they should be used), and all BGP routers could ship with a default
filter to block propagation of these routes (which the administrator
would have modify in the unlikely event that he wanted to use BGP in
his completely isolated network).
I'm working on a draft that explains why I believe that site-localsThe above said - I will agree with you. Personally I think that we should use the opportunity of IPv6 to fix some of the design flaws of IPv4. One of them is that the shortage of address space led us to create RFC1918. We have the opportunity fix this, but there are to many people out there who don't see this as a benefit. As applications that don't work across NATs they will becomes more popular this will change - I remember having a discussion with a VPN customer who was telling me that a great invention NATs was. He then realized that buying VOIP transit from us would have saved him quite a lot of money, but he of course could not get that as he was behind a NAT. I guess they are still trying to figure out to get rid of it...
need to be limited to this extreme, and that draft will provider further
Anyway, although I don't like what you suggest above - I think it is the only think that we can get some sort of consensus for and move on. But I think that we need to learn from the RFC1918 mistake and make sure we include a enforcement method.
details of the proposal. I'm actually NOT proposing any automatic mechanism to enforce this restriction, as I just think that makes implementations larger and more cluttered.
Probably, but see above.
Well, to me the intermittently connected networks are covered above. If they have no network access, fine. If they do, they don't need SLs. Actually, what I am missing is why they couldn't use link locals when off-line, but never mind.There was also a "moderate usage" proposal put forth by Bob Hinden in the meeting, which would allow the use of site-local, but would not allow sites to border each other (site-local addresses would be filtered in firewalls). The details of this model haven't been documented in detail, but it has the advantage that it would allow the use of site-locals on intermittently connected networks (ones that may not always have global addresses available from their ISP, or where their ISP-provided addresses may change on each connection).
The WG had consensus to limit the use of site-locals to one of these two proposals, but we were pretty much split down the middle between
Wait - to ONE of them? - kurtis - -------------------------------------------------------------------- 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] --------------------------------------------------------------------
