Subject: Lack of need for 66nat : Long term impact to application developers

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Nov 2008 21:39:02 -0600

The discussion today in Behave shows there is very strong peer-pressure
group-think with no serious analysis of the long term implications about
what is being discussed. I requested we pop this up a level to talk about
'make things better' by focusing on ---who--- we are making it better for.
The closest we came to that was Townsley's discussion about spec'ing
something in the short term for the people that are building 46/64 nats to
make their job easier. 

There is a ---very--- large issue here related to the application developers
and end users need to deal with topology warts. In IPv4, nat became
necessary due to the limited address range, so establishing some rules
through Behave made sense to minimize the kinds of impacts that applications
would have to deal with. So far there has not been any valid need documented
for why a 66nat should exist. Just the lame, 'they will be built anyway'
group-think of the mob.

If there is a valid need, yes Behave should make sure we minimize the kinds
of impacts that applications have to deal with. Lacking a valid need,
standardizing 66nat only ensures that applications will have to deal with
these unnecessary topology warts ---forever---. This is ---NOT--- making
things 'better' for applications developers, and end users. Making it easier
for a few product vendors to throw in 66nat while they are doing 46/64 is
not in the long term best interest of the Internet, and therefore the IETF
should not be doing this work. 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.

Rewind the clock, and note that as chair of ngtrans I tried very hard to
categorize the nat-pt effort as experimental, but the IESG and IETF chair of
the time overruled that in the face of group-think pressure to have a
standards track document. Fast forward to RFC 4966 where that decision was
reversed in the face of deployment evidence showing an experiment gone awry.
I ask myself what is different about the 66nat discussion, and the only
thing I can come up with is that the applications development community is
not aware and voicing their objections to this discussion, and that there
will be no way to recall this nonsense through a simple change of status
once they do, because the products will have long since been widely deployed
through default configurations (unlike nat-pt). 

Tony

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Sat, 22 Nov 2008 07:20:41 -0600

Tony,

I have not yet formed even my own opinion on what to do with NAT66. I do 
agree with you though that we need to think carefully what we are doing. 
What the IETF does here will have a significant impact*. We do need 
wider community discussion on this. I have also asked the IP directorate 
and IAB to provide feedback on what they think should be done here. I do 
hope though that we keep our focus on completing the IPv4-IPv6 
co-existence work that is going on in Behave, rather than spend all our 
energy on debating new work...

Jari

*) Even if it should be understood that vendors make their own decisions 
independently of the IETF, some of the similar application implications 
may exist due to other reasons such as firewalls, etc.

---

From: Ted Hardie <[email-masked]>
Date: Sat, 22 Nov 2008 08:34:37 -0600

>may exist due to other reasons such as firewalls, etc.

The warts due to firewalls  are very different from those due to topology shifting
from an application-layer perspective.  I think the ICE and ICE-TCP documents
ought to give everyone serious pause about creating NATs in v6 space; even
with all the work ICE requires (a rendezvous protocol, relay servers, candidate
gathering etc.) they do not work anywhere close to a 100% of the time.  As
originally specified, I seem to recall ice-tcp succeeded something like 40%
in the real world.

Tony's point is architectural, and I agree with it.  The folks who are arguing
that the practical trumps the architectural here are also very likely to be wrong,
as the practical consequences here are painful indeed.
			regards,

				Ted

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Sun, 23 Nov 2008 10:33:26 +0200

On Saturday 22 November 2008 05:39:02 ext Tony Hain, you wrote:
> There is a ---very--- large issue here related to the application
> developers and end users need to deal with topology warts. In IPv4, nat
> became necessary due to the limited address range, so establishing some
> rules through Behave made sense to minimize the kinds of impacts that
> applications would have to deal with. So far there has not been any valid
> need documented for why a 66nat should exist. Just the lame, 'they will be
> built anyway' group-think of the mob.

Because "they will be built anyway", application developpers will continue to 
try to design application-layer protocols around them. From that sole 
perspective, it does not matter than much whether IETF specifies NAT66. It 
matters whether IETF designs layer>=4 protocols that cope with NAT66 
which "will be built anyway".

That being noted, history shows that IETF has designed lots of protocols that 
do not cope with NAT44, especially before BEHAVE (at least in Transport, 
Internet and RAI areas). And the similarity with the SBC "problem" in RAI 
area is too striking to not mention it. In other words, I am not very 
optimistic about IETF coping with NAT66, if it ends up not being specified 
_yet_ widely deployed. Eventually, the long-term relevance of -several areas 
of the- IETF is at stake.

On the other hand, as I said at the mike, the very fact that IETF would 
specify NAT66 will be an excuse for vendors to ship it. In the end, I expect 
we'd end up with "better" but more widely deployed NAT66. I don't claim to 
know which way would be best. I just hope that NAT66 is NOT deployed in 
access and unmanaged IPv6 networks in any case, and shall stick to 
managed/corporate policed networks. That is why I argued for a clear 
unambiguous applicability statement to NAT66 should the IETF go forward with 
it.

> these unnecessary topology warts ---forever---.

> This is ---NOT--- making things 'better' for applications developers, and
> end users.

The fact that vendors claim they're going to do it anyway makes me feel like 
we really should standardize it anyway. The point is precisely to limit its 
bad impact upon application developpers and users.

The only reason why I'm personaly undecided is the fear that standardizing it 
also makes it -needlessly- more widespread that if it were not specified.

> Making it easier for a few product vendors to throw in 66nat while they are
> doing  46/64 is not in the long term best interest of the Internet, and
> therefore the IETF should not be doing this work. 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.

Makes me think...

I was largely over-hummed in favor of only specifying TCP & UDP for NAT64 at 
the second BEHAVE session. I don't know in which camp you were (if any). But 
I have to say that the only "reason" why someone would want to stick to TCP & 
UDP only, is to be able to re-use existing NAT44 implementations and extend 
them to do NAT64.

If that's the case, then they will NOT follow the BEHAVE specs (since most 
NAT44 don't), not even for UDP and TCP. Then why would NAT66 follow a 
would-be IETF RFC on NAT66 either?

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 23 Nov 2008 12:25:56 -0700

This is not anti-nat religion. There are costs that every application
developer has to absorb to deal with topology warts, and the people that are
focused on their little part of the problem space refuse to acknowledge
those costs. They also refuse to recognize the fact that these costs are
multiplied many times over due to the breadth of the application development
space. In terms of the overall costs to the system, squeezing a cost out of
the core forces a much larger cost spread all around the edges. 

The fundamental problem here is that the voices of those bearing the costs
in the core are being represented, while the voices of those doing
application development are not being heard. 

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Fred Baker
> Sent: Friday, November 21, 2008 10:08 PM
> To: [email-masked]
> Cc: [email-masked] WG; IAB; IETF Discussion; IESG IESG
> Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
> application developers
> 
> 
> On Nov 21, 2008, at 9:39 PM, Tony Hain wrote:
> 
> > The discussion today in Behave shows there is very strong peer-
> > pressure group-think with no serious analysis of the long term
> > implications about what is being discussed.
> 
> Yes, there is a very clear anti-NAT religion that drives a lot of
> thought. It's not clear that any other opinion is tolerated.
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 24 Nov 2008 08:46:56 -0500

On Nov 24, 2008, at 5:56 AM, Eric Klein wrote:
>
> We need a team made up of both sides to sit down, spell out what are  
> the functions of NAT (using v4 as a basis) and then to see if:
> 1. If they are still relevant (like number shortage from v4 is not  
> the same issue under v6 for example)
> 2. Do they already exist in v6 without adding NAT

This was already done, and the results are in RFC 4864.

> Then we need to check:
> 1. Is there is a solution by using NAT
> 2. Is there is a better solution than using NAT

#2 was done in the gap analysis section of RFC 4864.

I'm not sure what you mean by #1, because if you start with a list of  
the functions of NAT, the fact that NAT can be used for those  
functions just follows, doesn't it?

>  Only then can we make a proper and informed decission on what is  
> needed and what is unneeded legacy.

I think we are ready to do this, based on the information in RFC  
4864.  Do you see anything missing from 4864 that needs to be analyzed  
further? If so, could you send specific points, and perhaps we can  
consider an update?

Margaret

---

From: Fred Baker <[email-masked]>
Date: Fri, 21 Nov 2008 23:07:37 -0600

---

From: "Eric Klein" <[email-masked]>
Date: Mon, 24 Nov 2008 12:56:26 +0200

On Sat, Nov 22, 2008 at 7:07 AM, Fred Baker <[email-masked]> wrote:

>> what is being discussed.
> Yes, there is a very clear anti-NAT religion that drives a lot of thought.
> It's not clear that any other opinion is tolerated.
>
Fred,

I pesonally would be open to a real discussion about the needs and then
about the solution. But for now NAT has taken on religious connotations with
those who are for it being as single minded as those who are against it.

We need a team made up of both sides to sit down, spell out what are the
functions of NAT (using v4 as a basis) and then to see if:
1. If they are still relevant (like number shortage from v4 is not the same
issue under v6 for example)
2. Do they already exist in v6 without adding NAT

Then we need to check:

Only then can we make a proper and informed decission on what is needed and
what is unneeded legacy.
Eric
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Marc Manthey <[email-masked]>
Date: Mon, 24 Nov 2008 18:16:52 +0100

> thought. It's not clear that any other opinion is tolerated.

But if we had enough ipv4 adresses in the 90th,  we would not  even  
consider talking about it.

sorry just my 50 cents

regards

Marc

