Subject: [nat66] My issues with NAT66

From: Fred Baker <[email-masked]>
Date: Thu, 26 Mar 2009 10:59:27 -0700

If I have problems with the NAT66 algorithm, it is the set of cases in  
which it can be defeated. Both of these have to do with routing.

In the first, if Alice served by Bob and Bobby, it is probable that  
Alice's administration lists both the Alice-via-Bob and the Alice-via- 
Bobby address in DNS. If Carol seeks to connect to Alice, Alice will  
pick among those addresses at random unless she has a good explicit  
reason to have an affinity to one of them. However, routing within  
Alice's network may choose a different exit gateway than the ingress  
gateway Carol in effect chose when she chose an address to use for  
Alice. Thus, when Carol sends a SYN to Alice-via-Bob, the SYN-ACK  
might come from Alice-via-Bobby. One hopes that Carol would eventually  
retry Alice-via-Bobby and get through.

Coming back to Keith's question of referrals, there is a security  
issue in hairpins. Let's imagine that in DNS Alice's administration  
also lists Alice-via-ULA, the request is from Alicia, and both  
Alicia's and Alice's nearest exit gateway is Bobby. If Alicia chooses  
to contact Alice-via-Bobby, the argument is that the NAT66 should  
either do or do something externally equivalent to translating it to  
Bobby's network, turning the packet around, and translating it back  
into Alice's network. But if Alicia chooses Alice-via-Bob, the packet  
will exit to Bob, change ISPs, and attempt to enter at the NAT66  
between Alice and Bob. While this would functionally work, it would  
violate my company's, and I presume many company's, information  
security rules - internal traffic is not allowed to go externally.  
Hence, they are likely to filter traffic to both Alice-via-Bob and  
Alice-via-Bobby at both NAT66 systems, with a view to forcing Alicia  
to use Alice-via-ULA. Alice can refer to her heart's content, but only  
using addresses that conform to the corporate security rules.

That said, I think both of these have trivial solutions.

To the first point, I need to prove this, but I think it would be  
anomalous for such communication exchanges to not settle down to a  
pair of addresses that work. If both Alice and Carol are using their  
egress gateways of choice, the setup of sessions would have the effect  
of selecting a pair of addresses that work. I can construct a case in  
which that is not true, but I have to work pretty hard.

To the second case, I have two observations. First, while this is  
unpopular with those who design DNS, those who run DNS usually have  
different DNS databases internally and externally. If the internal  
database uses ULA addresses and the external database uses Bob/Bobby  
addresses, and the application uses names rather than addresses, the  
issue largely falls out. Second, even if there is a common DNS, I  
would be amazed to find Alicia trying to access Alice-via-Bob or Alice- 
via-Bobby in preference to Alice-via-ULA, since Alicia and Alice have  
addresses from the same prefix, and RFC 3484 would tell Alicia to  
select that prefix.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 Mar 2009 11:36:28 -0700

Expanding on Fred's concerns about ways in which NAT66 can be  
defeated, the NAT66 discussion only covered in detail a very specific  
deployment in which a NAT66 translator (or perhaps a few) are placed  
between an "edge" network and the "core".  That deployment scenario is  
the one we usually think of, as it's the usual deployment model for  
NAT in IPv4.  If there is a chance NAT66 might be deployed in other  
scenarios, some of which might be unanticipated in the current NAT66  
docs.  I think it's important to analyze other NAT66 deployments -  
multiple NAT66 in a path, routing that results in the use of multiple  
paths, NAT66-inverse at a destination that "unNATs" the effect of a  
NAT66 - so we fully understand the effects of NAT66.

- Ralph

---

From: Roland Bless <[email-masked]>
Date: Thu, 26 Mar 2009 19:45:59 +0100

Hi Fred,

> which it can be defeated. Both of these have to do with routing.

My problem with NAT66 is:
it breaks end-to-end transparency unless you use
a SAF solution like Dave Thaler's. So if we buy
NAT for v6 I think we also buy in such a solution
(and it's not clear to me yet that it will work in nested
NAT realms etc.).

Regards,
 Roland

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 Mar 2009 17:35:02 -0700

> retry Alice-via-Bobby and get through.

It can get even worse is Carol is served by Dan and Danny. In the worse case, we get something like:

