Subject: RE: Netfilter (Linux) Does IPv6 NAT

From: Greg Daley <[email-masked]>
Date: Thu, 1 Dec 2011 11:12:20 +1100

Is the problem that they don't get what IPv6 is for?
Or that we haven't articulated the use cases appropriately?

Alternatively,

Is there something they are trying to achieve other than "more=good?"

Greg Daley 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sabahattin Gucukoglu
> Sent: Thursday, 1 December 2011 11:08 AM
> To: [email-masked]
> Subject: Netfilter (Linux) Does IPv6 NAT
> 
> In case you didn't see this:
> http://www.h-online.com/open/news/item/Netfilter-developers-working-on-
> NAT-for-ip6tables-1385877.html
> 
> It's a complete IPv6 NAT implementation with the functionality of the
> IPv4 one in the same stack.  ALGs.  Port translation.  Connection
> tracking.  You don't need me to tell you why I don't like this.
> 
> Cheers,
> Sabahattin
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 03:00:12 +0100 (MET)

Sabahattin Gucukoglu wrote:
> http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html
> 
> It's a complete IPv6 NAT implementation with the functionality of
> the IPv4 one in the same stack.  ALGs.  Port translation.  Connection

I fail to understand the issue that you have with this.

Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for
outbound connections by default (i.e. *NO* static network prefix that
can be linked to a single ISP customer) would be extremely irresponsible
with respect to data privacy protection.

Without that, I consider IPv6 a complete no-go.

And many DSL routers are based on Linux, so having an implementation
of such a NAT is a prerequisite before IPv6 can be reasonably offered
to home customers in Europe.

I'm perfectly OK with folks getting static IPv6 network prefixes for
specific applications that desperately need it.  But the default
definitely ought to be temporary dynamic IPv6 addresses, especially
for outbound connections.

-Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Dec 2011 15:18:56 +1300

On 2011-12-06 15:00, Martin Rex wrote:
> can be linked to a single ISP customer) 

I think you're confused. Whatever IPv6 source address is in the outgoing
packet from the CPE is bound 1:1 to the subscriber. You can't conceal
the address of the subscriber, if you ever want to get any packets back.

If you want to protect the privacy of individuals within the home (etc.)
behind the CPE, you can use IPv6 privacy addresses. But the traffic will
still be traceable back to the CPE, of course.

I hope you aren't under the illusion that NAT44 in CPE provides any
privacy.

  Brian

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 03:29:49 +0100 (MET)

Greg Daley wrote:
> 
> The assumption that information is present only within the IP address
> is erroneous.
> This has been studied for mobile IPv6 users as well,
> and there is information leakage up and down the stack.

Your reasoning is obviously flawed.

Having a temporary dynamic IP address assigned will not prevent any
negligent or privacy-ignorant protocols and apps higher up the stack
to reveal identifying information about you.

But _without_ a temporary dynamic IP address, each and every of your
network communcation will be 100% identifyable as you for everybody that
can oberserve you IP datagrams floating by, even when you're using IPSEC.

> 
> We have local source address selection mechanisms in recent Windows
> versions that use randomized IIDs on outbound connections today.
> This doesn't prevent exposure of the information regarding the
> internal network structure, but nor do firewalls at publically
> addressed IPv4 institutions today.

I fail to understand what you mean by "randomized IIDs".
What you need is a temporary network address randomized by you ISP
so that your address blends within the entire customer base
of that ISP.

> 
> Putting NATs on the path just causes the device inside the network
> to be unaware of its presented addresses, which means that it will
> impede peer-to-peer communications, as it cannot even describe its
> available services without external information services.

Asking your border router for the temporary external IP-Address is
trivial compared to performing a secure DNS lookup.

> 
> This is the awful situation in IPv4 today:  Address scarcity
> is not the problem, addressability is the problem.

It is a problem for which solutions exists or can be built with
moderate effort.  Privacy is a much more serious problem today,
and without temporary dynamic addresses assigned by the ISP
privacy can no longer exist.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 03:40:45 +0100 (MET)

Brian E Carpenter wrote:
> Martin Rex wrote:

