[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: alternatives to site-locals?



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                Andrew.E.White@motorola.com
--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------