If you use this method to generate unique local addresses (which may be one viable alternative), you still won't want the semantics of current site-local addressing...
The current site-local architecture does not allow sites to overlap or be nested. Sites also need to be "convex" which requires that their boundaries be at routing area or AS boundaries. Current site-local addresses are ambiguous, so they need to be treated specially in address selection rules, at UIs, etc.
If you come up with any method to generate unique local addresses (mac-address-based, registry-based, etc.), then most of the restrictions in the current site-local architecture are unnecessary. Unique local addresses don't need to be treated as "scoped" addresses (in the sense this term is used in the scoped addressing architecture). They can be treated just like any other global addresses, and just filtered at the borders of the local space.
Margaret
At 02:35 AM 4/3/2003 +1000, 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
-----
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.
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.
On renumbering:
Most of the ambiguity questions are really renumbering questions. For 'large' sites, you can go provider-based (renumbering is potential issue), or site-local (and be unrouteable), or NAT (yuck!), or PI (doesn't currently exist). Multi-homing at least helps things, in that you can switch in your new addresses before you switch out your old.
If you wish to run an internal non-routeable address space, there are several proposals to allow site-local address realms to be set-up such that they are probably (or guaranteed) globally unique (without requiring registration), which solves the local merge problem.
On the other end of the spectrum are zeroconf networks that may or may not be connected to a global provider. SL and multihoming is perfect for these networks, since they can zeroconf in the SL space and then overlay a global address space if convenient.
And zeroconf networks don't have nearly the same renumbering problems as large configured networks, because they are designed to rebuild all that configuration information without human agents.
Finally, there is advantage to using SL in private, disconnected networks, and that is that those networks may eventually join the global internet. If you have used SL, you know that you can continue to use that space locally without masking global connectivity, and overlay a global address. If you picked an arbitrary address, then you may have ambiguity that matters, rather than ambiguity that doesn't.
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.
-- Andrew White [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] --------------------------------------------------------------------
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