The outgoing packet is bound 1:1 to the ISP of the subscriber, any only
the ISP knows to which of his customers he is routing the datagrams
during any specific point in time.  The DHCP lease should be 24h at most
and the ISP is bound by data protection laws to not make the mapping
publicly accessible except under very specific legal exceptions.

> still be traceable back to the CPE, of course.

The so-called "IPv6 privacy addresses" are terminology fud.

> I hope you aren't under the illusion that NAT44 in CPE provides any

For my ISP (and it seems to be the norm for german home customers),
that is not an illusion, but rather a feature.

-Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Dec 2011 16:17:34 +1300

> publicly accessible except under very specific legal exceptions.

If you are paranoid about your IP address, that's fine. Personally, I prefer
a stable address. If your IPv6 prefix changes every day, your home network
will get renumbered every day. What does this have to do with NAT?

> The so-called "IPv6 privacy addresses" are terminology fud.

No, there is no fear, uncertainty or doubt involved. If you don't want
to be traceable by your MAC address, use privacy addresses. That will
even conceal from parents which child is downloading music.

> that is not an illusion, but rather a feature.

You mean there is a privacy benefit in translating some address such
as 10.1.1.2 into a routeable IPv4 address that can, as you say, be traced
back to you even if it changes every day?

You'll have to explain that.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Dec 2011 16:14:58 +1100

> even conceal from parents which child is downloading music.

If parents want to know which child is doing what they can do that
even with privacy addresses.  Privacy addresses don't change the
mac, that just don't encode the mac in the IPv6 address.  If the
kids start playing mac games use 802.1x.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 17:17:37 +0100 (MET)

Greg Daley wrote:
> 
> I do not know if this is a current environment, or what you would like to see
> (A reference would be good).

That is the current environment for home DSL subscribers (IPv4) in Germany.

>
> One would use DHCPv6-PD to request the lease for a period,
> Router Advertise it downstream to your devices, which use
> it only for 24h, and at the end of the time return the prefix
> to the pool.

At most 24h, I can get a new DHCP lease on request every 2 minutes
if I want to.  With a single IPv4 address on the external interface
of the DSL router, this does affect all connections, of course.

> 
> If you wish to rotate through address space, you could still use
> the 24 hour lease either as a replacement for or in addition to
> your static prefix in IPv6, but you do not need to use NAT.

I do *NOT* want dynamic addresses on my local network. These
ought to be static.  This is why IPv4 NAT and rfc1918 private
address space is so useful.

An IPv6 NAT would have to offer the same functionality, of course:
Address assigned through DHCP on the local/home network, but
extending the leases for the same addresses, and a randomized temporary
dynamic address on the external interface of the DSL router.

Renumbering the internal network would be completely silly.
You certainly do not want any interruptions of the local network traffic
just because you frequently change the address on the external interface for
privacy reasons.

-Martin

---

From: Greg Daley <[email-masked]>
Date: Tue, 6 Dec 2011 13:11:42 +1100

Hi Martin, 

The assumption that information is present only within the IP address is erroneous.
This has been studied for mobile IPv6 users as well, and there is information leakage up and down the stack.

We have local source address selection mechanisms in recent Windows versions that use randomized IIDs on outbound connections today.  This doesn't prevent exposure of the information regarding the internal network structure, but nor do firewalls at publically addressed IPv4 institutions today.

Putting NATs on the path just causes the device inside the network to be unaware of its presented addresses, which means that it will impede peer-to-peer communications, as it cannot even describe its available services without external information services.

This is the awful situation in IPv4 today:  Address scarcity is not the problem, addressability is the problem.

Greg Daley

> Martin Rex
> Sent: Tuesday, 6 December 2011 1:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Netfilter (Linux) Does IPv6 NAT
> 
> > http://www.h-online.com/open/news/item/Netfilter-developers-working-
> on
> > -NAT-for-ip6tables-1385877.html
> >
> Doing home gateways and *NOT* using dynamic temporary IPv6 addresses
> for outbound connections by default (i.e. *NO* static network prefix
> that can be linked to a single ISP customer) would be extremely
> irresponsible with respect to data privacy protection.
> 
> And many DSL routers are based on Linux, so having an implementation of
> such a NAT is a prerequisite before IPv6 can be reasonably offered to
> home customers in Europe.
> 
> definitely ought to be temporary dynamic IPv6 addresses, especially for
> outbound connections.
> 
> 
> -Martin

