Subject: Re: [BEHAVE] NAT66 - lets bring back FEC0:: ( was Lack of need for 66nat)

From: "Eric Klein" <[email-masked]>
Date: Thu, 27 Nov 2008 17:59:00 +0200

If we are seriously discussing defining some flavor of NAT (and it appears
that more than half of the people writing are in favor of it) then we need
to resurect the address space that was allocated for site locals
fec0:: (andcurrently is likely not used do to early implementations)
and use it as the
new "1918" type pool for v6.

Otherwise we open more problems while leaving a block of addresses that were
intended (and in theory depriciated) just for this out there and unusable.

Note I say in theory, as the depreciating RFC (RFC3879) states:
   "However, the formal deprecation allows existing usage of site-local
addresses
     to continue until the replacement is standardized and implemented."

and I do not know of a standardized replacment. So maybe we need to
depreciate 3879 and reclaim the addresses for this proposed NAT66 pool (it
is larger than the old 1918 pool).
Eric

On Mon, Nov 24, 2008 at 14:15, Magnus Westerlund <
[email-masked]> wrote:

> Tony Hain skrev:
> > The charter of Behave should be amended to
> > remove this entire discussion until someone demonstrates that we actually
> > need a 66nat because there is no way to solve a real problem without it.
>
> The BEHAVE charter does not include anything about NAT66 for the moment.
> We Area Directors have taken the decision that NAT66 is to be discussed
> in Behave for moment. If we find more suitable home for the discussion
> we will move it.
>
> I also don't think we are yet ready to make a decision or not of
> chartering any NAT66 work. So please let this discussion continue.
> Especially the one that brings technical or operational requirements to
> the table and help increase our understanding of the benefits and
> downsides and potential alternatives.
>
> Best Regards
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
>  _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Nov 2008 11:20:56 -0500

Eric Klein wrote:
> If we are seriously discussing defining some flavor of NAT (and it
> appears that more than half of the people writing are in favor of it)
> then we need to resurect the address space that was allocated for site
> locals fec0:: (and currently is likely not used do to early
> implementations) and use it as the new "1918" type pool for v6.

uh, no.

the one thing that makes NAT even worth considering in IPv6 is not
having conflicting use of the same address space, like we have with RFC
1918 addresses in IPv4.

Keith

---

From: Dave Thaler <[email-masked]>
Date: Thu, 27 Nov 2008 11:00:06 -0800

I agree with Keith here.  In my earlier comments on the NAT66 draft,
I mentioned that in my opinion, it MUST NOT be used with scoped
addresses (link-locals, site-locals).  Communication to such
addresses should never be routed outside their scope (even
if translated).

And use with ULAs is questionable (might affect some applications
if they assume[*] that ULAs aren't used outside their site).

-Dave

[*] I use assume in the same sense as other assumptions/myths in
draft-iab-ip-model-evolution.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Keith Moore
> Sent: Thursday, November 27, 2008 8:21 AM
> To: Eric Klein
> Cc: Behave Mailing List
> Subject: Re: [BEHAVE] NAT66 - lets bring back FEC0:: ( was Lack of need
> for 66nat)
>
> Eric Klein wrote:

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Nov 2008 20:23:47 +0100

> if they assume[*] that ULAs aren't used outside their site).

So what then? Unique Locally Local but Globally Translated Addresses  
(ULLbGTAs)?

In my opinion, it's an important feature to be able to determine  
locally that an address will be subject to translation. The easiest  
way to do that is by only allowing translation for a specific subset  
of addresses. And we certainly don't want RFC1918-style ambiguity. On  
top of that, having to get addresses that are disconnected from the  
internet (they provide connectivity through the NAT, but the addresses  
themselves aren't connected to the internet) from an ISP seems rather  
strange.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Nov 2008 14:40:32 -0500

Iljitsch van Beijnum wrote:
> In my opinion, it's an important feature to be able to determine locally
> that an address will be subject to translation.

I don't think that's an important feature.  I do think it's important
that applications be able to obtain and use addresses that are globally
scoped and globally reachable from the public Internet.  But that's not
the same thing as being able to determine than an address will (or will
not) be subject to translation.

Even if that were an important feature, ULAs exist for a variety of
reasons.  To restrict ULAs for this purpose would be to impair their use
for other purposes.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Nov 2008 14:12:12 -0500

Not FEC0::, I STRONGLY agree.
Not link local.

ULA I can sorta use as my intra-site addressing system which always
available. (Lack of reverse DNS is a serious problem for me)

But, if you can't use ULA as the site side of NAT66, then what can
you use?   Sites/People with stable IPv4 can generate 6to4 addresses and
use them. What about places without stable, public IPv4?
(People who have only ever been on the "natwork")

It seems to me that perhaps the *IETF* should instruct IANA to create a
new pool of addresses which are to be given out to SME/end users.
/56s or /60s.  These addresses will NEVER(%) be globally routable, but
will: 
     a) have whois.
     b) have reverse DNS.
     c) be unique.