--
web : http://www.let.de
PGP/GnuPG: 0x1ac02f3296b12b4d  jabber :[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 24 Nov 2008 19:11:57 +0100

I would encourage a discussion on what overall services and  
architectures we are looking at for the future of the Internet. I see  
mainly three camps, the ones being interested in situations where the  
ISP is in strong control (and responsibilities) over quality,  
addressing, services etc. I normally call these "vertically integrated  
solutions". The second group are the one-to-many applications, where  
users explicitly or implicitly connect to a server from where they get  
information they want. These are the Googles, Spotify, Facebook, but  
also many p2p solutions that have self-elected supernodes acting as  
rendezvous point.

The third group which I think is the most interesting one include the  
many-to-many applications. Where end users really try to connect to  
their own computer at home when they travel. When two persons really  
try to communicate with each other without any broker. With some very  
limited rendezvous mechanism, like DNS or other naming services, but  
no broker/rendezvous on the application layer. Almost only Apple is  
trying to do these things I claim. But I really really really hope I  
am wrong as I want to see more of this myself.

Will the future ip-layer handle these many to many applications, or  
will this be resolved by having even more overlay networks on top of  
HTTP or something similar, where these overlay networks are built  
automatically using supernodes?

There are both scaling and addressing issues in here. On many layers  
in the architecture.

    Patrik

---

From: Peter Dambier <[email-masked]>
Date: Mon, 24 Nov 2008 23:01:20 +0100

Hi Eric,

I would like to be part of that group.

My little network is connected to the internet
via a NAT router and I could not live without
it because daily renumbering wont do.

On the other hand that NAT-box is the biggest
obstacle between my network and IPv6.

I would like to help design a NAT that is not
an obstacle but a stepping stone.

Kind regards
Peter

Eric Klein wrote:
> 
> 
> On Sat, Nov 22, 2008 at 7:07 AM, Fred Baker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>         The discussion today in Behave shows there is very strong
>         peer-pressure group-think with no serious analysis of the long
>         term implications about what is being discussed.
> 
> 
> about the solution. But for now NAT has taken on religious connotations
> with those who are for it being as single minded as those who are
> against it.
>  
> 1. If they are still relevant (like number shortage from v4 is not the
> same issue under v6 for example)
> Only then can we make a proper and informed decission on what is needed
> and what is unneeded legacy.
> Eric
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Nov 2008 18:19:19 +0100

> application development are not being heard.

Not sure that's entirely true...

But in any event, compared to the backflips through flaming hoops we  
have to do in IPv4, the asking a remote server what our source address  
looks like from the outside to make address based referrals work  
doesn't seem too onerous. Or do you disagree?
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Nov 2008 15:19:13 -0500

Iljitsch van Beijnum wrote:
> looks like from the outside to make address based referrals work doesn't
> seem too onerous. Or do you disagree?

absolutely it's too onerous.  why in the world should an application's
deployability depend on the existence of a server that lives in global
address space -- or for that matter, on a bank of servers that exist to
do nothing but forward traffic?  isn't that what the network is supposed
to do?

Keith

---

From: David Morris <[email-masked]>
Date: Tue, 25 Nov 2008 13:26:24 -0800 (PST)

> do nothing but forward traffic?  isn't that what the network is supposed

Actually, he did not say the server forwarded traffic, just that it
provided a way to learn how 'my' address was mapped through 'my' nat. A
ip-ip mapping lookup service, probably not all that different than DNS or
the service the telcos use to map 8xx numbers to actual phones, or phone
numbers to specific terminal devices on specific carriers.

I don't know if that is a good approach or not but I find it quite a bit
less onerous than routing all traffic via an intermediate server. And it
seemed the question wasn't understood.

Dave Morris

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 25 Nov 2008 14:10:42 -0800

...
> doesn't seem too onerous. Or do you disagree?

Who do you ask??? Your note assumes there is only one 'outside', so any
server could answer the question. There is absolutely no restriction on
where and how topology warts are deployed, so asking a server in network A
what your address will appear to be to network B is fundamentally absurd. I
have heard similar comments from the document authors recognizing this
problem, but hand-waving something about asking a service before populating
DNS, while completely ignoring the fact that there is no way to predict in
advance who will want to know or where they will be attached. Essentially a
server is not reachable until it guesses that network B exists, someone
wants to contact it from there, and where the service is to ask about the
address that the server appears to be. 

There is no valid reason for 66nat. The only justifications being given are
'people will do it anyway', and 'we have to move quickly because vendors are
trying to build it'. This is called railroading in any other context, and
absolutely no long term thought is going into the impact and inability to
remove this once it is unleashed. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Nov 2008 17:43:01 -0500

David Morris wrote:

> provided a way to learn how 'my' address was mapped through 'my' nat. 

I understand.  But in practice just knowing your external address is
often insufficient.  You need an intermediate server that will forward
traffic as well as maintain the bindings in both (nay, all) endpoints' NATs.

If we're going to standardize NATs of any kind, they need to be defined
in such a way that no "external" server is necessary - not to determine
one's external IP address, nor to forward traffic between hosts that are
all behind NATs, nor to maintain state in the NAT, nor to determine a
host's 'external' IP address or port, nor to listen for traffic intended
for a host behind a NAT.  All of this functionality (and more) needs to
be "built in" to the NAT itself.

Furthermore it's not sufficient to just define a NAT with a
bidirectional, algorithmic mapping (in order to avoid some of these
problems) because what people have come to expect from NAT (and to rely
on) is that incoming connections are denied by default.

So really, to be viable, any NAT standard needs to include some amount
of firewall functionality.  And the firewall needs to be able to keep
working even if the NAT function is turned off.

Keith

---

From: Peter Dambier <[email-masked]>
Date: Tue, 25 Nov 2008 23:46:27 +0100

> do nothing but forward traffic?  isn't that what the network is supposed

That is what bothers me too. sip is mostly peer to peer, so for most
of your communication (in megabytes) no server in a rack needed.

Email, with fixed IPv6 addresses will become peer to peer again too.

html? html is not much traffic. Many people do html hehind their NAT44
boxes today.

There is still a lot to be done for zeroconf, so DNS still is ok
with a server in a rack.

Oh, I forgot. For DNS you are still dependent on IPv4.

All the enthusiasts with their linux and freebsd boxes using ISATAP
to communicate don't see a need for NAT66. It is the big guys with
big windows servers who really need NAT66 to hide their fragile
machines from the bad wild internet.

I am one of those poor guys who has never been told what good NAT66
can do for him. I am still troubled by NAT44 preventing me from
connecting with my ISATAP interface.

I am running more than one computer. That is why I am imprisoned
behind my NAT44 and I am afraid NAT66 will be yet another prison.

I have seen with tunneling (slow as molasses) I get only a single /128.
So I guess a bilingual router will sit on both his single IPv4 and
another single IPv6 and keep all the traffic for himself letting
me do the guesswork how to drill the holes I need to connect to
the internet.

I see with IPv6 I do have to compete with my fridge and the
central heating drilling holes to talk to the butcher, the baker
and the oil-tanker. None of them is living in a rack in a colocation.
They all have to drill holes into their NAT66 to talk to my home.

There is a hole industry living from selling me super excluse
and expensive drilling machinery, I would not need if there was
not a NAT66 in the first place.

I know NAT44 is like my front door and keeps the bad internet out.
But it is not NAT44, it is the firewall who keeps them out.

Only a vague feeling for symmetry keeps telling me I should have
a NAT66.

Math is telling me that need not be true. IPv4 brought us from
point to point clothes line to 2-dimensional space spanning
continents. IPv6 will bring us 3-dimensional space spanning
the globe and DNT will bring us even further. I do not know if
there is such a thing as NAT66 existing.

In  2-D space we do have trigons, squares, pentagons, hexagon...
In  3-D space live stops with things built from pentagons.

The guys with their big windows servers behind NAT44 are living
in a 2-D world, dreaming their 2-D dreams bout selling us
3-D NAT66 boxes without even knowing the math.

Kind regards
Peter

---

From: Sam Hartman <[email-masked]>
Date: Tue, 25 Nov 2008 18:11:50 -0500

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> I understand.  But in practice just knowing your external
    Keith> address is often insufficient.  You need an intermediate
    Keith> server that will forward traffic as well as maintain the
    Keith> bindings in both (nay, all) endpoints' NATs.

    Keith> If we're going to standardize NATs of any kind, they need
    Keith> to be defined in such a way that no "external" server is
    Keith> necessary - not to determine one's external IP address, nor
    Keith> to forward traffic between hosts that are all behind NATs,
    Keith> nor to maintain state in the NAT, nor to determine a host's
    Keith> 'external' IP address or port, nor to listen for traffic
    Keith> intended for a host behind a NAT.  All of this
    Keith> functionality (and more) needs to be "built in" to the NAT
    Keith> itself.

Keith, would the NAT-66 proposal plus some mechanism for a server
inside the NAT to ask the NAT for its global address be sufficient to
meet the needs described above?

How about the existing proposal plus an IPV6 anycast address for a
stun-like protocol?  If not, why not?

I'm a bit concerned about adding requirements that would involve
solving the NAT discovery problem.  We've already had a lot of bad
luck with that approach in protocols like midcom, nsis, etc.

In contrast, in environments where it works, stun has been quite successful.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Nov 2008 15:23:08 -0800

Tony,

On Nov 25, 2008, at 2:10 PM, Tony Hain wrote:
> There is no valid reason for 66nat.

Then it will die in the marketplace and any standardization efforts  
will simply fade away.

> The only justifications being given are

So, if vendors are trying to build it, it would seem to me that an  
industry group focused on standardizing its functionality would be a  
good thing, otherwise we get into the same mess we got into with IPv4.

If vendors aren't trying to build it, no significant harm is done  
(other than the waste of time for folks participating in the  
standardization).

Putting our fingers in our ears and singing "la la la" because we  
don't think a particular technology should exist is unlikely to be  
particularly beneficial.

Regards,
-drc

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Nov 2008 18:53:16 -0500

> stun-like protocol?  If not, why not?

I don't think so in either case.  The reason I don't think so is that I
suspect the NAT traversal problem is really a firewall traversal problem
in disguise.

People say they want NATs when what they mostly want is stateful
firewalls and maybe some topology hiding.  We might get them to move to
stateless NATs with bidirectional algorithmic mapping and a STUN-like
protocol, but they'll still want a statefull firewall to be bundled in
to block incoming connections.  And if there's a statefull firewall that
denies incoming connections by default, there will still be a need for
an intermediary in the network "core" that can arrange for traffic to be
forwarded between two hosts that are behind firewalls.  And there will
be little incentive for any network admin to get rid of NAT, because as
long as those firewalls are in the way, doing so won't enable many more
applications.

So if we really want to get rid of NAT, I think we have to resolve a
tussle between users and application developers on one hand, and
enterprise network operators on the other.  The tussle is over two
things: (1) how to restrict the kinds of traffic that can be sent over
the network, how to communicate those restrictions to apps, and what
kind of behavior is reasonable for apps that are presented with such
restrictions.  (2) to what extent network admins can control what
programs are used on hosts that attach to their networks.

Hey, I didn't say it was easy.  But I don't think anything less will get
rid of the need for the kinds of workarounds apps currently have to use
to deal with NATs.  Even if we got rid of NAT, we wouldn't solve the
problem (and NATs wouldn't matter too much) if apps still have to use
those workarounds.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 25 Nov 2008 16:41:53 -0800

> Then it will die in the marketplace and any standardization efforts

No it won't, because people will have deployed it in default configurations
without realizing they didn't need it. 

> don't think a particular technology should exist is unlikely to be

This is not about ignoring the technology, it is about blindly legitimizing
short-term money making for a few box vendors at the long term expense to
the entire Internet application development and end user community. If it
were simply a stand-alone technology, it would have to show value before
being deployed. It is not, because the IPv4 version of it became mandatory,
and due to marketing crap synonymous with firewall. This ensures people will
deploy it a) without awareness as a default 'security' config, or b) because
they have completely drowned in the nat==security kool-aid. Either way the
app developers will have to rely on topology awareness crutches to deal with
the resulting nonsense. 