---

From: Greg Daley <[email-masked]>
Date: Tue, 6 Dec 2011 14:00:35 +1100

Hi Martin, 

> From: Martin Rex [mailto:[email-masked]]
> Sent: Tuesday, 6 December 2011 1:30 PM
> To: Greg Daley
> Cc: [email-masked]; mail-dated-1325290081.a3a4e0@sabahattin-
> gucukoglu.com; [email-masked]
> > This has been studied for mobile IPv6 users as well, and there is
> > information leakage up and down the stack.
> 
> negligent or privacy-ignorant protocols and apps higher up the stack to
> reveal identifying information about you.

My point is that it is unhelpful to ignore the principles underpinning IPv6 architecture in order to fail to achieve your privacy goal.

> network communcation will be 100% identifyable as you for everybody
> that can oberserve you IP datagrams floating by, even when you're using
> IPSEC.

Yes, when your outbound sessions hit the internet, devices on the path can see where you come from.

In my world, these people can see what they can already learn from watching my IKEv1 aggressive mode identity (if not using certs) or WWW cookies, or TCP stack behaviour and use profile.

In your world you gave up peer-to-peer IPSec, SIP, etc  initiated from either end to gain a false feeling of privacy.

> What you need is a temporary network address randomized by you ISP so
> that your address blends within the entire customer base of that ISP.

Please read RFC 4941 "Privacy Extensions for Stateless Address Autoconfiguration".

> >
> > Putting NATs on the path just causes the device inside the network to
> > be unaware of its presented addresses, which means that it will
> impede
> > peer-to-peer communications, as it cannot even describe its available
> > services without external information services.
> 

I have no interest in comparing apples to oranges.
I have implemented ICE and I can say it is non-trivial.

Sincerely

Greg Daley

---

From: Greg Daley <[email-masked]>
Date: Tue, 6 Dec 2011 14:21:47 +1100

Dear Martin, 

> > I think you're confused. Whatever IPv6 source address is in the
> > outgoing packet from the CPE is bound 1:1 to the subscriber. You
> can't
> > conceal the address of the subscriber, if you ever want to get any
> packets back.
> 
> during any specific point in time.  The DHCP lease should be 24h at
> most and the ISP is bound by data protection laws to not make the
> mapping publicly accessible except under very specific legal
> exceptions.

If you wish to rotate through address space, you could still use the 24 hour lease either as a replacement for or in addition to your static prefix in IPv6, but you do not need to use NAT.

One would use DHCPv6-PD to request the lease for a period, Router Advertise it downstream to your devices, which use it only for 24h, and at the end of the time return the prefix to the pool.

The mapping then becomes a routing one, rather than a NAT one, and the routing mapping only exists as long as the connection is available (if using PPP) AND the DHCP lease is held (under the same rules or laws you indicate).

While I do not think there is an option to "return this prefix to the pool, and assign me a different prefix", it would be "trivial" to implement, and would not create a barrier to sessions like NAT would.  (Note that I would decouple the prefix return and assignment to de-link them in time).

This is presented as a counter-example to "NAT is the answer", because this is a technologist perspective, and there are other solutions.  What we should really be doing is engaging with industry to identify the actual need, not choosing technical paths because of their feasibility in code.

Sincerely,

Greg Daley

---

From: Doug Barton <[email-masked]>
Date: Tue, 06 Dec 2011 10:10:58 -0800

> We have local source address selection mechanisms in recent Windows versions that use randomized IIDs on outbound connections today.  This doesn't prevent exposure of the information regarding the…

This has been covered many times, but once more (with feeling) ...

The problem that 4941 is designed to fix is to avoid being able to track
the same user on *different* networks. This is possible because by
default the host portion of the address remains constant, and
theoretically globally unique.

Privacy for a user that is always connecting through the same network is
a whole different basket of bagels.

Doug

-- 

		[^L]

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Dec 2011 09:00:13 +1300

On 2011-12-06 18:14, Mark Andrews wrote:
...
> kids start playing mac games use 802.1x.