I am in favour of defining NAT66.  Do it right.
Give it an RFC number.  An applicability statement, etc.
At least I can say to my ISP, "I refuse to use RFCxxxx. Give me some
address space."
Or, "Oh, you are an RFCxxxx site. Well, that won't work for us."

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Nov 2008 14:55:21 -0500

Michael Richardson wrote:
> you use?

There's more than one use case for NAT.  There are cases where it would
make (local) sense to NAT from one range of PA space to another.  There
are also cases where it makes (local) sense to NAT to ULA space.

Similarly there's more than one use case for ULAs.  Apps should not make
assumptions about what a ULA means or how they can be used, beyond the
obvious one that ULAs aren't expected to be routeable in the public
Internet.  For instance: A ULA can be routed between consenting private
networks by bilateral agreement, A ULA can be short-lived, etc..

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Nov 2008 13:47:07 +1300

> if they assume[*] that ULAs aren't used outside their site).

I'm afraid that such assumptions are going to be made in any case,
until the day when addresses are consistently handled as data structures
including format, lifetime and scope information.

We explicitly defined ULAs as having global scope; which is a sort of
warning that they may be exported from their origin site.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Nov 2008 14:08:01 +1300

Michael,

On 2008-11-28 08:12, Michael Richardson wrote:
...
> /56s or /60s.  These addresses will NEVER(%) be globally routable, but

Is that significantly different from the ULA-C proposal,
which didn't gain consensus?
http://tools.ietf.org/id/draft-mrw-6man-ulac-analysis-01.txt

    Brian

---

From: "Eric Klein" <[email-masked]>
Date: Fri, 28 Nov 2008 09:48:07 +0200

On Thu, Nov 27, 2008 at 21:00, Dave Thaler <[email-masked]>wrote:

>  This actually was my point, people want NAT back for the renumbering
issue, because they are used to assiging one set of addresses from a fixed
pool inside and using public ones outside.

If we do away with the set of known inside addresses (and I am not sure what
we are doing with 0:0:10:x:x:x) how will we prevent people from using these
2 sets of previously defined pools of addresses that are not to be routed
across the public network?

In one of the other discuss chains on this topic the premise that we need to
give people what they "think they want" because someone will try to sell it
to them anyway was made so I sent out this topic to show that within the
actual rules of the active RFCs we have problems to address that are at the
core of this NAT issue.

Eric

---

From: [email-masked]
Date: Fri, 28 Nov 2008 12:05:53 +0000

Maybe redefine fc00::/8.to be NATable ULAs?
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "Eric Klein" <[email-masked]>

Date: Fri, 28 Nov 2008 09:48:07 
To: Dave Thaler<[email-masked]>
Cc: Behave Mailing List<[email-masked]>; Keith Moore<[email-masked]>
Subject: Re: [BEHAVE] NAT66 - lets bring back FEC0:: ( was Lack of need for
	66nat)

---

From: Rémi Després <[email-masked]>
Date: Fri, 28 Nov 2008 13:24:19 +0100

> Sent from my Verizon Wireless BlackBerry
Using Fc00::/8 in IPv6 like 10.0.0.0/8 is used in IPv4 would make a lot 
of sense to me.
This would be the prefix for "private IPv6", whith full freedom on how 
bits beyond the eigth are used.

RD

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 28 Nov 2008 09:18:05 -0500

IMO, using site local addresses (or the site local prefix) for  
addressing behind a NAT would be a huge mistake.

As Keith Moore has already indicated, one of the major sources of  
difficult with IPv4 NAT is that we use ambiguous net 10 addresses  
behind the NAT.  When an application (or a network management tool)  
sees one of these addresses in a referrral (or a MIB, or a system  
log), there is no good way for an application to know whether the net  
10 that is used in that address is the _same_ net 10 as is used on the  
locally attached network.  The application can try to reach a node at  
that address, but it may not be the right node.

To understand the difference between net 10/site-local addressing and  
ULAs, you need to consider two properties of addresses:  reachability  
and identity.  While it is true that all local addresses (net 10s,  
site locals and ULAs) have limited reachability, ULAs uniquely  
identify a node within a global scope, while net 10/site-local  
addresses only identify a node within a local scope (the same net 10/ 
site-local address is used for different nodes in different sites).   
This can create ambiguity about what node is being referred to in  
cases where net 10 addresses leak out of the local site (in referrals,  
MIBs, system logs, URIs, etc.).