1) Carol sends a SYN to Alice-via-Bob. It gets routed through Dan, because of local preferences at Carol's network.
2) Alice sends a SYN-ACK to Carol-via-Dan. It gets routed through Bobby, due to local preferences at Alice's network.
3) Of course, the SYN-ACK gets dropped by the NAT66-via-Dan entry point in Carol's network.
4) Carol retries, sends a SYN to Alice-via-Bobby. It gets routed through Danny, because of local preferences at Carol's network.
5) Alice sends a SYN-ACK to Carol-via-Danny. It gets routed through Bob, due to local preferences at Alice's network.
6) Tough luck, uh..

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Mar 2009 18:59:53 -0700

On Mar 26, 2009, at 17:35, Christian Huitema wrote:
> [...]
> 5) Alice sends a SYN-ACK to Carol-via-Danny. It gets routed through  
> Bob, due to local preferences at Alice's network.
> 6) Tough luck, uh..

My preferred approach to the 6AI problem, i.e. combining source  
routing with route recording, does not seem to have this problem.  Let  
me describe how Christian's scenario works in a 6AI network as I would  
envision it (where Bob, Bobby, Dan and Danny are not translators, but  
instead routers that process shims accordingly):

1) Carol sends an unshimmed SYN to Bob's mapped address for Alice.  It  
gets routed through Dan, because of local preferences at Carol's  
network.  On the way out of Carol's network, it arrives at Bob with  
Dan's mapped source address for Carol.  Bob pushes its interior  
address into a route-recording shim and forwards to Alice.

2) Alice receives the shimmed SYN, copies the recorded interior  
address for Bob into the TCP control structure, sends a SYN-ACK to  
Dan's mapped address for Carol with a source routing shim specifying  
Bob's interior address. It gets routed back through Bob, despite local  
preferences for non-source-routed flows at Alice's network for Dan's  
address being to go out through Bobby.

3) Bob processes the source-routing shim from the SYN-ACK and forwards  
to Dan's mapped address for Carol, where the packet is forwarded after  
verifying that it matches the previously sent outbound SYN packet.

4) Dan does the same thing with the SYN-ACK that Bob did for the SYN  
and forwards to Carol.  Carol learns that a source route is  
appropriate for fixing the bidirectional path to Alice, copies the  
interior address for Dan into its TCP control structure, and uses the  
source-routing shim going forward with the session.

5) Epic connectivity fail avoided.

Naturally, we would need to design the shims so that multiple 6AI  
domains can be nested within one another. That means source-route and  
route-recording shims must each comprise multiple addresses in their  
paths.

Note: if outbound source-routing shim processing is defined to allow  
its *removal* when the source route is complete, then it's possible  
that sites using a mechanism like this need not even be aware that  
correspondent sites are using it.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Mar 2009 19:08:56 -0700

> correspondent sites are using it.

s/site using a mechanism like this/sites *not* using a mechanism like  
this/

---

From: james woodyatt <[email-masked]>
Date: Fri, 27 Mar 2009 08:52:24 -0700

On Mar 26, 2009, at 19:08, james woodyatt wrote:
>> Note: if outbound source-routing shim processing is defined to  
>> allow its *removal* when the source route is complete, then it's  
>> possible that sites using a mechanism like this need not even be  
>> aware that correspondent sites are using it.
>
> s/site using a mechanism like this/sites *not* using a mechanism  
> like this/

Ugh.  I'm looking at the notes I wrote to myself the last time I  
thought I might have time to write a draft about this, and now I'm  
remembering the reason I put it on the shelf: both sides of  
communication need to upgrade before the side that wants address  
independence can communicate.  There is also the other reason I put it  
on the shelf: it doesn't use translators, and people really really  
really want translators.

---

From: <[email-masked]>
Date: Thu, 26 Mar 2009 19:15:05 +0100

>From my perspective the NAT solution that might be specified within 6AI should be able to deal also with prefixes shorter, equal or _longer_ than a /48 since there might be ISPs giving out such longer prefixes to their customers.
(A reason for that are the changed RIR policies that allow the ISPs freely to decide if they want to give a /48, a /56 or even a /61 to its customers.)

Removing the /48 assumption will have major impact e.g. on Margarets draft.

br	olaf

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 28 Mar 2009 22:11:02 +0100

Its easy to change policies back if there is a good reason for doing so, and
in fact, not all the RIRs have changed the /48.

Furthermore, policies in some regions don't disallow /48, which means "if
you want to use NAT66, you need to use /48": good enough, right ?

I still believe the right approach is /48 and will simplify many things.

If we move ahead with /48 for NAT66, it is even a good reason for the
policies to be changed, which was not so evident before.

Regards,
Jordi