A reasonable standards development effort would not blindly endorse
something known to be detrimental, simply because one constituency plans to
make a quick buck. We do have an Architecture Board, and a Steering Group,
so one would think we have reason to be thoughtful about the long term
impacts of what we publish. Instead all we get is complaints that anyone not
helping detail how to ship the broken architecture is ignoring reality and
off in a fantasy land, when the exact opposite is closer to the truth.
Rushing to restock the drug dealers while claiming we have no hand in the
outcome is about as far from reality as one can get.

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Nov 2008 19:47:40 -0500

james woodyatt wrote:
> On Nov 25, 2008, at 15:11, Sam Hartman wrote:
>>
> No.  RFC 3424 is the IAB Considerations document covering that problem. 
> I'm tempted to copy and paste highlights from that ancient scripture
> here, but I don't think I'd know where to stop.  As the kiddies say,
> Read The Whole Thing.
> 
> The basic problem with NAT66 is that it introduces the possibility of
> more than one global IPv6 address realm.  Where there is more than one,
> there is *any* number, not just the current realm and the single realm
> on the other side of the relevant NAT66 box.  

I'm not sure about that.  Conflicting use of address space is probably
the biggest single source of NAT-related pain that network operators
experience.  If enterprise network operators can still NAT without
reusing the same addresses in different realms, I think they'll mostly
do so.  And regardless of what else happens with NAT66, I think it's
reasonable for IETF to make it really clear that apps aren't expected to
deal with conflicting address assignment in IPv6.

> Fixing your self-address in whatever address realm any given
> communications peer happens to reside is the canonical problem that NAT
> causes for applications developers, and NAT66 is no exception to that.

No, it's only one of several canonical problems that NAT causes for
applications developers.  If we narrow the focus to that one problem,
we'll miss the boat - we won't produce a "solution" that makes life any
easier for apps developers.

> If we're going to go very far down this road toward standardizing on a
> NAT66 "solution," then I would humbly suggest that it doesn't make much
> sense for there to be a single global DNS horizon where we have multiple
> global address realms.

If we were going down that road, I'd agree with you.

But I'll make a stronger statement - any "solution" to NATxx (for any
value of xx) that requires split DNS should be considered a non-starter.
 It doesn't make much sense to improve consistency at the IP naming
layer if you're going to degrade consistency at the DNS naming layer.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Nov 2008 19:50:12 -0500

Tony Hain wrote:

> trying to build it'.

Okay, let's try to be a tad more precise.  There is a subtle but
important difference between:

A) "There is no valid reason for 66nat" and
B) "There are obvious ways to solve the problems that people want to
solve with 66nat that are both easier to understand and technically
superior"

The two statements should have equivalent truth values, but the second
one is more illuminating.

It follows that if we want people to avoid using 66nat, we need to (a)
identify or provide technically superior solutions that are easy to
understand and (b) make them obvious to people.

Keith

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Nov 2008 18:07:55 -0800

Tony,

On Nov 25, 2008, at 4:41 PM, Tony Hain wrote:
> Either way the

Stuff they presumably already have to deal with because they'd like  
their applications to be used in the real (IPv4+NAT) world...

> something known to be detrimental,

Standards development effort != endorsement.

I considered NetBIOS to be wildly offensive and actively detrimental,  
but RFC 1001 and 1002 were appropriate codifications of NetBIOS over  
TCP/UDP/IP.

> Instead all we get is complaints that anyone not

> off in a fantasy land, when the exact opposite is closer to the truth.

The architecture is _ALREADY_ broken.  66NAT is merely another symptom  
of the underlying disease.

Regards,
-drc

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Nov 2008 21:34:02 -0500

David Conrad wrote:
>> Either way the app developers will have to rely on topology
>> awareness crutches to deal with the resulting nonsense.
> 

Yeah, but we're trying to get rid of that stuff, or at least
considerably reduce the cost and complexity, because (among other
things) it presents a huge barrier to adoption of new multiparty apps.

> Standards development effort != endorsement.

According to RFC 2026, IETF standardization is a kind of an endorsement,
because it's a statement of both protocol quality and community consensus.

> of the underlying disease.

Just because a disease exists does not mean we have to encourage its spread.

The only reason for IETF to standardize some kind of 66NAT is to
significantly improve the situation over what would happen in the
absence of standardization.  There are several ways that we could
probably do that.   But one of them is NOT to standardize NATs like they
exist in IPv4.  We already know that that sucks really badly, and it
would never meet the criteria defined in RFC 2026.  Nor would it achieve
community consensus.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Nov 2008 10:10:17 +0100

> what your address will appear to be to network B is fundamentally  
> absurd.

Well, the case where my externally visible address is different  
depending on who I talk to makes it fundamentally impossible to set up  
peer to peer connections if the other end is living with the same  
limitation, so we'd have to define this such that only a single  
translation is permitted at a time.

---

From: <[email-masked]>
Date: Wed, 26 Nov 2008 09:27:00 -0000

> things) it presents a huge barrier to adoption of new multiparty apps.

Promoters of NAT, particularly vendors, seem to have a two-valued
view of the network in which inside is good and outside is evil.
But network operators, who sit on the outside of the NAT,
do not share that view. In fact, we see a future in which
cloud computing centers within the network infrastructure
will lead to a wide variety of new multiparty applications.
In many cases the network operator also takes management
responsibility for gateway devices, so the idea of evil on
the outside is even further fetched.

That said, if there is to be some form of NAT66 because there
are real requirements elsewhere, it would be preferable if
the defined default state of this NAT66 was to *NOT* translate
addresses. This is not crazy if you see it in the context
of a NAT device which includes stateful firewalling.

I suggest that if part of the problem is an excess of
pressure from vendors, then the IETF could resolve this
by actively seeking greater input from other stakeholders
such as network operators.

--Michael Dillon

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Nov 2008 16:20:48 +0100

Please,

any input into this debate shall go to the behave list. People
interested in this topic please subscribe to Behave.

Regards

Magnus

-- 

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]
----------------------------------------------------------------------
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2008 08:44:31 -0800

[Behave dropped, this is an architectural level discussion. If we don't want this on ietf we should start a different forum]
 
I don't think that this claim is right: "Promoters of NAT, particularly vendors, seem to have a two-valued
view of the network in which inside is good and outside is evil."
 
Lets go back to the original concept of an inter-network as something that is different from a network. Here I think you will find that the writings of Clark, Postel, Crocker and co. make a clear distinction. A network is under a single administrative control while an internetwork is not, there is no one party that you can rely on to synchronize major changes. That is in fact the reason that IPv4-to-6 is a really hard problem.
 
So the distinction here is not between 'good and evil', it is between that which I am responsible for and that which someone else is responsible for. And that is why I expect that there will always have to be some form of perimeter control device in future network architectures.
 
Now lets turn to the issue that I raised in the plenary: encapsulation.
 
Encapsulation is an important principle in object oriented programming precisely because having rules about what is allowed to depend on what makes it much easier to innovate in useful ways in the future. Discipline is not incompatible with creativity.
 
Today the Internet architecture looks a bit like a program written in Cobol. The program works, it performs an important function but it is not written in the way that we would write it today knowing what we know today. And the reason is much the same: Cobol was research, the Internet was research. The objective of research is to know more at the end than you did at the beginning.
 
In particular the biggest problem we fact in the Internet is precisely the fact that it is very hard to change and to innovate. The reason people turned to object oriented programming was that encapsulation led to programs that were easier for others to maintain. This is also the reason that we use the single inheritance model of Java and C# rather than the multiple inheritance model of C++ or LISP.
 
What I am looking for here is an encapsulation that allows the application programmer to rely on a small set of simple assumptions and be able to be maximally confident that the result will be compatible with the network of the future.
 
That is not stiffling creativity or the 'generative' power of the Internet. On the contrary, every standards process involves removing choices from the programmer. We decide on particular RFC822 headers to use, we decide on particular semantics, above all we decide on one way to do something not five.
 
The question here then, is not whether an assumption is likely to be true or not, it is whether it is necessary.
 
Over the next few years application programs are going to have to cope with a minimum of four separate transport protocols even if there is no NAT whatsoever: IPv4, IPv6, IPv46, IPv64. Add NAT in and we have four different variations of IPv4 alone: IPv4, IPv44-4, IPv44-4-44, IPv4-44. And that is before we start thinking about multiple layers of NAT.
 
To me this argues that the only possible credible position has to be that the application protocol makes absolutely no assumptions whatsoever on the basis of the IP layer address. In fact it would be best for the O/S to provide an API which hides the details of the IP address from the application entirely in the same way that the ethernet MAC address is hidden.
 
What we absolutely cannot afford is allowing people to insert 'assumptions' into the application layer design that simply are not true for the purpose of mandating support for some particular network architecture. This is tinkerbell logic: if we wish hard enough it will make true something that is not.
 
In the original Inter-network design the role of Internet Protocol was only mandated as the protocol for use between networks. The idea that IP has to be end to end is a subsequent assumption that has no grounding in the actual history. 

What I want to see in an Internet Architecture is a set of assumptions that can be reified as an API that can then remain stable for a century or so. For example:
 
A well formed Internet application MUST:
 
* Identify a service endpoint by means of a URI
* Resolves a service endpoint to a server and port address through the Domain Name System [1]
 
A well formed Internet application MUST NOT:
 
* Employ IP addresses and/or port numbers as inbound signalling
 
The contract here is that we write down the shortest possible list and then we try to keep those promises true for the longest possible time, like a century.

[1] Note that the Domain Name System need not necessarily entail the DNS protocol.as described in RFC 2181, it is the consistency of the mapping, not the protocol instantiation that is essential. Not that I consider it likely that there would be a change, it is not necessary to assume that there will never be a change.

Not only is this proposal more robust, it allows almost infinitely greater generative power. In fact I can quantify it. With the port numbering scheme we are limited to 2^16=65536 different protocols. That is not very many in a world with a billion Internet users. Using DNS/SRV for service endpoint discovery on the other hand allows for 36^12 = 4.7E18 different combinations, 72 trillion times more than there are port numbers. And if we ever run out we can work on a new scheme and burn another DNS RR.
 
It is also, I would suggest, supported by a considerably greater consensus in the application area than the arguments being made that NAT is evil. From the apps area point of view we would like programs to work using the networks we have and we really do not believe that IPv6 is going to save us.
 
Going NAT free is not going to be an incentive to move to IPv6 because there is no possible transition plan that is not going to involve IPv4-6 translation and thus the problem is going to get worse for the next ten years if we are foolish enough to write any more application protocols that rely on the IP address being constant along the network path. 

Publishing a simple architectural contract of this form would greatly ease the IPv4-6 transition and help clarify questions such as when/where we should employ UDP, TCP and Multicast. 
 
My view is that UDP should only be used for the lowest level facilities, we need it for DNS and we appear to need it for time. After that I think that any other use looks more like a different protocol 'lossy TCP'. 
 
The principal problem with using a streaming layer other than TCP or using multicast is the lack of support which in turn is a defect of our service endpoint discovery strategy. If we could use an extended version of SRV which gave us information about the range of transport protocols on offer it would be possible for endpoints to negotiate better choices. So the consumer whose local ISP supports 'lossy TCP' can use a videophone client application that makes an intelligent choice of transport protocol. 
 
The same is true of several other features that were discussed in the IAB presentation. So applications are using faulty heuristics to make guesses as to what the network state is? Well provide them with a principled means of publishing and obtaining the same information. For example, ISPs could publish network performance stats in the reverse DNS.

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Wed 11/26/2008 4:27 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [BEHAVE] Lack of need for 66nat : Long termimpact to applicationdevelopers

--Michael Dillon

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Nov 2008 16:34:40 -0800

> meet the needs described above?

No.  RFC 3424 is the IAB Considerations document covering that  
problem.  I'm tempted to copy and paste highlights from that ancient  
scripture here, but I don't think I'd know where to stop.  As the  
kiddies say, Read The Whole Thing.

The basic problem with NAT66 is that it introduces the possibility of  
more than one global IPv6 address realm.  Where there is more than  
one, there is *any* number, not just the current realm and the single  
realm on the other side of the relevant NAT66 box.  Fixing your self- 
address in whatever address realm any given communications peer  
happens to reside is the canonical problem that NAT causes for  
applications developers, and NAT66 is no exception to that.

If we're going to go very far down this road toward standardizing on a  
NAT66 "solution," then I would humbly suggest that it doesn't make  
much sense for there to be a single global DNS horizon where we have  
multiple global address realms.  Do the proponents of NAT66 have any  
proposals for extending DNS appropriately to support the architecture  
that NAT66 implies?

Do we really want to open the can of worms that multiple global DNS  
horizons represents?  I should hope not.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2008 08:58:52 -0800

Could we agree on a consensus point that:
 
'Any application developer who designs a protocol on the assumption it will not be subject to NAT66 may be disappointed'
 
I think that it is beyond rational argument to claim otherwise. Furthermore, if it is really the interests of application layer protocol designers that are being considered here, then why am I reading so many posts from network layer folk telling me what my problems are?
 
HTTP was originally designed to run just fine over OSI and DECNET. In fact I have deployed HTTP over DECNETv4. The fact that it runs just fine over past protocols is one of the reasons that NAT works and why HTTP works just fine over IPv6.

From: [email-masked] on behalf of Fred Baker
Sent: Sat 11/22/2008 12:07 AM
To: [email-masked]
Cc: [email-masked] WG; IAB; IETF Discussion; IESG IESG
Subject: Re: Lack of need for 66nat : Long term impact to applicationdevelopers

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2008 08:45:09 -0800

The problem here is that the Behave group seems to have people who are making IETF wide policy. So that is why opponents of the behave position think that the appropriate forum is the IETF list.
 
Behave can decide not to do a NAT66.
 
But what they cannot do is to decide that NAT66 should be prohibited. 
 
The lack of a consensus that NAT66 is needed does not automatically mean that it does not happen. On the contrary, behave was founded after years of ideological opposition to NAT led to botched implementations. Then we had a small clique decide that they were going to unilaterally pohibit NAT46 because they could
 
And then a lot of folk got rather angry and do not want the issue swept under the carpet again just because some folk are tired of the discussion.

From: [email-masked] on behalf of Magnus Westerlund
Sent: Wed 11/26/2008 10:20 AM
To: [email-masked]
Cc: 'IETF Discussion'
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers

Please,

Regards

Magnus

--

Magnus Westerlund

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2008 09:14:40 -0800

Eric, 
 
The problem here is that you assume that the IETF has decision power that can magic away NAT66. Clearly it did not for NAT44 and will not for NAT66.
 
So the real question for App designers is:
 
1) Should they design protocols that assume no NAT66
2) Should they regard the assumption that there is no NAT6 as a design fault that may lead to lack of interoperability.
 