Yes, of course it depends on the child's and the parents' technical
sophistication. I was limiting my comment to layer 3, since Martin was
arguing that layer 3 NAT helps privacy.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Dec 2011 09:05:39 +1300

Martin,

> just because you frequently change the address on the external interface for

This is why ULAs are useful. People just need to get used to the fact
that IPv6 addresses derived from ISPs will change from time to time,
and that you will have several of them. This is not your grandfather's
TCP/IP.

This is also why we have the MIF, HOMENET and 6RENUM WGs.

   Brian

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Dec 2011 15:34:00 -0500

Brian, I'd like to join this from another angle.

What exactly does changing your v4 address get you in terms of privacy?

It's my understanding that protocols including TCP, HTTP, TLS, and very
much the web platform are fairly easily linked.
That is, it's relatively easy to determine with reasonably widely
available software whether two connections come from the same end-system
across a NAT and regardless of what's done to the IP addresses.

So, I'd like to better understand what attacks changing the outer DHCP
address protects against in terms of privacy.

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 21:34:20 +0100 (MET)

> This is also why we have the MIF, HOMENET and 6RENUM WGs.

As long as the current IPv4 characteristics are not transparently
available with IPv6, it will probably deter adoption of IPv6 for
the installed base.

I certainly feel fine with IPv4, and would probably feel
more comfortable with IPv4 behind CGN than with what is
currently available as IPv6.

-Martin

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 7 Dec 2011 10:57:31 +0000

> just because you frequently change the address on the external interface for

1.  If you just want to camouflage internal clients, do it with privacy addresses or a socks proxy and clients.

2.  If you want to hide, do it with proper means, i.e., tor.  You needn't suppose that the one agent who has the most insight into your network traffic, that being your ISP, is trustworthy.  Especially true given that it's the one agent with the highest likelihood of actually succeeding in the intercept of your Internet traffic.  Or that it often has controls over its routers which allow monitoring beyond rightful boundaries.  Best intentions aside.

3.  If you've got to have dynamic external IP addresses (note, not address; for that, see 1 above), we'll have to find a way to renumber your network so applications running on your hosts know what their new addresses are while keeping your preferred topological configuration, every time your PD lease is due *.  However, you should be using ULA or LL addresses for intra-network traffic, not global.  This has to be the only legitimate use of NAT, but not for port translation.

4.  NAT must die.  It is simply a pain in the arse.  We're not stunting another decade of growth simply to uphold an illusion caused by address sharing.  Most funny has been the many things attributed to it, because the original NAT concept specification was written at a time when most traffic was within the private realm, not through the translator into the public one.  Please try to think outside the box, as the popular expression goes.  We can find solutions to your problems that do not include damaging important principles which ensure that the Internet actually grows and innovates, groupthink notwithstanding. And yes, I realise that this statement is already enough to ruffle some people even within the IETF, and definitely within the security community.

Cheers,
Sabahattin

* What's renum doing these days? There's got to be a better answer than NAT66 for this sort of problem.

---

From: Greg Daley <[email-masked]>
Date: Wed, 7 Dec 2011 09:44:30 +1100

Hi Doug, 

> versions that use randomized IIDs on outbound connections today.  This
> doesn't prevent exposure of the information regarding the internal
> network structure, but nor do firewalls at publically addressed IPv4
> institutions today.
> 
> The problem that 4941 is designed to fix is to avoid being able to
> track the same user on *different* networks. This is possible because
> by default the host portion of the address remains constant, and
> Privacy for a user that is always connecting through the same network
> is a whole different basket of bagels.

We have not had carrier NAT solutions until walled gardens came in with 3G networks, and now people are mooting CGNs, but I have not seen many in general use for access networks.

Up until now, we have migrated addresses when a new PDP-Context, PPP (Dialup/xDSL) or DHCP Lease has been supplied.  In IPv4, the session uniquely identifies/identified the session and links to the user during that interval.
The same is true for IPv6, except that IPv6 defaulted to MAC based IIDs.  With 4941, the same Layer 2 identity is removed, and we have the same circumstances with IPv4 and IPv6.