> From: <[email-masked]>
> Reply-To: <[email-masked]>
> Date: Thu, 26 Mar 2009 19:15:05 +0100
> To: <[email-masked]>
> Subject: [nat66] NAT66 / IPv6 NAT and assumption of /48
> 
> From my perspective the NAT solution that might be specified within 6AI should
> be able to deal also with prefixes shorter, equal or _longer_ than a /48 since
> there might be ISPs giving out such longer prefixes to their customers.
> (A reason for that are the changed RIR policies that allow the ISPs freely to
> decide if they want to give a /48, a /56 or even a /61 to its customers.)
> 
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Mar 2009 10:45:39 +1300

Yes, I think any prefix up /64 needs to work. But why not,
in a stateless NAT66?

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 28 Mar 2009 22:29:07 -0400

It would be highly desirable if, at least for lengths at or shorter than 
/64, the lower 64 bits if the IPv6 address field could normally be left 
unchanged by the NAT66.  This can easily be done for /48 or shorter 
prefixes.  If we are prepared to locate and modify the TCP/UDP 
checksums, it can easily be done for lengths /49../64.  But that is a 
nontrivial compelxity.  Keeping the requirement to /48 keeps the 
solution much simpler.

Yours,
Joel M. Halpern

---

From: Mark Townsley <[email-masked]>
Date: Sun, 29 Mar 2009 08:29:56 +0200

My ISP currently hands out a /60 via 6rd (space gets a little tight with 
the embedded IPv4 address). The BBF is settling on /56 as its 
recommended prefix size for residential customers. I've seen /64's out 
there as well (and stomped on them as quickly as possible, but can only 
do so much).

I have to agree that we must expect that variable prefix sizes to sites 
will be a reality.

- Mark

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 29 Mar 2009 13:47:43 -0700

For homes?  Or larger enterprises?

My original 6AI BOF request suggested multiple work items, two of  
which were:

(1) An information (or BCP?) document on how to build a home gateway  
for IPv6 that includes a firewall (for simple security) and prefix  
delegation, etc. for easy configuration, but no NAT functionality.

(2) NAT66 to provide address independence for enterprises.

Do we think that home users (regular home users, not us) actually need  
address independence, or they would be happy to get their addresses  
from their ISP via PD and to be renumbered when/if needed?

If we view NAT66 as applicable to home networks, I agree that we will  
need to handle prefixes longer than /48.  However, I expect that most  
enterprises will get /48 or larger.

Margaret

On Mar 28, 2009, at 11:29 PM, Mark Townsley wrote:

>
> My ISP currently hands out a /60 via 6rd (space gets a little tight  
> with the embedded IPv4 address). The BBF is settling on /56 as its  
> recommended prefix size for residential customers. I've seen /64's  
> out there as well (and stomped on them as quickly as possible, but  
> can only do so much).
>
> I have to agree that we must expect that variable prefix sizes to  
> sites will be a reality.
>
> - Mark
>
>> >From my perspective the NAT solution that might be specified  
>> within 6AI should be able to deal also with prefixes shorter, equal  
>> or _longer_ than a /48 since there might be ISPs giving out such  
>> longer prefixes to their customers.
>> (A reason for that are the changed RIR policies that allow the ISPs  
>> freely to decide if they want to give a /48, a /56 or even a /61 to  
>> its customers.)
>>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 30 Mar 2009 09:17:48 +0200

