Mike Saywell wrote: > On Wed, Apr 02, 2003 at 03:37:25PM +0200, Jeroen Massar wrote: > > Indeed 'just pick some random address' if you don't want to > > be connected to the rest of the world. No need for SL. > > Also E20 or a similar amount is peanuts compared to what it > > would cost if you need to renumber your complete site.
You accidentally cut out the following lines from the reply above this one which does make a big difference in the rest of the context: > > What you need is a globally unique /48 that is disconnected > > and which one should be able to register 'cheaply'. Eg > > an annual fee of E20 or something just to make sure that > > not everybody starts harvesting them. <snipback> > Think beyond corporate networks. > > SL does not lead to NAT but choosing random addresses *WILL*, > consider: > > I setup an ad-hoc network using my laptop, wireless is 1 network and > wired is a second, my laptop routes between them. There is > no external connectivity and site-locals are deprecated so I pick > a random prefix. This looks like a typical house style network... just like mine except that I got a machine which gates these two nets to the internet just like you explain in: > Now somebody with a link to the wider world joins my network, > since there is no guarantee that the prefix used on the ad-hoc > network is not used on the internet you either have to nat > outgoing traffic or re-number the network. > You have repeatedly slated re-numbering, and it seems > un-feasible in an ad-hoc network anyway so the only choice left is NAT. Announce the new prefix, deprecate the old prefix done. Small networks don't really care about having to edit a couple of places where hosts<->ip are registered which should quite probably only be DNS and a single firewalling place. That's the joy of small non-corporate networks. For SOHO usage this will boil down to a click-and-pray interface. > If the network was numbered using site-locals all you don't need to > re-number, just advertise an additional prefix. And why can't you just advertise an additional prefix when having some space that is globally unique and private as that's where it is registered for (see the text above that was cut away :) ? > Yes, applications would need to be made to use the global prefix, we > need a way of enforcing this - a simple method could be that the O/S > simply deprecates the site-local prefix. What I stated above. > If you only consider that Site-locals will ever be deployed > in a "normal" network then the deprecation question is easy > (yes deprecate them), however I thought that one of the > advantages of v6 was that it gives better support for the a-typical network. Name these a-typical networks. Otherwise there can be no cases for them. I do still like the boat case :) > I dont think some organisation allocating private prefixes is viable > either, ad-hoc means exactly that, I don't want to be manually entering > my unique private prefix. You have to enter a site local prefix too. Whats the difference in entering a unique prefix or typing in 10.0.0.0/8 again? Most people will want to connect to the internet. So especially for SOHO cases they will be connected to the internet. Their ISP will provide them with a /48 either through router advertisements or using the old fashion paper way. SOHO routers will simply ask "please enter the prefix as stated on the paper" and done. We are fortunatly taling SOHO here and > How about using fec0:<MAC address>::/64? That gives a (probably) private > network per interface, the only issue is that you wouldn't be able to > aggregate them in a sizeable network - however I agree that > site-locals shouldn't be used in such a scenario. :) Hmmm that does sounds like a good idea for an alternative. It does indeed overcome the 'registry' problem and the fact that it should be globally unique. Except that one would rather use EUI-64 instead of the MAC address. But that's ofcourse debatable. I would rather see use of the fec0::/10 in a way like this than with every sole person using fec0::80 for their home webserver... Greets, Jeroen -------------------------------------------------------------------- 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] --------------------------------------------------------------------