So CGNs for IPv4 are an answer to a new question that you pose where the implicit assumption is that it is insufficient to maintain address unlinkability between different PDP-Context/PPP/DHCP sessions.

Given that we have good local addressing mechanisms in IPv6 (ULA, Link-local) and automatic global prefix configuration mechanisms (SAA/RA/DHCPv6/DHCPv6-PD), I would like to know: What are the advantages of CGNs for IPv6 and does the cost to application development justify the change?

Sincerely, 

Greg Daley

---

From: Greg Daley <[email-masked]>
Date: Wed, 7 Dec 2011 09:56:49 +1100

Hi Martin, 
> available with IPv6, it will probably deter adoption of IPv6 for the
> installed base.

I would argue that this is a commonly held incorrect view:  The problem is not that feature sets are unavailable, but that there is no compelling local economic case for installing IPv6.

IPv4 networks could not do everything that IPX networks were doing when the Internet boom occurred.  There was a compelling local use case which drove parallel adoption.

What we should be doing is identifying the key features of IPv6 that cannot be addressed by IPv4, and ensuring that these are available.  If these are good enough, IPv6 will be deployed.

Today the only feature IPv6 has which is absolutely better than IPv4 is end-to-end addressability.

Introducing CGNs places a barrier to this addressability.

Really if you want address-user unlinkability, use HMIPv6 or some other signalling based protocol to get temporary addresses in the carrier.  At least in that case the applications will know their addresses because they will be locally configured.

Greg Daley

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Dec 2011 02:47:31 +0100 (MET)

Sabahattin Gucukoglu wrote:
>
> 1.  If you just want to camouflage internal clients,
> do it with privacy addresses or a socks proxy and clients.

I don't see a purpose to camouflage internal clients from
internal peers.  And my ISP would probably and rightfully refuse
to route my IP datagrams if he could not recognize me as a peer
and paying customer.  But there is regularly no need that anybody else
besides my ISP can distinguish my IP datagrams from those of other
customers of this ISP.

The typical residential/home internet access is like a
1-family home, and this is even explicit part of many ISPs
home DSL subscriber contracts.

In real life, all members of a household typically have a key to the outer
door, and that outer door is usually closed or locked most of the time,
while most doors within the house are not locked most of the time.

It is very desirable to have as much privacy as achievable
from the rest of the world at the network layer, because it
is the ultimate prerequisite for application and user to control
and limit disclosure of ones identity to network peers.

When a sufficient part of the network address that your peers
on the internet see when you talk to them, is sufficiently unique
and constant over time, then privacy is *completely* impossible.
A network address with a prefix that uniquely idenfies individual
subscribers over a prolonged time amounts to a pseudonym.
RFIDs with unique IDs and biometrics have the very similar problems.

Since there _are_ going to be situations when your identity is visible
along with the IP address that was used to convey your identity,
this information will spread within a matter of at most days.
SMTP-Servers regularly write the sender's IP-Address into
rfc(2)822 Received:-headers of EMails they forward and distributed
to all receipients.  In case of EMail lists, this informatio may end
up in public Email archives and easily accessible through Internet
search engines for everyone as a result.

A logical step for muggers would be to profile prospective victims
with a smart phone by covertly take a photo, try Facebooks face recognition,
use peoplefinders, and then google streetview in order to assess the amount
of money someone might be capable and willing to spend on _not_
getting harmed when being assaulted.

Profiling people is fairly easy when there are no privacy protection laws,
as in the US, and more and more common for businesses on employees and
customers.  Crooks might appreciate a level playing field.  I don't!

The problem with biometrics, when they're abused, is that they're
regularly difficult to change (face recognition, retina scan,
fingerprint).

Over here, in old Europe, we believe that privacy is a basic human
right and that implies that each person must have ultimate control
over all collection, use and distribution of PII.  Which means
an explicit opt-in prerequisite, that is voluntary and revocable anytime,
precise and clearly limited about collectors, data items, purposes&use cases
for all PII about oneself -- backed laws to enforce data privacy and
punish violators.

>
> 2.  If you want to hide, do it with proper means, i.e., tor.

Tor is of limited usefulness, at least for me.  I can not think of a
single reasonable use case for myself (I do not have any stuff for
upload to any *leaks places).