The only way that the effort being expended to kill NAT66 makes any sense is if the idea is to allow this type of argument to be rulled out of scope as similar arguments were ruled out of scope when they were brought up in existing protocols that simply do not work properly because the design was intentionally made to be unfriendly to NAT.
 
If we recognize that there is no consensus that applications that are not NAT66-agile will work in future then we should agree that the reasonable default requirement for an apps WG should be that it should build a protocol that is NAT66 tolerant. But I suspect that there will be severe pushback against that.

Peter Dambier is right in this case,
 
I would NAT66 my network for the simple reason that very few endpoint devices actually tollerate a change in the IP address without at a minimum a service interruption. Since I cannot guarantee that my IPv6 address from my ISP will never change I am going to NAT66 my internal network for the sake of having static numbering inside the network.
 
The more infrequent you posit the need for renumbering is, the greater my reluctance to allowing it will become. If you have a network event that happens only once a year it is going to mean a very serious disruption when it happens. DHCP only solves some of the problems, I am still effectively forced to perform a reboot, I will lose connections and this will cost me real time and money to fix.

From: [email-masked] on behalf of Eric Klein
Sent: Mon 11/24/2008 5:56 AM
To: Fred Baker
Cc: IAB; [email-masked] WG; IETF Discussion; [email-masked]; IESG IESG
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers

		The discussion today in Behave shows there is very strong peer-pressure group-think with no serious analysis of the long term implications about what is being discussed.

	Yes, there is a very clear anti-NAT religion that drives a lot of thought. It's not clear that any other opinion is tolerated. 

Fred,
 
I pesonally would be open to a real discussion about the needs and then about the solution. But for now NAT has taken on religious connotations with those who are for it being as single minded as those who are against it.
 
We need a team made up of both sides to sit down, spell out what are the functions of NAT (using v4 as a basis) and then to see if:
1. If they are still relevant (like number shortage from v4 is not the same issue under v6 for example)
2. Do they already exist in v6 without adding NAT
 
Then we need to check:
 
Only then can we make a proper and informed decission on what is needed and what is unneeded legacy.
Eric
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2008 09:27:14 -0800

>suspect the NAT traversal problem is really a firewall traversal problem

Absolutely, and that is why there needs to be a permissions system that allows effective decisions to be made without the need for human administrative decisions on a case by case basis.
 
I described one way of doing this in my book. Devices need to authenticate themselves to the network and they need to be able to specify the precise range of services they offer and require.

If you plug a Playstation into the home network, the network security policy should be something like:

* The Playstation has unrestricted access to the Internet, including the ability to open inbound ports in the range xxx-yyy and make outbound connections to such

* The Playstation can report status via SNMP and hook into the backup sub-system

* The Playstation cannot route packets to any other device on the network under any circumstances.

I do not want to run the playstation with unrestricted network access. I certainly do not want it sending or receiving SMTP mail. 
 
This is not just a protocol design issue, it is a platform architecture issue. I see the future as being a mixture of single purpose devices that have a specific function and can be safely granted highly restricted access with few worries and more complex multi-function platforms (computers, mobiles) that serve multiple functions are require partitioning enforced at the kernel level.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Nov 2008 12:27:11 -0500

While most of the discussion about killing NAT66 is happening on the  
IETF list, we have a much more constructive discussion going on in  
behave regarding how to define an IPv6 NAT that will meet the needs of  
network administrators and end-users, while being less destructive to  
the Internet architecture, local network connectivity, transport layer  
protocols and applications than current IPv4 NA(P)Ts.  It is not clear  
that we can achieve everything that we want to achieve yet, but  
wouldn't it be cool if we did?

If folks would like to join that discussion, please read the following:

NAT66 Internet-Draft:  http://tools.ietf.org/html/draft-mrw-behave-nat66-01
NAT66 Presentation (updates the draft):  http://www.ietf.org/proceedings/08nov/slides/behave-14.pdf

Then, come talk to us on the behave WG mailing list:  [email-masked],  
To Subscribe: [email-masked], In Body: subscribe.

All feedback and opinions are welcome!

Margaret

On Nov 26, 2008, at 12:14 PM, Hallam-Baker, Phillip wrote:

> Eric,
>
> The problem here is that you assume that the IETF has decision power  
> that can magic away NAT66. Clearly it did not for NAT44 and will not  
> for NAT66.
>
> 2) Should they regard the assumption that there is no NAT6 as a  
> design fault that may lead to lack of interoperability.
>
> The only way that the effort being expended to kill NAT66 makes any  
> sense is if the idea is to allow this type of argument to be rulled  
> out of scope as similar arguments were ruled out of scope when they  
> were brought up in existing protocols that simply do not work  
> properly because the design was intentionally made to be unfriendly  
> to NAT.
>
> If we recognize that there is no consensus that applications that  
> are not NAT66-agile will work in future then we should agree that  
> the reasonable default requirement for an apps WG should be that it  
> should build a protocol that is NAT66 tolerant. But I suspect that  
> there will be severe pushback against that.
>
>
> I would NAT66 my network for the simple reason that very few  
> endpoint devices actually tollerate a change in the IP address  
> without at a minimum a service interruption. Since I cannot  
> guarantee that my IPv6 address from my ISP will never change I am  
> going to NAT66 my internal network for the sake of having static  
> numbering inside the network.
>
> The more infrequent you posit the need for renumbering is, the  
> greater my reluctance to allowing it will become. If you have a  
> network event that happens only once a year it is going to mean a  
> very serious disruption when it happens. DHCP only solves some of  
> the problems, I am still effectively forced to perform a reboot, I  
> will lose connections and this will cost me real time and money to  
> fix.
>
>
>
> applicationdevelopers
> I pesonally would be open to a real discussion about the needs and  
> then about the solution. But for now NAT has taken on religious  
> connotations with those who are for it being as single minded as  
> those who are against it.
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2008 09:38:38 -0800

I don't quite understand what you men by this.
 
My internal DNS for the house does not reveal the existence of any of the machines to the outside world. Multiple horizons have been a feature of DNS for decades now.
 
The only thing global about DNS is that there is only one consensus holder of a particular name. You can override ietf.org in your local DNS server but you cannot persuade a large number of folk to do that at a global level.
 
Seems to me that it would be a good thing for the IAB to look into this area of assumptions as well.

In particular the original conception of DNS was to locate a HOST. Since then we have increasingly used DNS to locate a SERVICE, starting with MX but continuing since.
 
But more generally, I don't think that there is a proposal for multiple global domains. The assumption seems to be that we have networks that connect together through the Internet. A network may use a different address and DNS resolution internally and a network may in turn be comprised of sub-networks with different address and DNs resolutions. But there is only one Internet and one set of name holders and one set of universally agreed addresses.
 
