[ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address?

On 27 Mar 2015 9:13 am, "Sanjeev Gupta" <ghane0 at gmail.com> wrote:
>> Technically, I think you mean NPTv6, as per RFC 6296.
>> It’s disappointing but not unexpected that sites are doing this.
>> The homenet approach is that hosts are multi-addressed with ULA and
globals. They use ULAs internally, which provides a decent level of
renumbering protection, and globals externally.
>> Having a single IP address is IPv4 thinking.
>
> Tim, thank you for the reference, we are using something close-to-but-not
RFC6296.

That's not a recommended deployment strategy. A much better strategy is the
one recommended by RFC 7368.

Bear in mind that RFC 6296 is classified as experimental, and to my
knowledge is not used by any other ISP in this way. IIRC it was originally
rushed through the prices due to a very unique situation in Japan, and even
there it is used to convert between two different global prefixes, not ULA.

Using NPTv6 will break applications, such as video chat clients, which are
built on the assumption that IPv6 does not use NAT and thus in IPv6
implement only firewall traversal but not NAT traversal. That assumption is
true in the vast majority of IPv6 deployments, so those apps may never
support this more of operation.

Also - if you're using ULAs, be aware that ULAs are specified to be
globally unique, i.e. all the ULA prefixes used in your network should be
different from all the ULA prefixes used elsewhere in the world. ULA
achieves this by requiring that ULA prefixes be generated randomly to avoid
collisions. If you're not doing this, you may encounter other forms of
breakage.

"It works like this in IPv4" doesn't means it will work in IPv6. In IPv4,
virtually everybody uses NAT. In IPv6, virtually nobody does.

Why can't you provide global IPv6 addresses? Most IPv6 deployments have to
deal with IPv6 prefix changes, and none that I'm aware of have chosen to
use ULA as a result.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ipv6-wg/attachments/20150327/74cb86ec/attachment.html>