>
> You needn't suppose that the one agent who has the most insight into
> your network traffic, that being your ISP, is trustworthy.

My neighbours are the ones who know best at what time I go on vacation,
and I even leave the key to my house with one of them while I'm away.

You are implying, that particular neighbour should be my real and only
concern and everybody&everthing else should be irrelevant in comparison.

Fortunately, the real world where I live is quite different from yours.

I'm not afraid of my neighbor and neither of my ISP.

It would be a felony with serious consequences for my ISP to listen into
communication of its customers (even when it is cleartext).
While keeping the shutters on ones windows firmly locked 24/7 might be
"safer", it believe the benefits of opening the shutters during the day
outweigh the risks...at least where I live.

>
> Especially true given that it's the one agent with the highest
> likelihood of actually succeeding in the intercept of your Internet
> traffic.

I'm much more worried about other threat scenarios.

By your logic, it would be a bad idea for banks and shop owners to
let bank clerks and armoured car personnel touch any of their cash money,
because those would be the folks with the highest likelyhood in
succeeding to steal it.  I believe this amounts to flawed logic.
One will need to deal with that kind of risk in a different fashion.

>
> Or that it often has controls over its routers which allow
> monitoring beyond rightful boundaries.  Best intentions aside.

So what?  Google probably stores and anylyzes more about google searches
and more about @gmail.com EMail contents than all of the ISPs in Europe
combined.  And Facebook is at least a magnitude worse about the data that
they get their hands on.

Fortunately, I live in a jurisdiction and country where constitution,
laws and justice will protect and enforce civil liberties, human rights
and privacy against all perpetrators alike: private, law enforcement,
governmental and legislators.  The last time when our national legislator
enacted a law to have ISPs collect data for law enforcement
without probable cause, although limited to connection data and excluding
communication content, that law was quickly provisionally neutered and
later nixed by our constitutional court.

The technical part about peer authentication and data confidentiality,
for sensible communication content while traversing the ISPs network,
can be mitigated with protocols&software like TLS/HTTPS and SSH.

>
> 3.  If you've got to have dynamic external IP addresses
> (note, not address; for that, see 1 above), we'll have to find
> a way to renumber your network so applications running on your hosts
> know what their new addresses are while keeping your preferred
> topological configuration, every time your PD lease is due *.

That sound like a weird design.  Whatever the solution will be,
it will have to be without renumbering.  Hosts must not care
about the temporary dynamic external IPv6 address at all. 
Only a very small number (if any) of applications might need
to know, and those will have to ask the home gateway for it
exactly when they need it.

The home gatway might need a NAT66, and for the remaining lifetime
of IPv4 a NAT44 in combination with an IPv4<->IPv6 protocol translation
(maybe something like rfc6052).

The use of seperate routing tables for IPv4 and IPv6 looks more like
part of the problem to me rather than part of any solution.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Dec 2011 16:13:29 +1100

You really don't know what IPv6 boxes are capable of.  Below is the
start of a netstat of the active IPv6 connections.  The first
connection is a internal connection.  The stack automatically choose
to use the ULA address (fd92) over the non-ULA address as it was a
connection to a internal host.  Both machines have ULA and non ULA
addresses.

The other connections are all to external servers.  They use the
non-ULA address.  That address could be changed at anytime the same
as your IPv4 is being changed.  The IPv6 hosts don't care.  You
also don't need NAT66 to achieve this.

Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)    
tcp6       0      0  fd92:7065:b8e::6.50942 fd92:7065:b8e::2.22    ESTABLISHED
tcp6       0      0  2001:470:1f00:82.50941 2001:4860:8005::.80    ESTABLISHED
tcp6       0      0  2001:470:1f00:82.50940 2001:4860:4001:8.80    ESTABLISHED
tcp6       0      0  2001:470:1f00:82.50286 2001:4860:4001:8.80    CLOSE_WAIT 
tcp6       0      0  2001:470:1f00:82.49833 2001:4f8:4:d::8.5223   ESTABLISHED

This is done using machines that you can walk down to the local
computer store and pick up today.  I didn't have to configure
anything to achieve this other than have the router advertise a
second ULA prefix.

Mark