Can is opened, Do you want to borrow a soldering iron and a spoon to try and push 'em back in?

From: [email-masked] on behalf of james woodyatt
Sent: Tue 11/25/2008 7:34 PM
To: Behave WG
Cc: [email-masked]
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers

---

From: [email-masked]
Date: Wed, 26 Nov 2008 09:17:14 -0800 (PST)

> The problem here is that you assume that the IETF has decision power that can
> magic away NAT66. Clearly it did not for NAT44 and will not for NAT66.
 
I really hope you aren't correct about this, but I fear you are.

> 2) Should they regard the assumption that there is no NAT6 as a design
>    fault that may lead to lack of interoperability.
 
> The only way that the effort being expended to kill NAT66 makes any sense is
> if the idea is to allow this type of argument to be rulled out of scope as
> similar arguments were ruled out of scope when they were brought up in existing
> protocols that simply do not work properly because the design was intentionally
> made to be unfriendly to NAT.
 
Unfortunately, protocol-unfriendly middleboxes are a fact of life even for
protocols that have no specific issues with NAT. In the case of email,
for example, NAT rarely presents problems even though a significant fraction
of message submission occurs from NATted systems.

Firewalls are another matter. They cause all sorts of operational problems - so
much so that malfunctioning and misconfigured firewalls create a noticeable
fraction of our support calls.

Frankly, I think it would be good if some of this anti-NAT fervor were to be
generalized to other sorts of application-hostile midldeboxes. BUt I've been
able to get essentially zero traction on that over the years in the IETF.

> If we recognize that there is no consensus that applications that are not
> NAT66-agile will work in future then we should agree that the reasonable
> default requirement for an apps WG should be that it should build a protocol
> that is NAT66 tolerant. But I suspect that there will be severe pushback
> against that.
 
I'm sure there will. That said, perhaps one alternative is to attempt to reduce
the extent to which NAT66 will be needed by doing what Fred Baker suggests and
looking clearly and carefully at the reasons for NAT use. But it is very hard
to do this in the present climte of what amounts to religious hysteria on both
sides.

> I would NAT66 my network for the simple reason that very few endpoint devices
> actually tollerate a change in the IP address without at a minimum a service
> interruption. Since I cannot guarantee that my IPv6 address from my ISP will
> never change I am going to NAT66 my internal network for the sake of having
> static numbering inside the network.
 
Bingo. That's exactly the reason long-term I'll probably do it too.

And even this assumes that renumbering support of any kind manifests in a
useful way. The absolutely dismal state of support for IPv6 in SOHO-grade
routers is IMO one of the orimary current impediments for IPv6 deployment. And
when IPv6 support does start to show up in these boxes, I really have to wonder
if they'll get automatic renumbering right, assuming it's supported at all.

> The more infrequent you posit the need for renumbering is, the greater my
> reluctance to allowing it will become. If you have a network event that happens
> only once a year it is going to mean a very serious disruption when it happens.
> DHCP only solves some of the problems, I am still effectively forced to perform
> a reboot, I will lose connections and this will cost me real time and money to
> fix.
 
I went for something like 10 years without having to renumber, and as a result
IP addresses got put in all sorts of nooks and crannies on my network. Then
suddenly and without warning my ISP announced an emeergency numbering change
due to an upstream provider switch. The announcement went out at 11:00PM Sunday
night; the renumbering occurred the next morning.

It is a bit of an understatement to say I was not a happy camper. And then it
happened again a week or so later - easier because I had notes on all the stuff
that needed changing plus I'd switched to DHCP as much as possible, but still
no picnic. And then I had to renumber again when I switched ISPs ;-) But that
should be the last time because I took the opportunity to switch to 1:1 NAT and
private address space.

In any case, I think getting renumbering right and getting it deployed is an
essential step in minimizing the use of NAT66.

				Ned

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2008 10:00:24 -0800

Ned raises one firewall concern: they block applications that should work.
 
I have another concern: many are completely insecure as configured. It is not completely unusual to find a $200,000 firewall configuration that could be replaced with an ethernet patch cable. I have seen it: some consultant was working on an installation at the customer site, the deployment didn't work, they shut off the firewall rules, it worked and he got paid. Nobody checked the firewall until we came in to take it under outsourced management.
 
One of the key problems is that we have no facilities for network administration. The modus today is that we administer the hosts on the network, not the network as a whole. We have network monitoring, but not really administration. 
 
It should be possible to have a supplier drop ship equipment to the other side of the world, have them plug it into the local network and have all the configuration be pushed out securely from the administration control center in machinereadable form. Lets get rid of the need for SSH tweakage as well. 
 
I want to rack dumb hardware and then have the control system decide 'hey, I need more email server, box 42 is now an email server, here are your marching orders'. 
 
People should not talk to machines when machines can talk to machines. The machines can automatically configure, they can optimize, they can load balance.

And we can save a lot of electricity this way as well. When a machine is no longer needed shut it down, or collapse its function with another under-utilized machine. In the near future we are going to be using a lot more renewables and that will mean that the spot price for energy may change pretty quickly. If the wind is blowing in Texas the price there will be cheaper than when it is not. Making use of that cheap energy is going to mean moving the computing effort to where the power is. 

From: Ned Freed [mailto:[email-masked]]
Sent: Wed 11/26/2008 12:17 PM
To: Hallam-Baker, Phillip
Cc: Eric Klein; Fred Baker; behaveietforg WG; IAB; IETF Discussion; [email-masked]; IESG IESG
Subject: RE: [BEHAVE] Lack of need for 66nat : Long term impact toapplicationdevelopers

                                Ned

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 26 Nov 2008 11:06:54 -0800

Hi -

> From: "james woodyatt" <[email-masked]>
> To: "Behave WG" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, November 25, 2008 4:34 PM
...
...

>From the peanut gallery...

The potential disconnect between an application's notion of "self"
and how it's identified in the local and big internets is a difficulty
with any kind of NAT and cute DNS tricks.  But weren't these the
kinds of problem HIP was intended to address?

Randy

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Nov 2008 14:13:29 -0500

> essential step in minimizing the use of NAT66.

This seems to ignore the fact that we already have a widely deployed  
solution to site renumbering:  NAT.

IPv4 NA(P)T (of the stateful, n:1, portmapping variety, anyway)  
includes a lot of stuff that isn't strictly required to solve the  
renumbering problem, though.  The renumbering problem can be solved  
with a stateless, 1:1 NAT that doesn't change the transport ports.  In  
that case, do you really think that NAT is an unacceptable solution,  
and that we need to develop another renumbering solution in order to  
minimize use of the one that we already have?

Margaret

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Nov 2008 15:18:01 -0500

Hallam-Baker, Phillip wrote:
> 'Any application developer who designs a protocol on the assumption it
> will not be subject to NAT66 may be disappointed'

I think it would be far more constructive to tell application developers
what they _can_ assume... and to make sure that they have enough "safe"
assumptions to implement not only client-server apps but also multiparty
protocols with referrals.

(And trying to make it all hinge on DNS names is a non-starter)

Keith

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Nov 2008 09:40:12 +1100

In message <[email-masked]
om>, "Hallam-Baker, Phillip" writes:
> This is a multi-part message in MIME format.
> 
> Eric,
> 
> that can magic away NAT66. Clearly it did not for NAT44 and will not for
> NAT66.
>
> sense is if the idea is to allow this type of argument to be rulled out
> of scope as similar arguments were ruled out of scope when they were
> brought up in existing protocols that simply do not work properly
> because the design was intentionally made to be unfriendly to NAT.
>
> If we recognize that there is no consensus that applications that are
> not NAT66-agile will work in future then we should agree that the
> reasonable default requirement for an apps WG should be that it should
> build a protocol that is NAT66 tolerant. But I suspect that there will
> be severe pushback against that.
>
>
> I would NAT66 my network for the simple reason that very few endpoint
> devices actually tollerate a change in the IP address without at a
> minimum a service interruption. Since I cannot guarantee that my IPv6
> address from my ISP will never change I am going to NAT66 my internal
> network for the sake of having static numbering inside the network.

	And if you stop thinking IPv6 == IPv4 + big addresses and
	start thinking multiple IPv6 addresses including a ULA IPv6
	address + RFC 3484 you get local address stability without
	needing a NAT.  You use ULAs for internal communication and
	global addresses for external communication.

	This isn't future stuff, you can do this today.  You can
	renumber your external addresses daily and keep internal
	sessions up for weeks.

> The more infrequent you posit the need for renumbering is, the greater
> my reluctance to allowing it will become. If you have a network event
> that happens only once a year it is going to mean a very serious
> disruption when it happens. DHCP only solves some of the problems, I am
> still effectively forced to perform a reboot, I will lose connections
> and this will cost me real time and money to fix.

	If your OS requires a reboot when you renumber get a real OS.
	If your apps require that they restart when you renumber get
	your apps fixed.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: David Morris <[email-masked]>
Date: Wed, 26 Nov 2008 14:59:33 -0800 (PST)

> 	If your apps require that they restart when you renumber get

I fail to understand how an app such as ssh can maintain a secure
connection in the face of renumbering. Yet many of my ssh sessions are
active for days or weeks quite happily and their existance represents my
mid term memory about what I'm working on.

Creating a new connection represents a restart from my perspective. Some
amount of my activity is lost and if I don't directly control when the
renumbering happens, it can be at a very in-opportune time in terms of my
productivity.

Dave Morris

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Nov 2008 15:16:55 -0800

David Morris wrote:
> connection in the face of renumbering. 

That is probably because you appear to have failed to read the top half of
that post. An external ssh session will break during renumbering, no matter
what nat capability might exist, so the only thing worth discussing is an
internal one. Deploying a ULA prefix alongside whatever external one might
exist will allow the internal ssh to persist forever while the external
prefix is changed on a minute by minute basis. 

> Yet many of my ssh sessions are

Clearly none of those are external, or there is no actual renumbering going
on.

> renumbering happens, it can be at a very in-opportune time in terms of

No argument about the impact, but you have not demonstrated a need for 66nat
beyond wanting it so that nothing changes except the size of the address.
This will not be true on a number of fronts, so perpetuating an
architectural impediment in a futile attempt to avoid reality is not a
reasonable argument. 

Vendors will build what you say you want to buy, so don't box yourself in by
insisting on perpetuating the past without trying to move beyond it first...

Tony

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Nov 2008 10:21:47 +1100

In message <[email-masked]>, David Mo
> mid term memory about what I'm working on.

	Internally ssh picks a ULA address and you don't notice the
	renumbering event.

	For external renumbers events extend SSH to support reconnects.
	You need that anyway for network outages other than renumbering.

	There are apps today that support reconnect.

	NAT won't save you from external renumber events.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 Nov 2008 16:35:47 -0800