> For homes?  Or larger enterprises?
The problem is that the line is gray between the two.
> from their ISP via PD and to be renumbered when/if needed?
Regular home users, likely not (so your #1 is fine for that). Very large 
enterprises will probably get PI space and may or may not feel like the 
need a NAT66. Medium-sized businesses, particularly those on a budget, 
may well opt for "Business Broadband" - e.g., get a residential-type 
broadband service, and use it for their business. They certainly do 
today for IPv4 service, so I don't know why they would do otherwise for 
IPv6.

This is all really just crystal-ball gazing, but if one of the reasons 
we are going to build NAT66 openly in the IETF is to avoid vendors 
building it themselves, I find it hard to believe that targeting /48 
only will suffice. Certainly, if /48 service (along with a "compatible 
with IETF NAT66" bullet-point in the SLA) comes at a premium in terms of 
monthly service fees vs., say, a /56 or otherwise,  then you've given an 
incentive to small router vendors to build something that allows one to 
get all the advantages of /48-type service with a /56 service contract.  
Voila, the vendor gets to reap the difference between the service fees 
for /48 vs. /56... Much like they did for a /32 vs. /30 (or "multiple 
IP" service) in IPv4.... see where I'm going with this?

Point is, once the genie is out of the bottle, I don't think it is 
realistic to think that we can keep it backed into a /48 corner. 
Special-casing /48 may be worthwhile, but we need to somehow address the 
rest. Going "halfway" here could well be a classic worst of both worlds 
situation (i.e, we should either define NAT66 in full, or not at all).

> enterprises will get /48 or larger.
If the line between "home" and "enterprise" were solid, I would agree 
with you. But, it's not today, and (sadly) I don't think we can assume 
it will be for IPv6.

- Mark
>>> >From my perspective the NAT solution that might be specified within 
>>> 6AI should be able to deal also with prefixes shorter, equal or 
>>> _longer_ than a /48 since there might be ISPs giving out such longer 
>>> prefixes to their customers.

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 02:43:14 -0500

> IP" service) in IPv4.... see where I'm going with this?

It seems like one of the consequences of IETF defining NAT66 might then
be that it pushes us further down the "slippery slope" toward widespread
NAT in IPv6.  It's one thing if it turns out being used by medium sized
enterprises, quite another if it turns out appearing in every consumer
IPv6 router.  I'm actually much less concerned about the consequences of
NAT66 in medium enterprises (who can presumably make a technical
evaluation of the pros and cons of NAT for their particular business
needs and then choose whether to solve their say multihoming problem
with NAT or by some other means) than for home users (who are forced to
use NAT in IPv4 in part because a single address is all most can afford).

What I'd really hate would be for the existence of NAT in IPv6 and in
home routers to be used by ISPs as an excuse to dole out only /64s or
longer prefixes.

> situation (i.e, we should either define NAT66 in full, or not at all).

I really think it depends on what problems NAT66 is expected to solve.
There's a bit of the "Maslow's hammer" mentality about NAT these days -
NAT is such a familiar tool that people tend to see lots of different
problems as address translation problems rather than say, tunneling
problems.

As I tried to say in SF, we really need to decide which use cases of
NAT66 are justified (from an engineering perspective) and make sure that
the solution we develop in IETF actually addresses those cases.  Unless
we do that, we run a real risk of (a) developing a solution to one or
more non-problems, while (b) failing to develop solutions to bona fide
problems, with (c) the unintended consequence of promoting wider use of
NAT in IPv6 than is needed.

For instance, I'm pretty much convinced that the value from the degree
of topology hiding that can be accomplished by NAT66 is so small that
it's not worth the cost to deploy it.  There might be people who think
otherwise, but that doesn't compel IETF to spend its resources solving
their non-problem - especially when doing so legitimizes the idea of
IPv6 NAT in the public mindset.  (as certain members of the trade press
would love to crow about...)

If we were to determine (for example) that the only valid use case we
could find for NAT was for address independence, we could develop a
solution for just that case.  And we could call it something besides NAT.

Keith

---

From: <[email-masked]>
Date: Mon, 30 Mar 2009 12:46:53 +0200

Totally aggree on the lower 64 bit thing and that it will be easier to stay with an /48 prefix. But regarding the prefix we will not have a big choice since there are already longer prefixes  (/56 or /60) out there in real world scenarios.

Cu
	olaf

-----Ursprüngliche Nachricht-----
Von: Joel M. Halpern [mailto:[email-masked]] 
Gesendet: Sonntag, 29. März 2009 04:29
An: Bonneß, Olaf
Cc: [email-masked]
Betreff: Re: [nat66] NAT66 / IPv6 NAT and assumption of /48

Yours,
Joel M. Halpern

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 30 Mar 2009 10:04:39 -0400

... And ISP's could just say "we're only handing out one /128" because
we're expecting you to deploy NAPT66 - and there are plenty of vendors
willing to sell NAPT66 boxes...

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Keith Moore
Sent: Monday, March 30, 2009 3:43 AM
To: Mark Townsley (townsley)
Cc: Margaret Wasserman; [email-masked]; [email-masked]
Subject: Re: [nat66] NAT66 / IPv6 NAT and assumption of /48

> with IETF NAT66" bullet-point in the SLA) comes at a premium in terms 
> of monthly service fees vs., say, a /56 or otherwise,  then you've 
> given an incentive to small router vendors to build something that 
> allows one to get all the advantages of /48-type service with a /56
service contract.

use NAT in IPv4 in part because a single address is all most can
afford).

> Special-casing /48 may be worthwhile, but we need to somehow address 
> the rest. Going "halfway" here could well be a classic worst of both 
> worlds situation (i.e, we should either define NAT66 in full, or not
at all).

If we were to determine (for example) that the only valid use case we
could find for NAT was for address independence, we could develop a
solution for just that case.  And we could call it something besides
NAT.

Keith

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Mar 2009 10:12:10 -0400

Yes, they could.
If that allowed them to save something somewhere else.
Since I don't see why it would save them anything, it would seem that if 
we can give them reasoanble ways to behave they will do so.

Yours,
Joel

PS: Yes, some operators are handing out /60s.  They seem to be operating 
from a fear of scarcity and a lack of understanding of how much space 
they have.

---

From: [email-masked]
Date: Mon, 30 Mar 2009 14:18:14 +0000

The cynic in me says they might do it just so they could charge more for more ... ?

/TJ
PS - some ISPs are also going to hand-out /60s to clients, and hold onto the 'saved' 4 bits for misc. service delivery / future growth to that client (not my idea, just sharing with the class!)
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "Joel M. Halpern" <[email-masked]>

Date: Mon, 30 Mar 2009 10:12:10 
To: Wes Beebee (wbeebee)<[email-masked]>
Cc: Margaret Wasserman<[email-masked]>; <[email-masked]>; Keith Moore<[email-masked]>; <[email-masked]>
Subject: Re: [nat66] NAT66 / IPv6 NAT and assumption of /48

Yes, they could.

Yours,
Joel

---

From: Roland Bless <[email-masked]>
Date: Mon, 30 Mar 2009 16:37:43 +0200

Hi Wes,

> willing to sell NAPT66 boxes...

probably, another incentive for NAPT may be the poorly understood
"topology hiding" feature. I really fear that once NAT66 is out it's
going to be pushed further from a 1:1 mapping towards a 1:n mapping and
even NAPT due to unnecessary address costiveness or topology hiding.

Regards,
 Roland

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 10:05:35 -0500

> we can give them reasoanble ways to behave they will do so.

handing out /128 doesn't seem that likely.  but handing out prefixes of
/64 seems more plausible, particularly if it helps some ISPs roll out
IPv6 with existing equipment designed for IPv4.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 30 Mar 2009 17:41:13 +0200

I'm in contact with a lot of broadband providers deploying and thinking 
about deploying IPv6, and have never seen one seriously consider /128. 
/64, yes. /60 certainly. But never /128.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Mon, 30 Mar 2009 17:43:51 +0200

Joel M. Halpern wrote:
> Since I don't see why it would save them anything, it would seem that 
> if we can give them reasoanble ways to behave they will do so.
>
> Yours,
> Joel
>
> PS: Yes, some operators are handing out /60s.  They seem to be 
> operating from a fear of scarcity and a lack of understanding of how 
> much space they have.
Or, because they are a relatively small provider embedding an IPv4 
address in their site prefix as part of their transition mechanism.

- Mark

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 30 Mar 2009 11:57:10 -0400

> /64, yes. /60 certainly. But never /128.

I'm too "in contact with a lot of broadband providers deploying and
thinking about deploying IPv6".

and some were first thinking to give a /128 as the "basic service", even
after some education on how "IPv6 works"... The possible arrival of
6ai/nat66 has already bring back this notion of /128, since it "just
maps" with their current v4 deployment/billing/OSS/...

note that I don't think /128+nat66-6ai is a good idea, but I would
certainly be careful claiming that it would not happen or it is not on
the design table.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Mark Townsley <[email-masked]>
Date: Mon, 30 Mar 2009 18:17:46 +0200

My experience is that those brand new to IPv6 (and who don't do some 
reading up front) first think of offering a /128, but are quickly 
convinced that /64 is the real minimum (which is why I said I had never 
seen one "seriously" consider a /128). Then, after some time, they can 
be convinced to move the line up to a /56, but it takes a second push - 
one that's a little bit harder than the first. Going further, to a /48, 
is often a tough sell for residential.

That's my experience at least, YMMV. I've never actually seen a 
residential /128 service, though I have seen /64, /60, /56 and /48.

- Mark

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 30 Mar 2009 12:09:57 -0700

While there are certainly people that want to differentiate service levels
based on prefix length, most of the providers I have talked to have started
from an invalid assumption that all they can get is a /32, then dividing
that up by their current customer base results in long prefixes. They really
do need to flip that over, taking a plan to their RIR for customer-base *
planned-prefix-length to get a realistic allocation to begin with.

In any case, the 66nat effort is a solution looking for a problem, but if it
does exist it should be based on technical rather than policy issues. CGA is
a reason to keep the low order 64 bits intact, and checksum adjustment is
reason to have a 16-bit modifier. This combination means that if people
really-really-really have to have their hallucinogenic 66nat drug, they have
to figure out a way to deal with the policy issues to get a /48. Note: they
could just use 6to4 and they are already there...

Tony 

> Of Mark Townsley
> Sent: Monday, March 30, 2009 9:18 AM
> To: Marc Blanchet
> Cc: [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Mar 2009 16:41:01 -0700

On Mar 30, 2009, at 00:17, Mark Townsley wrote:
> Certainly, if /48 service (along with a "compatible with IETF NAT66"  
> bullet-point in the SLA) comes at a premium in terms of monthly  
> service fees vs., say, a /56 or otherwise,  then you've given an  
> incentive to small router vendors to build something that allows one  
> to get all the advantages of /48-type service with a /56 service  
> contract.  Voila, the vendor gets to reap the difference between the  
> service fees for /48 vs. /56... Much like they did for a /32 vs. /30  
> (or "multiple IP" service) in IPv4.... see where I'm going with this?

This is the argument I attempted to make in the 6AI session in San  
Francisco last week when I ranted about how we're hand-waving away  
address amplification as a perceived benefit of NAT deployment for  
IPv6.  I had hoped that hearing it come from a member in the  
engineering team for a line of small router products made by one of  
the major vendors in the market might help clarify the issue for some.

I also pointed out that this feature would be deployed by small router  
vendors to permit networks to obtain something like Internet  
connectivity from providers who restrict service only to hosts, i.e.  
those that do not delegate any prefix at all.

Anyone who thinks that captive network service providers (like, say,  
those serving hotel guests) won't eventually recognize there's a huge  
incentive for them to charge per host instead of per network  
demarcation point is willfully ignoring more than a century of  
telecommunications industry economic history.  If one can't find any  
providers currently thinking that's how they'll sell IPv6 service,  
then it only means one hasn't asked the ones with mono- or  
oligopolistic market power.

Or one *has* asked them, they've quite naturally not told the truth,  
and for some unearthly reason, one has chosen to believe them anyway.

It would be very good if we could stop pretending that address  
amplification isn't among the reasons users could have for wanting to  
deploy NAT for IPv6.  If the point of this exercise is to set a  
standard for 6AI before clueless router vendors do something that  
breaks the Internet for all time, then leaving support for address  
amplification out of the standard will only delay the inevitable  
damage you're trying to prevent.

We'll be writing a standard for a NAT that nobody uses, and the NATs  
that everyone will use will be the non-standard ones we're hoping to  
make unnecessary.  How embarrassing will *THAT* be in retrospect?

If we can find a way for the standard to require A) that address realm  
gateways MUST implement RSIP servers and B) that hosts in private  
realms MUST use RSIP clients to obtain public connectivity, then maybe  
we can make some progress here.  But, since RSIP by itself is not  
NAT-- it's only an *optional* enhancement for NAT clients and  
gateways-- the first step in making RSIP mandatory for IPv6 address  
realm traversal instead of NAT66 is to declare, well, that NAT66 Is  
Evil.

Yet, as we have already decided that "NAT66 Is Evil" is an unwelcome  
view in this BOF, it seems there is little hope for any productive  
work to come out of this effort until that changes.

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Mar 2009 22:47:46 -0500

(do not taunt Happy Fun Ball)

james woodyatt wrote:
> IPv6.  I had hoped that hearing it come from a member in the engineering
> team for a line of small router products made by one of the major
> vendors in the market might help clarify the issue for some.

Actually I suspect the set of SOHO router customers who couldn't make do
with a /56 (or really, even a /64) *without* NATting is relatively small.

A more relevant concern might be the use of NAT as part of
autoconfiguration.  The typical v4 NAT just gets one address via PPP or
DHCP and from there it serves a great many hosts.  But you can plug
another NAT into the back side of the first NAT and it will do the same
thing.  In this way, NATs implement a form of the "catenet" model and
they do it without any explicit configuration.  Sure it sucks in lots of
different ways, but overall it's a very nice feature for casual users.

(Seems like once upon a time I read about some IPv6 DHCP options or some
other ways for a downstream router to grab some allocation from an
upstream router -- but I didn't keep up with it, so I don't know whether
it ever survived its journey through the swamp.  But I think it's fair
to say that if IPv6 SOHO routers aren't given a better way to do
autoconf even in the presence of nested routers, they'll use NAT.)

> those that do not delegate any prefix at all.

In general, when there's a tussle between the ISPs and their customers,
it's hard to expect the router vendors to not try to help the customers
pull from their end of things.  Though this might not be much of an
issue as long as there is competition between ISPs.

> incentive for them to charge per host instead of per network demarcation
> point is willfully ignoring more than a century of telecommunications
> industry economic history. 

True, but I'm not sure what that has to do with NAT.  The hotels (and
airports, etc.) can and will charge per MAC address, just like they do
with IPv4.  Customers can drag IPv6 NATs along with them if they want
(or use "Internet sharing" software in their PCs).  (And if the hotels
network providers work hard enough, they can detect the use of NAT and
pessimimize the connection quality.)

In general, it seems like the thing for IETF to do is not try to
completely forbid IPv6 NAT, but instead write specifications in such a
way that IPv6 NAT is seen as the last resort... and try to solve the
problems in other ways so that NAT is a corner case rather than the
general case.  That eases the burden on software developers - they can
deal with NAT if they want to, but hopefully most of the market won't
have NAT so most applications won't have to deal with it - thus making
most things less complex and more reliable.

> If one can't find any providers currently thinking that's how they'll
> sell IPv6 service, then it only means one
> hasn't asked the ones with mono- or oligopolistic market power.

Well, those same providers would very much like to do differential
charging for traffic (based on destination port or destination address),
but for the most part they haven't done so yet, and there's pressure
from governments and public interest groups to not do the latter.  So it
is at least possible that they'll hold off on "per host" billing for awhile.

> deploy NAT for IPv6. 

Of course it is a reason.  But I can't tell how big a reason it is.  And
a lot of that depends on just what ISP IPv6 service offerings look like
a year or three from now.  I don't see how to evaluate that at this point.

But the point is clear - the ISPs can kill e2e v6 if they want to.  And
what's more, the impending exhaustion of v4 address space may give them
sufficient ammunition to do so.  Soon IPv4 may suck badly enough that
IPv6 only has to work marginally better to get customers to switch to
it.  e.g. A single v6 /64 with no port restriction and a NAT-PT for
legacy v4 access, might well look more attractive to a customer than a
NATted, shared v4 address with port restrictions.

> view in this BOF, it seems there is little hope for any productive work
> to come out of this effort until that changes.

Of course NAT66 is evil.  We should all acknowledge that at the start so
that we don't have to debate it.  The question is whether we can make it
less evil, and/or promote even lesser evils as alternatives to NAT66.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 31 Mar 2009 11:36:57 -0400

It sounds like we are fairly certain that homes and some small  
businesses will be given prefixes longer than /48 by their providers.   
Are we also convinced that those small networks will require the  
address independence feature provided by NAT66?  I guess this question  
boils down to whether we expect two (or more) hosts within a small  
network to communicate directly with each other using global IPv6  
addresses.

If we do need to address prefixes of longer than /48 in NAT66, that is  
fairly easy to do.  We just need to pick which sacrifices we are  
willing to make.  I can think of two choices:

(1) Add the checksum correction to a 2byte portion of the lower 64  
bits when the prefix is longer than /48, thus modifying the IID.  This  
wouldn't be compatible with (currently unspecified) mechanisms that  
require a constant IID, but we would already have that problem with  
nodes that generate privacy addresses.

or

(2) Fix the UDP or TCP checksum instead of performing the checksum  
correction algorithm when the prefix is longer than /48.  The cost  
here is that we lose the ability to encrypt/protect the transport  
layer headers.  In NAT66, we could explicitly make this correction for  
UDP/TCP only, passing through other transport layers unmodified, which  
might help to reduce the impact on new innovations at the transport  
layer.

Margaret

On Mar 30, 2009, at 12:17 PM, Mark Townsley wrote:

> convinced that /64 is the real minimum (which is why I said I had  
> never seen one "seriously" consider a /128). Then, after some time,  
> they can be convinced to move the line up to a /56, but it takes a  
> second push - one that's a little bit harder than the first. Going  
> further, to a /48, is often a tough sell for residential.
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 31 Mar 2009 18:28:44 +0200

> NAT in IPv6 than is needed.
Not only do I fully agree with this, but I worked on both problem 
analysis and solution design. The current result is in 
_draft-despres-sam-02_. (Sec. 2. is "NAT44 services that remain 
desirable in IPv6"; Sec. 5 is "Avoiding using NATs in IPv6 with SAM").

You should be interested in reading it, and I look forward to your 
reactions.

Note that this document was not presented at the 6AI BOF, despite its 
being cited as relevant by Dan Wing, for a reason given in the BOF charter:
 "This BOF will use IPv6-to-IPv6 Network Address Translation (NAT66) 
draft-mrw-behave-nat66-02.txt as the basis discussion of address 
independence for IPv6 solution. Other IPv6 address independence 
solutions will be considered if a working group is formed, but for the 
purpose of determining consensus to form a working group, only this 
solution will be in scope."

Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 31 Mar 2009 19:02:33 +0200

> a year or three from now.  I don't see how to evaluate that at this point.

In the SAM draft, "host-rooted subnets" are included as a useful service 
of NAT44s.

The ability to deploy subnets behind nodes that are seen as hosts (i.e. 
without adding the prefix delegation mechanism to that of address 
assignments) is IMHO something to be also available in IPv6, preferably 
with at least one way to avoid sacrificing e2e transparency.

Although I am convinced that SAM still needs work, I do believe that it 
is a fairly advanced approach toward a solution to this problem.

Regards,

RD

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Mar 2009 13:20:24 -0400

Margaret Wasserman wrote:
> Are we also convinced that those small networks will require the address
> independence feature provided by NAT66?  I guess this question boils
> down to whether we expect two (or more) hosts within a small network to
> communicate directly with each other using global IPv6 addresses.

... and that those applications and networks cannot reasonably survive
an occasional renumbering.

I am personally of the opinion that all applications, and all networks,
need to be engineered to be able to tolerate an occasional renumbering.
 But of course this isn't always the case.  And renumbering is more
difficult to do for large networks than for small ones.  For some value
of "small" I don't think renumbering is onerous.   But even a /52
network can be quite large (assuming networks are delegated on nybble
boundaries due to DNS concerns).  So I think it's a stretch to assume
that any network smaller than /48 will be engineered to tolerate
occasional renumbering.

I therefore conclude that IF ISPs don't uniformly delegate /48s to
enterprise networks, there will be some market demand for IPv6 NATs to
provide address independence.

It strikes me that one of the outputs of this WG (if formed) might well
be a reinforcement of the message that /48 really is a minimum network
size (maximum prefix length) for any network of significant size, for
reasons not understood when that recommendation was originally made.

(note the existence of a tussle between ISPs who might like to make
decisions which have the unintended consequence of encouraging NAT, and
application developers who bear increased costs as a consequence of
those decisions)

> fairly easy to do.  We just need to pick which sacrifices we are willing
> to make.  I can think of two choices:
> 
> (1) Add the checksum correction to a 2byte portion of the lower 64 bits
> when the prefix is longer than /48, thus modifying the IID.  This
> correction algorithm when the prefix is longer than /48.  The cost here
> is that we lose the ability to encrypt/protect the transport layer
> headers.  In NAT66, we could explicitly make this correction for UDP/TCP
> only, passing through other transport layers unmodified, which might
> help to reduce the impact on new innovations at the transport layer.
> 

I think it's going to be difficult to insist that every use of IPv6 NAT
is one where the prefix is /48 or shorter.  Clearly there's an advantage
in doing the checksum correction in the address when feasible, but I
doubt it's always going to be feasible.

But we won't know for sure until we enumerate all of the use cases and
clearly establish which ones have merit.

Keith

---

From: Rémi Després <[email-masked]>
Date: Tue, 31 Mar 2009 19:44:05 +0200

Margaret Wasserman  -  le (m/j/a) 3/31/09 5:36 PM:

> headers.

I don't understand the point.

If the transport protocol is neither UDP nor TCP, is it not true that 
doing or not doing further address modification after prefix replacement 
(for UDP/TCP checksums to be unchanged) has no effect on whatever 
encrypt/protect mechanism this transport might introduce?

Maybe you could explain more.

In any case, I support this second choice (simple and guaranteed to 
work).

Regards,

RD

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 31 Mar 2009 13:52:20 -0400

On Mar 31, 2009, at 1:44 PM, Rémi Després wrote:
>
> If the transport protocol is neither UDP nor TCP, is it not true  
> that doing or not doing further address modification after prefix  
> replacement (for UDP/TCP checksums to be unchanged) has no effect on  
> whatever encrypt/protect mechanism this transport might introduce?

It is altogether possible to create a transport that doesn't do  
anything to checksum, encrypt or protect the IP address that appear in  
the IP header.  SCTP is one example, as I understand it.

Margaret