Date: Fri, 27 May 2016 07:54:30 +0200 From: Mark Tinka <mark.tinka@seacom.mu> To: Kevin Oberman <rkoberman@gmail.com>, tinc@tinc-vpn.org, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Mailinglists FreeBSD <freebsd-questions@freebsd.org> Subject: Re: IPv6, ULAs and FreeBSD Message-ID: <f96728b5-3989-2e39-17b8-4c5986d8d01e@seacom.mu> In-Reply-To: <CAN6yY1uEwttkd7iCBrjoFytUjUiNL1Ew-j7pm=-S=dY9HBXPYQ@mail.gmail.com> References: <20160519124446.GB2444@box-fra-01.niklaas.eu> <20160523034855.GA37797@box-fra-01.niklaas.eu> <20160524061707.GA77980@box-fra-01.niklaas.eu> <20160526193602.GF49239@box-fra-01.niklaas.eu> <CAN6yY1uEwttkd7iCBrjoFytUjUiNL1Ew-j7pm=-S=dY9HBXPYQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/May/16 06:11, Kevin Oberman wrote: > There are a lot of excellent reasons to avoid ULAs. There are a very few > good, or even so-so reasons to use them. The most commonly cited reason is > security which is almost always wrong. In almost 20 years of working with > IPv6 I have yet to see any valid security reason for using ULAs. There are > any number of excellent papers on this. > > The most valid use is when you can only get a /64 from your provider. RFCs > recommend a minimum assignment to residential customers of a /56 but many > providers seem to have missed this, so there is no choice. prefixes longer > than /64 are effectively not possible. IPv6 does not care, but the > supporting protocols , make a /64 or shorter assumption. More intractable > is that hardware also often make similar assumptions. As you learned, you > really, really don't waste your time trying to make it work. > > I really guess all of this needs to be in the handbook so people don't > waste time trying to do things that are documented to either not work or > not work effectively. And, unless you are really, really sure you need > ULAs, They mostly just break things. Fully agree. Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f96728b5-3989-2e39-17b8-4c5986d8d01e>