>their applications to be used in the real (IPv4+NAT) world...

Have to deal with does not mean that the current solutions actually work.
As I said in my first message in my thread, the estimates we have for
ICE-TCP working in the real world are 40% or so, and it is the best thing
that we have.  That means real applications that already benefit from
1) having a known rendezvous/signalling path and 2) have defined
methods for using relays *still fail the majority of the time they use
TCP*.

We deal with that by not having the apps deploy.  One of the few
ways to actual get a pull for v6, rather than than exhaustion-based push,
is to have the topology sufficiently simpler that some things work there
better than they work in v4.  Introduce NAT, and you have shot that
possibility in the head, not the foot.

There is a reason we see so many systems deploying in overlay networks
at this point--the IP topology is so broken for v4 that it is better to use
a key-based routing system on top of it than to use the topology itself.
If we are giving up on this for v6 at this point, we need much more
work on dealing with overlays, because our ability to have non
client-server systems will depend largely on them.

>Standards development effort != endorsement.

But the IETF sells itself as something that gets cross-area review and gives
a benefit in understanding how a technology fits in the ecosystem.  If we
aren't going to pay attention to it when it comes, we have relatively
little value beyond a cheaper industry consortium.  The review on
this is trying to express real concerns.    You have people offering to
do real work to come up with solutions that meet the need without
this breakage.  That's not possible, obviously, if the need is "introduce
NAT", but if the need is expressible in security properties or a threat
model, I personally believe we can do much, much better.

Happy Thanksgiving,
				Ted

---

From: "TJ" <[email-masked]>
Date: Wed, 26 Nov 2008 23:51:04 -0500

FWIW - I wholeheartedly agree with
"If we're going to standardize NATs of any kind, they need to be defined in
such a way that no "external" server is necessary - not to determine one's
external IP address, nor to forward traffic between hosts that are all
behind NATs, nor to maintain state in the NAT, nor to determine a host's
'external' IP address or port, nor to listen for traffic intended for a host
behind a NAT.  All of this functionality (and more) needs to be "built in"
to the NAT itself."

In fact, I think this (end nodes awareness of their "real" external address
and port) should be one of the, if not the, biggest design goals for NAT66
... assuming we do "define" it.  This enables the NAT to still "do its
thing", while still retaining the ability for apparent end to end
communications.  

Additionally, something like [ ~UPnP | NAT-PMP | NAT-XC | ALD ] to allow
firewall pinhole creation might just be useful, with a note of concern
around security of course ... 