This ambiguity is a significant problem for a number of reasons.  It  
makes it much harder for two private networks to join or to provide  
limited connectivity to each other's networks.  It makes it hard to  
manage these networks from an external location.  It confuses  
applications and causes them to attempt to connect to the wrong node.

The definition of ambiguous local address in IPv4 was probably  
necessary, due to the limited IPv4 address space.  However, we did not  
need to make the same choice in IPv6, which is why we chose to  
deprecate site-local addresses and define ULAs.

Margaret

On Nov 28, 2008, at 7:24 AM, Rémi Després wrote:

> Using Fc00::/8 in IPv6 like 10.0.0.0/8 is used in IPv4 would make a  
> lot of sense to me.
> This would be the prefix for "private IPv6", whith full freedom on  
> how bits beyond the eigth are used.
>
> RD
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Nov 2008 09:33:52 -0500

> Using Fc00::/8 in IPv6 like 10.0.0.0/8 is used in IPv4 would make a lot

So what you want to do is to make IPv6 as dysfunctional as IPv4?

Keith

---

From: Rémi Després <[email-masked]>
Date: Fri, 28 Nov 2008 15:59:30 +0100

Keith Moore  -  le (m/j/a) 11/28/08 3:33 PM:

Sorry I appreciate moderately this comment.

Like you I suppose, I work to help the community to deploy IPv6
gracefully.

(If most of native IPv6 users today are at Free.fr (Google statistics),
this is because my understanding of issues led me to propose the
innovative 6rd approach to this ISP, and because its CTO, Rani Assaf
adopted it enthusiastically.)

Your technical and marketing comments are most welcome, but not this
kind of statement without any substance.

RD

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Nov 2008 11:03:07 -0500

Rémi Després wrote:
> Like you I suppose, I work to help the community to deploy IPv6 gracefully.

I don't see a huge benefit in deploying IPv6 if it's going to work as
badly as IPv4 does today.

IPv4 is a huge mess because of overlapping address space and NATs.  It
is hard to convince people to do without NATs in IPv6 because from their
IPv4 experience they think they need them, and we have not (yet)
provided better solutions for everything that people use NATs for today.
 Even if people use NATs with IPv6 in the near term, IETF's goal should
be to provide better solutions than NAT, so that operators can turn NAT
off in the future without harming their networks.

What you are proposing is exactly the opposite.  It is a return to
overlapping address spaces, and NAT lockin.

Keith

---

From: Rémi Després <[email-masked]>
Date: Fri, 28 Nov 2008 17:43:49 +0100

Keith Moore  -  le (m/j/a) 11/28/08 5:03 PM:

Rémi Després wrote:

Of course.

But note that free.fr users, of which I am, use native IPv6, without
NAT, and are happy this way.

Le ISPs  offer native IPv6 like free.fr and you will see.

I don't see this.

RD

---

From: Christian Huitema <[email-masked]>
Date: Fri, 28 Nov 2008 09:07:18 -0800

We really need to build consensus on the properties of NAT that people like, and want to carry over, versus the accidental properties that just make life harder for no good reason. Using the same address in many places is one of those accidental properties that end up causing real harm -- look at RFC 3879 for an analysis. But let's elevate the debate.

Most of the desired properties of NAT seem to fall in one category, "isolation". Isolate your management space from the rest of the Internet, so you can renumber your network without affecting partners. Isolate your computers from the Internet, so they won't be attacked. Isolate your addressing structure from the rest of the Internet, so it cannot be used as a tool to spy on you.

This property, "isolation", is fundamentally at odds with the end-to-end assumption embedded in the original IPv4 design. It is so much at odd that the IETF reaction to it as been, well, reactionary. Indeed, one of the big design principles of IPv6 was to maintain the end-to-end nature of Internet addresses, so the network works "as it was intended", and the filthy NAT genius is squeezed back in the bottle. And of course, I was very much part of this reactionary consensus.

If we want progress, we have to go beyond the reactionary attitude, and understand how we reconcile the two conflicting principles of end-to-end connectivity and selective isolation. Can we engineer selective isolation in the Internet while maintaining connectivity in all places where it is desired? Can we engineer that at the IP layer alone, or do we need to also evolve the naming system? What about TCP, IPSEC?

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Fri, 28 Nov 2008 18:12:21 +0100

