Andrew White wrote: > Mike Saywell wrote: > > > > 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. :) > > There are currently two drafts that describe how to implement > this. There > are surface differences, but the basic idea is the same. > > * draft-hinden-ipv6-global-site-local-00.txt > * draft-white-auto-subnet-00.txt
I personally can see use in these two drafts. But not in the current setup for SL. These at least take the problem away that a site is unique which saves on the renumbering problem when 'unconnected' sites connect. > As for site locals, there seem to be three issues: scope, ambiguity, > renumbering. > > > On scope: > > If you only ever have on address per machine (strictly no > multihoming) then scope isn't an issue. However, renumbering becomes awkward. > > If you allow multihoming, then either you must ban filtering or all > applications need to be able to compensate for situations where some > source-destination address pairs work and some don't. > Architectural scoping doesn't make the problem worse, and may make > it better by providing hints to applications if they choose to pay attention. Having multiple prefixes will most of the time imply that the layers above know a bit about the network. Though ignorance is bliss in this case as the current source-address- selections protocols will select the correct prefix in most cases based on longest prefix matching algorithms. > On ambiguity: > > In most sensible SL deployment scenarios, ambiguity is not an issue. > Disconnected networks don't matter, while any other SL network is not > supposed to talk outside the site, and so things will happily > fail. And if someone else's DNS returns an SL? Well, the packet gets > dropped at the filter on your site border router. This is slightly better > than any other bad DNS result where the packet is dropped somewhere in the > global internet. There does start a problem where the deployment is not sensible. AS112 is the proof of this. Explicetly having a certain prefix filtered on SOHO devices could be an option, but this also implies that IPv6 will be going that dreaded NAT way if the upstream doesn't provide enough address space. Talking about that, maybe a clause in some document should hint ISP's to start billing based on traffic consumption and not on IP usage. "IP usage" is a unmeasurable thing when the endsite gets a /48 unless the ISP is going to sniff all the packets and account them that way instead of based on the circuit counters. This would at least hint them that endsites should really get a /48 and not just a single /128. Personally I would shoot ISP's who did not follow that convention. Then again one can always ask them why the peep they requested a TLA in the first place if they are not going to give their endsites /48's. <SNIP> > I'm all in favour of an 'SL considered harmful'. However, > there are several situations were SL is exactly what is > appropriate, and it seems an odd philosophy to deprecate > power-saws because they shouldn't be used in place of drills. With the above 2 drafts in mind we only will be deprecating the current version of SL. One, or a merger, of the above two drafts will make the power saws into a workable saw which doesn't smash up the wood (ambiguity) nor doesn't need any power (registration). 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] --------------------------------------------------------------------