/TJ

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Keith Moore
>Sent: Tuesday, November 25, 2008 5:43 PM
>To: David Morris
>Cc: 'IAB'; [email-masked] WG'; 'IETF Discussion'; 'IESG IESG'
>I understand.  But in practice just knowing your external address is often
>insufficient.  You need an intermediate server that will forward traffic as
>well as maintain the bindings in both (nay, all) endpoints' NATs.
>
>If we're going to standardize NATs of any kind, they need to be defined in
>such a way that no "external" server is necessary - not to determine one's
>external IP address, nor to forward traffic between hosts that are all
>behind NATs, nor to maintain state in the NAT, nor to determine a host's
>'external' IP address or port, nor to listen for traffic intended for a
host
>behind a NAT.  All of this functionality (and more) needs to be "built in"
>to the NAT itself.
>
>Furthermore it's not sufficient to just define a NAT with a bidirectional,
>algorithmic mapping (in order to avoid some of these
>So really, to be viable, any NAT standard needs to include some amount of
>firewall functionality.  And the firewall needs to be able to keep working
>even if the NAT function is turned off.
>
>Keith

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Nov 2008 00:28:05 -0500

As far as I can tell, most of what is being asked for here has little, 
if anything, to do with NAT.  To paraphrase:

If we are going to have firewalls which block incoming connections, 
communication between entities behind such firewalls should still be 
possible without any "external" servers.

That is a tall (not impossible, but quite tall) order, which we have 
attempted to address several times with little effect.

And let us be very clear.  Network admins have been asking for and using 
such features for at least 18 years, well before NAT.

I would recommend separating the problems.  The NAT solution, as I 
understand it, does not make this problem worses.  That is about all one 
can ask of the NAT side of the equation.

Yours,
Joel M. Halpern

---

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

> can ask of the NAT side of the equation.

the problem with separating the problem is that we'll solve the "easy"
part first (the NAT part) and put off trying to solve the biggest part
of the problem that is really keeping applications from working
efficiently or reliably ... and meanwhile we'll have done nothing to
improve security either.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Nov 2008 02:18:30 -0500

> 	renumber your external addresses daily and keep internal

it might work for two party applications on hosts that are configured to
prefer ULAs to global addresses when the destination address is also a
ULA.   problem is, sometimes that's exactly the wrong choice.  the API
and stack don't know whether the application has a greater need for a
global address (e.g. for referrals) or a local address (for stability).

and just because a ULA exists for both source and destination does not
inherently mean those addresses are more stable than other addresses
that are available, nor does it mean that traffic is routed between
source ULA and destination ULA.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Nov 2008 17:39:45 +0100

On 27 nov 2008, at 16:39, Eric Klein wrote:

> There is a diffrence between doing aways with NAT, allowing natural  
> growth of NAT, and endorsing NAT.  Of the 3 I only object to the 2nd  
> one.  So we either kill NAT so dead that it can not be brough back  
> in any form or we find a way to meet the needs in a way that will  
> not "break the internet" nor prevent new p2p applications.

I agree with this. I'd prefer no NAT, but I'll take a predictable,  
contained NAT over NAT anarchy.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Wed, 26 Nov 2008 11:47:12 -0800 (PST)

> solution to site renumbering:  NAT.

Well, given that I said I'm using it for V4 and will probably use it for V6,
I'm not sure "ignoring" is quite the right term.

> minimize use of the one that we already have?

Again, it seems clear that since I'm using it I don't regard it as
unacceptable... The real question is how it will compare to whatever IPv6
automatic renumbering support ends up in SOHO routers. (Please note that I am
entirely indifferent to the potential capabilities of IPv6 - what matters is
what I can buy, not what the specifications say is possible.) At this point in
time I an quite skeptical it will ever work as well as 1:1 NAT does.

				Ned

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Nov 2008 15:01:30 -0500

Hi Ned,

> time I an quite skeptical it will ever work as well as 1:1 NAT does.

Sorry for misunderstanding your earlier post, as it seems like we are  
in agreement about this.

Margaret

---

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

> This was already done, and the results are in RFC 4864.

I know, I was one of the co-authors of that RFC. But there seems to be a
differnce of opnion as to how well we covered all pervieved needs -
otherwise this discussion would not be happening and everyone would say "oh
yeah we don't need on NAT"

But as there are people that have a percieced need for topology hiding and
port translation lets look at this compleatly and build what is needed the
first time (and prevent the need for BEHAVE to rebuild it later)

> I'm not sure what you mean by #1, because if you start with a list of the
> functions of NAT, the fact that NAT can be used for those functions just
> follows, doesn't it?

#1 asks that if NAT will not fit the real need, why use it to fit the
percieve need.

> I think we are ready to do this, based on the information in RFC 4864.  Do
> you see anything missing from 4864 that needs to be analyzed further? If so,
> could you send specific points, and perhaps we can consider an update?
>
All of the points that have been made in this chain point to diffrent
percieved requreiments, and there are multiple proposed solutions being
tossed around.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

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

On Wed, Nov 26, 2008 at 19:14, Hallam-Baker, Phillip <[email-masked]>wrote:

>  Eric,
>
> The problem here is that you assume that the IETF has decision power that
> can magic away NAT66. Clearly it did not for NAT44 and will not for NAT66.
>

There is a diffrence between doing aways with NAT, allowing natural growth
of NAT, and endorsing NAT.  Of the 3 I only object to the 2nd one.  So we
either kill NAT so dead that it can not be brough back in any form or we
find a way to meet the needs in a way that will not "break the internet" nor
prevent new p2p applications.

>  The only way that the effort being expended to kill NAT66 makes any sense
> is if the idea is to allow this type of argument to be rulled out of scope
> as similar arguments were ruled out of scope when they were brought up in
> existing protocols that simply do not work properly because the design was
> intentionally made to be unfriendly to NAT.
>
>
Agreed, but to do that we need a consensus - and that seems very hard to
reach on this topic

> not NAT66-agile will work in future then we should agree that the reasonable
> devices actually tollerate a change in the IP address without at a minimum a
> service interruption. Since I cannot guarantee that my IPv6 address from my
> ISP will never change I am going to NAT66 my internal network for the sake
> of having static numbering inside the network.
>
> reluctance to allowing it will become. If you have a network event that
> happens only once a year it is going to mean a very serious disruption when
> it happens. DHCP only solves some of the problems, I am still effectively
> forced to perform a reboot, I will lose connections and this will cost me
> real time and money to fix.
>
>
This goes back to the renumbering issue, and I agree it is a real and
signifigant issue. But I am still not convienced that NAT is the only
solution.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

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

On Wed, Nov 26, 2008 at 19:17, Ned Freed <[email-masked]> wrote:

> devices
> happens
There are many drafts out there on renumbering, maybe we need to review them
to see how they fit in this issue or if NAT would do away with the need for
them. This is the analysis I am asking for.

Eric

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 27 Nov 2008 11:50:02 -0700

I'm sure that the IAB and IESG is keenly interested in this topic but  
everyone that cares is subscribed to behave. Getting several copies of  
every message does not make the thread any easier to follow. It's no  
big deal one way or the other, I am good at hitting the delete key,  
but if it was all the same to everyone, I would appreciate it if the  
topic could be discussed on the one email which, AFAIC, should be [email-masked] 
.

Respectfully, Cullen

On Nov 27, 2008, at 8:44 AM, Eric Klein wrote:

> endpoint devices
> greater my
> There are many drafts out there on renumbering, maybe we need to  
> review them to see how they fit in this issue or if NAT would do  
> away with the need for them. This is the analysis I am asking for.
>
> Eric

---

From: Stig Venaas <[email-masked]>
Date: Fri, 28 Nov 2008 11:47:41 +0100

Mark Andrews wrote:
[...]
> 	renumber your external addresses daily and keep internal

Yes, I think using ULAs is a much better approach. Using ULAs also
has some drawbacks though. Attached is some text I wrote a long time
ago on using ULAs for intra-site stability when changing providers.
You may want to jump directly to section 3 rather than reading it all.

There are issues like split DNS and address selection.

Stig
Using ULAs for intra-site stability

1. Introduction

When deploying IPv6 most organisations/sites have to use
provider assigned (PA) addresses. This allows for good
aggregation in the global routing tables since the number
of routes in the global routing table can be on the order
of the number of providers rather than the number of
organisations or sites. The downside of this, is that
an organisations/site need to renumber (change the IPv6
addresses of their hosts) when changing providers. Renumbering
has a significant cost, which again means that buying
connectivity from a provider is a long term investment, and
that changing to a slightly cheaper provider may indeed cost
more than staying.

>From an end-user perspective the optimal solution would be
to own a set of addresses that are provider independent (PI),
where one could keep using the same addresses independent of
the provider. However, due to the impact this would have on
routing, there are limitations on who can get such addresses.

For IPv4 it is pretty common to make use of NAT. While NAT
has several problems, one major benefit is that one can change
providers (and possibly be multi-homed) and only alter the
external addressing. The internal addressing can be completely
independent of the external and need not be altered.

For IPv6 there are enough addresses for all hosts to get
globally unique routable addresses, which means that no NAT
is required and one can get full end-to-end connectivity.
We will here look at how one can without the use of NAT,
have relatively stable addressing for internal communications,
and how that reduces the cost of changing providers.

One obvious way to try to solve this problem, is the use of
Unique Local Addresses (ULA) for internal communications,
and that is the focus of this document. There is some
on-going work, in e.g. the IRTF, on new routing and
addressing solutions, including various so-called locator
identifier split solutions. These solutions may allow hosts and
sites to have stable addresses that are used as identifiers.
It remains to be seen whether such solutions eventually get
deployed. It is clear that such solutions are many years
ahead.

2. Unique Local Addresses (ULA)

Unique Local IPv6 Unicast Addresses are specified in RFC
4193 from 2005. These are intended to be globally unique,
used for local communications, and not to be routable on
the global Internet.

2.1. ULA Format
The format of the ULA addresses is defined as follows:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+

where the prefix is FC00::/7, Global ID is a more or less
globally unique identifier, and L is set to 1 meaning the
identifier is locally assigned. We will discuss that below. The
Subnet ID is used for addressing subnets. This ID is 16 bits, so
a site may use a some Global ID, and for that value, have up to
65536 subnets.

2.2 ULA Global ID

RFC 4193 specifies how Global ID can be locally assigned. In this
case the L-bit is set to 1. For local assignment one must use a
pseudo-random algorithm, one is suggested in the RFC. They key is
that by using such an algorithm, one is unlikely to have the ID
clash with another network with the same ID. There may be two sites
in the world with the same Global ID, but given that they should be
for local used and not on the global Internet, it is unlikely that
two sites with the same ID come in conflict with eachother. The
use of this pseudo-random ID means that if networks using these
addresses merge, or a host moves between two networks, etc., the
two networks are very unlikely to have the same Global ID. These
addresses can be regarded mostly like the IPv4 privat address
space in RFC 1918, but the pseudo-random ID means that one is
unlikely to have the clashes experienced between sites using the
same IPv4 private address space.

There is an on-going discussion whether one should also specify
centrally assigned Global IDs, where the L-bit would be 0. One
could then guarantee global uniqueness. This is an interesting
discussion, but not all that relevant to our discussion in this
document. It would reduce the risks of conflicts where two sites
are using the same Global ID, but we believe the risk is already
sufficiently small.

2.3 Routing of ULAs

The ULA addresses are not to be routable on the global Internet.
The main reasons for that is that they would generally not be
aggregated, resulting in a large number of /48 prefixes in global
routing; also this would cause problems if two sites connected
to the Internet happened to choose the same Global ID. However,
the ULAs can be routed between small groups of of cooperating
sites. An attempt to use it between large groups increases the
risk of conflicting IDs.

2.4 Scope and reachability

ULA addresses are by default to be treated as globally scoped
addresses. However, they are only locally reachable. This may
cause problems for some applications. There may be a need to
give ULAs preference over other types of global unicast
addresses. One way of doing that is by controlling what
addresses can be looked up in the DNS, see next section. There
are also address selection mechanisms that we will discuss
later.

2.5 ULAs and DNS

The use of ULAs may have a significant impact on the use of
DNS in a site. Generally speaking one would typically
register all the addresses of all the hosts in the DNS, where
anyone from anywhere could look up the host in the DNS and
find the exact same set of addresses. However, the use of
ULAs changes this (as with the use of private IPv4 addresses).

First of all, one should not put ULA addresses in the global
DNS. Since ULA addresses are not globally reachable, but is
of global scope, an application anywhere on the Internet
looking up the host's addresses, may try to contact the host
using the ULA address. If the address is not reachable, it
may take a long time before the application times out and
tries another address; some applications may indeed never try
another address. In the worst case, the same ULA Global ID
may be used in the site where the application resides, and
the application may contact the wrong host. Hence hosts
should only be registered with their globally reachable
unicast addresses in the global DNS. Hosts never are to be
reached from the global Internet, may not even need to be
in the global DNS.

Inside a site using ULAs, one would obviously like to be
able to look up ULA addresses of a host in the DNS; perhaps
all addresses of the host. We will discuss this later in the
document.

The wish to find ULAs when looking up some FQDN in the DNS
internally, but not externally, leads to the deployment of
so-called split DNS. The use of split DNS is likely to make
DNS harder to manage and increase management cost. It may
also be tricky to make a host always get the right information.
E.g. a mobile host visiting an external network should normally
get only the external view, while if it gets a VPN connection
to its home site, one may want it to look up ULA addresses and
reach those through the tunnel.

3. ULAs for intra-site stability

We will consider how one may use ULAs for intra-site stability.
The idea is that one can use ULAs for internal communications,
so that when one changes providers and the Provider Assigned
addresses changes, not only on-going internal communications,
but also configuration files and applications that deal with
internal communications, remains unaffected. We will
discuss how this might be done, to what degree it can provide
stability and simplify management while changing external
addressing, and also possible issues, including increased
complexity and management. We will see that there are benefits,
but there is also a cost.

The main problem with renumbering (change of addressing) are
perhaps various configuration files that have hardcoded
addresses, application clients and servers that need to be
restarted due to long time caching of addresses, and sessions
both at the transport layer (like TCP), and the application
layer that may be reset. By using stable addressing internally
one can hopefully keep things more stable, and also limit the
amount of configuration changes.

For end-to-end connectivity all hosts in the site that are
to communicate with the outside world, will need to have a
global address. These are the PA addresses that may need to
change. In our case, we also assume that all hosts in the
site has a ULA address from a given ULA /48 prefix that the
site is using (based on some ULA Global ID). Note that it
is not a strict requirement that all hosts in the site has
a ULA, some may and some may not, but we assume all to
simplify our discussion. Note that when using stateless
address autoconfiguration all hosts on a given link will
get addresses with the same prefixes. In general the
easiest is probably to give all hosts both global and
private addresses. This includes having internal routing
for both ULA and PA addresses, and announcing both on
all (most) links.

The site will probably need to add ULA addresses in the
DNS for FQDNs of internal hosts. As discussed in 2.5 the
site will then need to deploy split DNS since the ULAs
should not be visible externally. As discussed, this adds
some complexity. There are however several DNS server
implementations supporting this, and the amount of management
work may not increase, depending on the management systems
used.

3.1 Address selection

If we now consider that the internal hosts in the site both
have ULAs (internal addressing) and one or more PA addresses
(external addressing). How can one we ensure that internal
addresses are used for internal communications, while external
addresses for external communications? Basically we would like
to use internal addressing if both hosts have addresses from
the same /48 ULA prefix, otherwise external. One might want to
do this for ULA more generally if there are multiple
cooperating sites using ULA.

IPv6 implementations should do address selection according to
RFC 3484. The RFC defines a default behaviour, but allows for
this to be modified. Whether this behaviour can be modified
varies between the different implementations. RFC 3484
distinguishes between IPv4 and IPv6, 6to4 vs native, and also
takes scoping into account. However, it has no knowledge of
ULAs, and ULAs are treated as being of global scope. That is,
the mechanism doesn't treat ULAs any different from the PA
addresses.

If say a client tries to reach a server, it may look up the
server's FQDN in the DNS and obtain both a ULA and a PA
address. The client will need to choose which address to
try to connect to (in which order to try them). Assuming
both the addresses are valid, not deprecated etc, the rules
that come into play for choosing ULA vs PA will be "longest
matching prefix" and if that makes no difference, the order
the addresses were returned from the DNS. Longest prefix
match ensures that if the client has only a ULA address,
then it will prefer the server's ULA address. If the client
only has a PA address, then it's fairly certain that the
server's PA address will get a better match. But what does
happen if the client and the server, both got ULA and PA
addresses?

If we look at two hosts using stateless address autoconfig
that both reside on the same link, where there are two /64
prefixes on the link, one ULA and one PA, then the longest
prefix match rule will not make a distinction, between
using ULA for both destination and source, or PA for both
destination and source. Also, many sites are likely to use
say a /48 prefix for the PA addresses, matching the ULA
prefix length. For ease of maintenance, the site may then
use the exact same bits for the remaining bits of the
addresses. Then longest prefix match will not give a
preference for ULA vs PA for any pair of hosts in the
site.

This means that when deploying both ULA and PA, the
order returned by the DNS is likely to be the deciding
factor. Hence one may be able to prefer ULA over PA for
internal communications if the DNS sorts ULAs first.
Perhaps an easier method is to only have ULAs in the
internal DNS.

Note that some implementations allows the policy table
in RFC 3484 to be customised. This means that the host
administrator may be able to add a rule for preference
of the site's ULA prefix (and possibly for ULA prefixes
of cooperating sites that also are known to be reachable).
However, not all implementations do this, and it's also
implementation specific how exactly to change this
table. There is some on-going work for using e.g. DHCPv6
to configure the policy table and also for changing the
default table. At the moment it is basically left to the
administrator to figure out whether and how the default
table may be changed on the different platforms. Provided
that the table is updated to prefer ULAs, one can safely
also put PA addresses in the internal DNS.

Address selection can get complicated for some applications.
If for instance the site is streaming some video, the source
address need to be PA if the stream is to go outside the
site, while if internal one probably would prefer ULA. This
can not be determined automatically. Also, a user in the
site wants to receive the stream needs to know which
address to use (although this could be via SDP or a URL
etc). The user cannot necessarily just use the FQDN of the
streaming host. This could lead the client to expect data
from the wrong address; in particularly if a PA address is
used for the stream and only ULAs are in the internal DNS.

4. IPv4 addresses for intra-site stability

Sites deploying IPv6 will generally do it alongside IPv4,
so that both protocols can be used. This may change in
the long term. One common scenario will probably be to
use IPv4 NAT with private addresses internally, and IPv6
with end-to-end connectivity and PA addresses. Using the
private IPv4 addresses for internal connectivity would
provide stable addressing.

Address selection would get difficult in this case. For
external hosts one would like to prefer IPv6 over IPv4
(at least in the case with IPv4 NAT), while for internal
hosts one would like IPv4 over IPv6. In this scenario
one would also end up using split DNS (to have the
private IPv4 addresses only visible in internal DNS),
and one could consider solving this by only having IPv4
addresses for hosts in internal DNS.