> addressing behind a NAT would be a huge mistake.
I don't see why.
I know of course that site local addresses have been deprecated by RFC 3879.
But scope identifiers were indeed an unnecessary pain that to needed to 
be relieved.
Other considerations in RFC 3879 either shared with ULAs, or IMHO very 
debatable.

The proposal is no more than authorizing private addresses that are not 
necessary ULAs (constructing an ULA, according to section 3.2.2 with all 
the complexity of constructing one).

Now, instead of fc00::/8, I agree that a longer prefix would be 
sufficient, and therefore BETTER.
It could be for example a "wild card ULA", e.g. fc01::/48, suitable for 
those that don't plan to merge with any other site in the future.
Is this rejected as dramatically as fc00::/8?
> that address, but it may not be the right node.
Many people seem happy with net 10 addresses, both in residential and 
enterprise networks. 
Using these addresses is IMO a mistake, which these people most probably 
don't make.

> addresses only identify a node within a local scope (the same net 
> 10/site-local address is used for different nodes in different 
> sites).  This can create ambiguity about what node is being referred 
> to in cases where net 10 addresses leak out of the local site (in 
> referrals, MIBs, system logs, URIs, etc.).
All of this is very clear to me.
IMHO,  all referrals in IPv6 should be done with global addresses (keep 
it simple, stupid).

If we can't resolve anything now, waiting for another time will be fine 
with me.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 28 Nov 2008 18:22:38 +0100

Margaret,
Sorry the previous message was sent too fast, with some bugs in the text.
This one is more understandable.
RD

I don't see why.

The proposal is no more than authorizing private addresses that are not
necessary ULAs (constructing an ULA, according to section 3.2.2 of RFC 
4193 is far from trivial).

Using these addresses in referrals is IMO a mistake, which these people 
most probably don't make.

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Nov 2008 09:33:15 +1300

> But scope identifiers were indeed an unnecessary pain that to needed to

But that is exactly the reason why ambiguous address space causes
problems that *cannot* be fixed, and exactly the reason why ULAs
are better for all purposes than site-local. We cannot tell by looking
at a site-local address that reaches us whether it is in fact local,
or whether it came by accident from another scope (via a VPN bypassing
normal routing, or via a faulty referral of some kind). Whereas a ULA
that reaches us incorrectly is immediately known to be unroutable.

In other words ULAs are much more resistant to misconfiguration or
bad protocol design than site-locals. I'm strongly against legitimising
their use again.

    Brian

---

From: Dave Thaler <[email-masked]>
Date: Fri, 28 Nov 2008 17:28:36 -0800

> Behalf Of Iljitsch van Beijnum
> Sent: Thursday, November 27, 2008 11:24 AM
> To: Dave Thaler
> Cc: Behave Mailing List; Keith Moore; Eric Klein

That would at least be similar to v4-mapped addresses.

-Dave

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Nov 2008 20:30:33 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    >> It seems to me that perhaps the *IETF* should instruct IANA to
    >> create a new pool of addresses which are to be given out to
    >> SME/end users.  /56s or /60s.  These addresses will NEVER(%) be
    >> globally routable, but will: a) have whois.  b) have reverse DNS.
    >> c) be unique.

    Brian> Is that significantly different from the ULA-C proposal,
    Brian> which didn't gain consensus?
    Brian> http://tools.ietf.org/id/draft-mrw-6man-ulac-analysis-01.txt

  Probably not.
  I don't understand why ULA-C didn't fly.

--

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 28 Nov 2008 22:27:14 -0500

>  I don't understand why ULA-C didn't fly.

There was concerned that folks would get ULA-Cs andpay their ISP to  
route them, resulting in scaling problems with IPv6 core routing.  At  
that time, there was no provider-independent (PI) addressing  
anticipated in IPv6, and there was concern that ULA-Cs would become de  
facto PI address prefixes.

At this point, though, an enterprise can get a /48 PI prefix from ARIN  
for < $1500/year.  So, perhaps we should revisit ULA-Cs?

Margaret

---

From: "Eric Klein" <[email-masked]>
Date: Sat, 29 Nov 2008 12:33:23 +0200

> bad protocol design than site-locals. I'm strongly against legitimising

I agree with Brian, we need to have these clearly identified to prevent the
confussion of inside / outside that we currently have with multiple
occurances of the same 1918 address and tunnels are a good example of the
confussion. Another is the nesting problem: NAT in home <-> NAT in carrier
access network <->NAT in server end network. Also we currently
have a problem with lack of filtering for 1918 addresses out on the public
internet.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Eric Klein" <[email-masked]>
Date: Sat, 29 Nov 2008 12:45:17 +0200