To only use IPv4 for intra-site connectivity would be
a bad idea in the long term though. The site may at
some point in the future get some IPv6-only devices
or prefer to make some part of the site IPv6-only.
But this could be a possible path for a site that is
currently using IPv4 NAT and private addressing
internally.

5. Conclusions

We have discussed how one may use stable addressing
like ULA, or perhaps even private IPv4 address space,
to provide intra-site addressing to be independent of
the PA addresses used for external connectivity. This
means that internal addresses can remain fixed and be
independent of any renumbering caused by a change of
providers. The benefits are that internal connections
are not reset at the time of renumbering, but perhaps
more importantly that configuration of internal
services need not be changed. On the other hand, the
use of the internal addressing adds complexity like
split DNS and possible problems with address selection.

Whether these techniques are useful, depends on how
often one changes providers, on the number of services
deployed in the site, and how much internal communication
there is. They add complexity in day-to-day operations,
but make it easier to change providers, in particular if
there are many internal services deployed.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 28 Nov 2008 11:50:32 -0800

Yes, we all know that it is much easier to get O/S vendors to fix their billion plus lines of code and the apps vendors to fix their million plus lines of code than it is to deploy a $50 NAT box.

What you are proposing here is that we bell the cat instead.

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]]
Sent: Wed 11/26/2008 5:40 PM
To: Hallam-Baker, Phillip
Cc: Eric Klein; Fred Baker; [email-masked] WG; IAB; IETF Discussion; [email-masked]; IESG IESG
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers 

	Mark

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 28 Nov 2008 12:06:29 -0800

It is quite easy to see how an application that is designed to tolerate renumbering is able to cope with it given appropriate O/S and protocol level support. I suspect what is happening there is that SSH loses the connection and then transparently attempts to reconnect before telling the user that it has failed and dropping the entire connection state.

But most IP applications are not designed to maintain connections for days, SSH is a rarity in that respect.

Renumbering your network every day is probably quite practical. Trying to change an address after it has been constant for a year or more is a recipe for pain and anguish. The more infrequent an event is, the less pleasant it becomes. 

I don't like the suggestion of using different addresses for local and Internet traffic for the same reason. Once you start to have more than one way for two things to communicate there is going to be more scope for error.

Changing the IP address on the host end every day or introducing split addresses seems to be a much more disruptive change to the network than NAT. 

-----Original Message-----
From: [email-masked] on behalf of David Morris
Sent: Wed 11/26/2008 5:59 PM
Cc: IETF Discussion
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact toapplicationdevelopers 

Dave Morris

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 28 Nov 2008 12:27:14 -0800

Again, there needs to be an expectations reset here.

The pro-NAT faction are not 'asking' for anything. They are serving notice that this is the approach that they intend to take.

You are saying, 'you can beg for your NAT but I am not giving it to you, now go away'. They are saying, 'I do not recognize your asserted veto power'.

Not many folk realize that when the comment was made about rough consensus and running code was made it was not a compliment, it was an observation that the IETF process is frequently pre-empted by unilateral decisions. Rough consensus does not have to mean a majority. In the past it has frequently meant a cabal that had a consensus amongst themselves and just decided they were going to do something.

If your idea of a representative 'application' program is SSH you are certainly not an application programmer. SSH is a tool that is almost exclusively used by network and system admins and programmers. Being robust in the face of network instability is a major functional requirement when you are debugging a network. 

Application programmers in general have zero interest in the design, coding and testing effort necessary to work in a network with arbitrary administrative renumbering. End users are going to demand a reliable network rather than allow their network to be subjected to unnecessary instability because some IETF faction thinks that keeping the network address constant from end to end is more important.

-----Original Message-----
From: [email-masked] on behalf of Tony Hain
Sent: Wed 11/26/2008 6:16 PM
To: 'David Morris'
Cc: 'IETF Discussion'
Subject: RE: [BEHAVE] Lack of need for 66nat : Long term impactto	applicationdevelopers 

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Nov 2008 15:34:10 -0500

Hallam-Baker, Phillip wrote:
> It is quite easy to see how an application that is designed to tolerate
> renumbering is able to cope with it given appropriate O/S and protocol
> level support. I suspect what is happening there is that SSH loses the
> connection and then transparently attempts to reconnect before telling
> the user that it has failed and dropping the entire connection state.
> 

SSH is also a rarity in that there is usually a good correspondence
between a DNS name and the specific entity to which one wishes to
connect via SSH.  So it makes more sense for an SSH client to  try to
reconnect to a peer and continue a session than it does, say, for an FTP
client.

> Renumbering your network every day is probably quite practical. 

I seriously doubt that.  There are very few layer 7 protocols which can
gracefully tolerate that kind of disruption, and our architecture
doesn't really give them a good way to do that.  And it's not just a
naming problem.

Granted that if we were to start renumbering more frequently, we'd get
better at it.  But the Internet architecture as it currently exists
doesn't come close to supporting that.  Which of course, is part of why
people continue to want NAT - so at least they can avoid renumbering for
local applications.

Keith

---

From: "AJ Jaghori" <[email-masked]>
Date: Fri, 28 Nov 2008 16:47:26 -0500

Lol :) I couldn't agree you any more...

On 11/28/08, Hallam-Baker, Phillip <[email-masked]> wrote:
>
>
> Yes, we all know that it is much easier to get O/S vendors to fix their
> billion plus lines of code and the apps vendors to fix their million plus
> lines of code than it is to deploy a $50 NAT box.
>
> In message
> <[email-masked]

-- 
AJ Jaghori
Chief Network Architect | Author | Professor
[email-masked]
M: 703.362.5002
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 29 Nov 2008 22:57:26 +0100

On Wed, Nov 26, 2008 at 08:44:31AM -0800,
 Hallam-Baker, Phillip <[email-masked]> wrote 
 a message of 431 lines which said:

> In fact it would be best for the O/S to provide an API which hides
> the details of the IP address from the application entirely in the
> same way that the ethernet MAC address is hidden.

I agree and some people are working on it:

Towards A Hostname-Oriented Network Protocol Stack for Flexible
Addressing in a Dynamic Internet
<http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Marc Manthey <[email-masked]>
Date: Sun, 30 Nov 2008 00:12:23 +0100

> <http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf 
> >

that's pretty interesting too

" Unmanaged Internet Architecture "

http://pdos.csail.mit.edu/uia/

regards

Marc

--
Marc Manthey 50672 Köln - Germany
Hildeboldplatz 1a
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
mail: [email-masked]
PGP/GnuPG: 0x1ac02f3296b12b4d
jabber :[email-masked]
IRC: #opencu  freenode.net
twitter: http://twitter.com/macbroadcast
web: http://www.let.de

Opinions expressed may not even be mine by the time you read them, and  
certainly don't reflect those of any other entity (legal or otherwise).

Please note that according to the German law on data retention,  
information on every electronic information exchange with me is  
retained for a period of six months.

---

From: Keith Moore <[email-masked]>
Date: Sat, 29 Nov 2008 23:26:54 -0500

> <http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf>

If by "hostname" the authors mean DNS names, then this approach is naive
in the extreme.

Granted it would be nice to have better application level endpoint
identifiers than either IP addresses or DNS names, but you're not going
to get a sufficiently fast, secure, and reliable mechanism for
associating stable endpoint names with addresses without considerable
engineering work.  DNS is too slow and too often incorrect.  And while
it's true that IP addresses don't have the right semantics, neither do
DNS names.

Keith

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 30 Nov 2008 16:49:19 +0100

On Sat, Nov 29, 2008 at 11:26:54PM -0500,
 Keith Moore <[email-masked]> wrote 
 a message of 27 lines which said:

> If by "hostname" the authors mean DNS names, 

I would personally make a difference between the concept of a domain
name and the protocol used to resolve them (today, mostly DNS).

The domain names will probably stay for a very long time, now that
people are used to it. The DNS may be replaced or partially replaced
in the future by new protocols (such as P2P ones).

So, I believe that the term of "DNS name" is confusing.

> DNS is too slow and too often incorrect. 

See the remark above. If we replace DNS with a "better" protocol,
would your objection still stand?

> And while it's true that IP addresses don't have the right
> semantics, neither do DNS names.

Please elaborate. I agree that the current resolution protocol is not
perfect but what is wrong with the semantics of domain names?
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 30 Nov 2008 19:06:43 -0800

> name and the protocol used to resolve them (today, mostly DNS).

Yup.

> would your objection still stand?

This question presumes that problems with performance and reliability are due to 
the protocol,  rather than its implementation and/or operation.

> perfect but what is wrong with the semantics of domain names?

Where is the alternative specification to compare against?  Where are the 
details for implementing, deploying and using, to compare against?

It's always appealing and trivially easy to take an existing infrastructure and 
find fault with it when comparing to something no more concrete than an idea.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Day <[email-masked]>
Date: Sun, 30 Nov 2008 22:32:29 -0500

>perfect but what is wrong with the semantics of domain names?

As we have known since the early 80s, naming the host has nothing to 
do with the problem at hand.  It is sloppy and gets in the way of 
getting it right.  Currently, domain name is a synonym for an 
IP-address.  The IP-address names the interface and is largely 
redundant since the MAC address does the same thing.

Naming the host is sometimes useful for network management purposes, 
but really has nothing to do with the problem of forwarding or 
delivering packets.  I realize there is a lot of sentimental 
attachment to the idea of naming a host, but as I said that was a 
sloppy habit we got in very early and for some reason sloppiness has 
prevailed.

The "entity" to be named is whatever the packets are delivered to. 
That may reside on a host, but that fact is purely coincidental.  As 
long as sentimentality trumps logic, it will be difficult to get it 
right, but in the current climate it will be possible to publish a 
lot of papers.

Take care,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 30 Nov 2008 21:05:34 -0800

John Day wrote:
> As we have known since the early 80s, naming the host has nothing to do 
> with the problem at hand.  It is sloppy and gets in the way of getting 

"The problem at hand" is what, exactly?  Concretely and specifically.

> it right.  Currently, domain name is a synonym for an IP-address.  The 
> IP-address names the interface and is largely redundant since the MAC 
> address does the same thing.

Ignoring, for the moment, that a domain name does not always map to an IP 
Address, nevermind that it often maps to a set of them, the fact of mapping is 
not quite the same as being "synonymous".  It can be -- and often is -- 
equivalent to find a path to the named resource.  A path is not a synonym.

www.example.com is a common name for the an organization's online web presence.

That sort of description of the name is quite different from the mechanical and 
narrow simplicity of a host name or a synonym for a *set of* IP Addresses that 
might refer to a single machine or to multiple.

d/

-- 

   Dave Crocker