On Fri, Nov 28, 2008 at 14:24, Rémi Després <[email-masked]> wrote:

> Using Fc00::/8 in IPv6 like 10.0.0.0/8 is used in IPv4 would make a lot of
> sense to me.
> This would be the prefix for "private IPv6", whith full freedom on how bits
> beyond the eigth are used.
>
This actually raises another point that no one has comment on (even though I
posed it several times): What are the rules for the old 1918 addresses under
v6? I presume that 0::0:10:x:x:x (and the rest) will still have to be
treated as local scope due to the problems we would have routing them in a
dual stack / transitional  world - maybe in 10 -15 years when the last v4
only hardware and software are retired will these be free to use again.

And if I am correct and these are going to still be local only then we don't
need FEC0:: /anything and everyone can (and probably will) do what they are
comfortable with from legacy v4 NAT anyway.
Eric
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Eric Klein" <[email-masked]>
Date: Sat, 29 Nov 2008 12:54:12 +0200

On Fri, Nov 28, 2008 at 19:07, Christian Huitema <
[email-masked]> wrote:

> We really need to build consensus on the properties of NAT that people
> like, and want to carry over, versus the accidental properties that just
> make life harder for no good reason. Using the same address in many places
> is one of those accidental properties that end up causing real harm -- look
> at RFC 3879 for an analysis. But let's elevate the debate.
>

Thank you

>
> Most of the desired properties of NAT seem to fall in one category,
> "isolation". Isolate your management space from the rest of the Internet, so
> you can renumber your network without affecting partners. Isolate your
> computers from the Internet, so they won't be attacked. Isolate your
> addressing structure from the rest of the Internet, so it cannot be used as
> a tool to spy on you.
>

This seems to be the key feature that people are discussing here on the
list. Other features  seem less important.

>
> This property, "isolation", is fundamentally at odds with the end-to-end
> assumption embedded in the original IPv4 design. It is so much at odd that
> the IETF reaction to it as been, well, reactionary. Indeed, one of the big
> design principles of IPv6 was to maintain the end-to-end nature of Internet
> addresses, so the network works "as it was intended", and the filthy NAT
> genius is squeezed back in the bottle. And of course, I was very much part
> of this reactionary consensus.
>

I presume you meant "the original IPv6 design" not "the original IPv4
design", if so I agree.

>
> If we want progress, we have to go beyond the reactionary attitude, and
> understand how we reconcile the two conflicting principles of end-to-end
> connectivity and selective isolation. Can we engineer selective isolation in
> the Internet while maintaining connectivity in all places where it is
> desired? Can we engineer that at the IP layer alone, or do we need to also
> evolve the naming system? What about TCP, IPSEC?
>

I think that if we can fix this at the IP layer then we can leave off work
at the application layer (TCP, FTP) from this WG and then the appropriate
WGs can address this based on a defined and working version of v6.
Eric
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 30 Nov 2008 18:05:13 +0100

On 28 nov 2008, at 21:33, Brian E Carpenter wrote:

> Whereas a ULA

Unfortunately, that's not the case. When ULAs were under discussion, I  
repeatedly asked the question whether ULA routability was to be a  
fundamental aspect of their design, or something imposed by the  
limitations of the routing infrastructure. As far as I remember, I  
never got a satisfactory answer to that.

So this means that when the RRG magically makes routing scale, some  
people will probably want to insert their ULAs into the routing  
system / routing overlay system and problems will ensue.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 Nov 2008 13:28:05 -0500

Iljitsch van Beijnum wrote:
> limitations of the routing infrastructure. As far as I remember, I never
> got a satisfactory answer to that.
> 
> people will probably want to insert their ULAs into the routing system /
> routing overlay system and problems will ensue.

ULAs are certainly not "known to be unroutable".  For that matter,
global PA addresses are not "known to be routable".

About the most that can be said is that hosts and applications have good
reason to assume that ULAs are less likely to be routable in the public
Internet than global PA addresses.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Dec 2008 11:17:53 +1300

> global PA addresses are not "known to be routable".

Not by the host, I agree. But the site routing system *does* know,
and will drop or forward packets accordingly. This is not the case
if the routers see FEC0::1 and that happens to exist locally - the packet
will be delivered, exactly the problem we have today with 10.1.1.1
and the like.

> Internet than global PA addresses.

That's true, but I was thinking about the certainty that they will get
a 'destination unreachable' for an extraneous ULA, versus the possibility
that a FEC0::/128 packet will be misdelivered.

In other words I can't see a single argument for bringing back an
ambiguous prefix.

    Brian