Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"?

From: Fred Baker <[email-masked]>
Date: Sat, 1 May 2010 15:44:48 -0700

On Apr 30, 2010, at 4:21 PM, Schwarz Albrecht wrote:

> Question: If a realm is characterized by reachability, then I would
> assume that an "IPv6 realm" would equate to an "IPv6 routing domain",
> right?

well, here things get squirrelly.

Look again at the picture in my original email in this thread:

       ------         ------         ------         ------
     // My   \\     //      \\     //      \\     // Your \\
    /ULA Realm \   /    ISP1  \   /   ISP2   \   /ULA Realm \
   ||          || ||          || ||          || ||          ||
   | +---+     +---+           | |           +---+      +---+|
   | |Me |     |DMZ|         -------         |DMZ|      |You||
   | +---+     +---+           | |           +---+      +---+|
   ||          || ||          || ||          || ||          ||
    \          /   \          /   \          /   \          /
     \\      //     \\      //     \\      //     \\      //
       ------         ------         ------         ------

   |<- my realm ->|<--------  Core Realm ----->|<-your realm->|

If these were IPv4 routing domains, the counterpart to a ULA would be an RFC 1918 prefix, and the reason that it wasn't injected in the the relevant ISP's routing was (beyond contracts and all that) that it would make routing in the ISP ambiguous: it would be actively bad. In IPv6 routing, the reason that a ULA is "local" is that the ULA domain doesn't advertise it outside of its domain and the ISP doesn't accept it if it did. But if they two agreed to advertise and believe it, there is no substantive reason that they *couldn't* - it wouldn't hurt anything.

Now, in the default-free zone (to the extent that such a thing really exists in the core), there are all sorts of places in which we aggregate routing, disbelieve routes advertised, and choose to advertise or not advertise routes. That makes it hard to argue that the fact of applying policy to routes marks off routing domains. I tend to come back to the definition of an "autonomous system", no doubt made for EGP or BGP but escaping search at the moment: "a set of networks using a common routing protocol and under common administration" for a "routing domain" - it is a region in which we can rationally expect routing to be consistent.

---

From: Fred Baker <[email-masked]>
Date: Sat, 1 May 2010 15:46:03 -0700

except that he probably would like to be able to reasonably easily obtain new address space for his future business requirements. There are rumored to be issues there. Something related to the word "finite".

On Apr 30, 2010, at 4:43 PM, james woodyatt wrote:

> On Apr 30, 2010, at 16:20, Chris Engel wrote:
>> 
>> If NAT provides me exactly the functionality I want now....doesn't break any protocols/applications I want to use. The applications/protocols it breaks I ACTUALY WANT broken.... why would I want to switch to RISP instead?
> 
> I don't even know why you would want IPv6.  It doesn't seem to buy you anything that you don't already have with IPv4/NAT.
> 
> I was merely countering your assertion that NAT is required to prevent unique-local routing topology from being exposed to exterior domains.  It isn't, as the example of RSIP demonstrates.  Concerns about reachability and stateful flow tracking can be handled orthogonally with things like I-D.ietf-v6ops-cpe-simple-security.
> 
> Look, I'm not trying to persuade you that you shouldn't use NAT at your borders-- indeed, as I said before, your plan to stay IPv4-only on local networks and to rely on NAT46 gateways to communicate with exterior IPv6 networks is a perfectly reasonable one.  You should go do that.  It sounds to me like the optimal solution for you.
> 
> 
> --
> james woodyatt <[email-masked]>
> member of technical staff, communications engineering
> 
> 
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

http://www.ipinc.net/IPv4.GIF

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 May 2010 15:32:19 +1200

> Look again at the picture in my original email in this thread:

And if Me and You cared to interconnect their networks with a
leased line, they could mutually announce their ULA prefixes
to each other. This would bind the two routing domains
in some way, but they would still be separate autonomous
system. Which wouldn't hurt anything either. That's actually
why ULAs are (a) unique and (b) of nominally global scope, and
it's another reason why the term "IPv6 Realm" doesn't seem useful.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Sun, 02 May 2010 18:10:51 -0400

>
> I'd like to come back to the concept of a realm and a possible
> definition for "IPv6 realm".
Problem is, we're already using the term "realm" in IPv4 to mean
something different.  So while there's definitely a useful concept here
to be teased out, "realm" seems likely to be confusing.

As an off-the-top-of-my-head suggestion,  how about "enclave"?

Keith

---

From: Chris Engel <[email-masked]>
Date: Mon, 3 May 2010 11:00:32 -0400

James,

I believe what I asserted was the following....

"The factual thing that can be said about NAT is that it obscures the literal IP address assigned to an end device from a source on the other side of the NAT boundary. For some that is a desired effect for others it's an undesirable problem.......

......

You are not going to achieve that level of "obscurity" without some form of address translation....and any solution that you do provide to achieve that obscurity will have much of the same side effects that todays NAT does."

As far as I'm concerned, that assertion continues to stand in the face of RISP. Under RISP (unless I understand it wrong) the PA address IS actualy bound on the end device itself and IS exposed to external sources... it's just that the duration of that assignment is limited. Furthermore, in order to be practicaly useful, RISP must have some sort of out-of-band registry that largely obviates much of the obscurity it might otherwise provide. Finally, to the degree that it does provide a level of obscurity....it does cause many of the same sort of side effects that NAT does.

On a more fundemental level, the goals of "transparency" and "end-to-end reachabilty" that seem to be part of the guideing principles that the designers of IPv6 built into thier work is anthetical to the goals of many of the people actualy using the internet. Many people don't want thier networks to be perfectly "transparent"...they want them to be quite opaque in fact....and they don't want thier end devices (in general) to be perfectly reachable. Unless that diversity of goals is recognized and accounted for... IPv6 is destined to remain the "New Coke" of it's generation.

Christopher Engel

> -----Original Message-----
> From: james woodyatt [mailto:[email-masked]]
> Sent: Friday, April 30, 2010 7:43 PM
> To: Chris Engel
> Cc: NAT66 HappyFunBall
> Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"?
>
>
> > If NAT provides me exactly the functionality I want now....doesn't
> > break any protocols/applications I want to use. The
> > applications/protocols it breaks I ACTUALY WANT broken....
> why would I
> > want to switch to RISP instead?
>
> I don't even know why you would want IPv6.  It doesn't seem
> to buy you anything that you don't already have with IPv4/NAT.
>
> I was merely countering your assertion that NAT is required
> to prevent unique-local routing topology from being exposed
> to exterior domains.  It isn't, as the example of RSIP
> demonstrates.  Concerns about reachability and stateful flow
> tracking can be handled orthogonally with things like
> I-D.ietf-v6ops-cpe-simple-security.
>
> Look, I'm not trying to persuade you that you shouldn't use
> NAT at your borders-- indeed, as I said before, your plan to
> stay IPv4-only on local networks and to rely on NAT46
> gateways to communicate with exterior IPv6 networks is a
> perfectly reasonable one.  You should go do that.  It sounds
> to me like the optimal solution for you.
>
>
> --
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 May 2010 11:10:29 -0400

> You are not going to achieve that level of "obscurity" without some form of address translation....and any solution that you do provide to achieve that obscurity will have much of the same side eff…
Actually, this seems like what IPv6 Privacy Addresses were made for.

Keith

---

From: james woodyatt <[email-masked]>
Date: Mon, 3 May 2010 10:25:31 -0600

On May 3, 2010, at 09:00, Chris Engel wrote:
> 
> [...] Under RISP (unless I understand it wrong) the PA address IS actualy bound on the end device itself and IS exposed to external sources [...]

Under RSIP, as with NAT, no private addresses are exposed to the external address realm, unless the private host does so at the application layer.  Yes, with RSIP, the public address is bound at the endpoint host instead of inside the NAT gateway.  Why this should make any kind of difference to you is a mystery to me-- I'll be polite and keep my speculations to myself.

> ... it's just that the duration of that assignment is limited. Furthermore, in order to be practicaly useful, RISP must have some sort of out-of-band registry that largely obviates much of the obscurity it might otherwise provide.

The RSIP protocol is intended to run over a secured private network.  No external hosts need be aware that you have deployed RSIP hosts and corresponding gateways.  Your internal network topology remains completely obscured unless your private hosts leak information--- which NAT cannot prevent them from leaking either.

> Finally, to the degree that it does provide a level of obscurity....it does cause many of the same sort of side effects that NAT does.

Like what?  (And, from your point of view, are these side effects desirable or undesirable?) [*]

> On a more fundemental level, the goals of "transparency" and "end-to-end reachabilty" that seem to be part of the guideing principles that the designers of IPv6 built into thier work is anthetical to the goals of many of the people actualy using the internet. Many people don't want thier networks to be perfectly "transparent"...they want them to be quite opaque in fact....and they don't want thier end devices (in general) to be perfectly reachable. Unless that diversity of goals is recognized and accounted for...

You say, to the guy who's been editing I-D.ietf-v6ops-cpe-simple-security for the last three years.  Situation awareness FAIL.

> IPv6 is destined to remain the "New Coke" of it's generation.

Is that what this is about?  You're afraid we're going to take your "Classic Coke" off the market?  As if we could do that?  As if *anybody* could do that?  That's absurd.

----

[*] These questions seem actually On Topic for the NAT66 list.  I'm genuinely interested in seeing a response to them.  The rest of this message is an attempt to clear some misunderstandings about RSIP and my animating motivations here.

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 May 2010 09:37:45 -0700

Maybe. I personally am not sure it needs a name. I agree that it is not a "realm" in the sense that the term is used in IPv4.

On May 2, 2010, at 3:10 PM, Keith Moore wrote:

> Problem is, we're already using the term "realm" in IPv4 to mean something different.  So while there's definitely a useful concept here to be teased out, "realm" seems likely to be confusing.
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 May 2010 09:46:17 -0700

> Actually, this seems like what IPv6 Privacy Addresses were made for. 

actually, no.

privacy addresses obscure the EID, the lower 64 bits, but don't obscure the locator information. Chris specifically would like to obscure the locator.

One could argue that NAT66 obscures the locator, in the sense that the bits used inside the house are not the same as are used outside the house. However, there is a 1:1 and onto relationship between the inside and outside expressions. That's not very obscure.

At the end of the day, however, any application that expresses an address in its content is overcoming any obscurity one thinks one is getting at the network layer. Consider the addresses in SMTP email; from this email that I am responding to, I can determine that [email-masked] sends email to 173.136.67.67 lust.indecency.org, which is a Mirapoint system, which as m1.imap-partners.net [64.13.152.131] sends it on to someone else - in this case, AMS operating on behalf of the IETF. Oh, you obscured all that at the network layers? Pardon me...

---

From: Chris Engel <[email-masked]>
Date: Mon, 3 May 2010 13:25:18 -0400

Fred,

What you said about the application layer is entirely true. However, the whole point of the OSI model (As I understand it) is to allow people to deal with the layers in a somewhat modularized fashion. One can, presumably, address how much or how little information is revealed by a particular application in a discussion targeted at the applications function itself. If the network layer is revealing information itself...then nothing about how a particular application functions is relevant there.

To use an analogy, I can design an application that requires the use of strong passwords to control access to it. I can't design an application that would prevent an authorized user from telling every single person they encounter what thier strong password is. That would have to be addressed at the level of organizational security & acceptable use policy...not in application design. However, if the application design itself doesn't support the use of strong passwords.... then nothing I can do at the level of acceptable use policy can make them happen.

On the network level, I basicaly want something that entirely abstracts my internal architecture from my external advertisement of services...and essentialy functions as a proxy/intermediary between my internal devices and thier external presence at the boundary between internal/external. NAT very handly does that currently in IPv4. From the discussions that I've had with alot of people involved with IPv6...and many of the people who have strongly argued against any sort of NAT in IPv6... they basicaly seem to be disagreeing not just with the particular method I want to use....but with my end goal itself.

Christopher Engel

> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, May 03, 2010 12:46 PM
> To: Keith Moore
> Cc: Chris Engel; NAT66 HappyFunBall
> >> "The factual thing that can be said about NAT is that it
> obscures the
> >> literal IP address assigned to an end device from a source on the
> >> other side of the NAT boundary. For some that is a desired
> effect for
> >> others it's an undesirable problem.......
> >>
> >> ......
> >>
> >> You are not going to achieve that level of "obscurity"
> without some
> >> form of address translation....and any solution that you
> do provide
> >> to achieve that obscurity will have much of the same side effects
> >> that todays NAT does."
> >>
> privacy addresses obscure the EID, the lower 64 bits, but
> don't obscure the locator information. Chris specifically
> would like to obscure the locator.
>
> One could argue that NAT66 obscures the locator, in the sense
> that the bits used inside the house are not the same as are
> used outside the house. However, there is a 1:1 and onto
> relationship between the inside and outside expressions.
> That's not very obscure.
>
> At the end of the day, however, any application that
> expresses an address in its content is overcoming any
> obscurity one thinks one is getting at the network layer.
> Consider the addresses in SMTP email; from this email that I
> am responding to, I can determine that
> [email-masked] sends email to 173.136.67.67
> lust.indecency.org, which is a Mirapoint system, which as
> m1.imap-partners.net [64.13.152.131] sends it on to someone
> else - in this case, AMS operating on behalf of the IETF. Oh,
> you obscured all that at the network layers? Pardon me...
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 May 2010 11:21:12 -0700

> On the network level, I basicaly want something that entirely abstracts my internal architecture from my external advertisement of services...and essentialy functions as a proxy/intermediary betwee…

I would agree that many in the IPv6 community disagree with your goal. Their fundamental objective is end to end transparency, and your fundamental objective is end to end opaqueness. You disagree with each other. I understood from your previous emails in this thread that you felt they were "wrong" or that you felt that they felt you were "wrong"; I don't think either is "wrong" per se, but you certainly disagree.

Personally, I think the term "NAT" in the moniker for this draft was particularly unfortunate, and said that to Margaret when I agreed to co-author. Since we are talking about something fundamentally different than IPv4/IPv4 NAT, we have the same issue that has been discussed with the term "realm". We wind up with this discussion, which is not a stupid discussion, but is off topic with respect to the proposal in question. When the IETF had a BOF on the topic, that was incredibly clear. We had a proposal on the table which was most decidedly *not* re-implementing IPv4/IPv4 NAT in an IPv6/IPv6 world, but the entire discussion from the floor was "we don't want to re-implement IPv4/IPv4 NAT in an IPv6/IPv6 world", largely non-responsive to the topic at hand. It winds up consuming a lot of cycles, is very emotional, and drowns out reasonable discussion on anything else. Take a look at this thread as an example. We have collectively exchanged 39 messages (this is the 40th), of which perhaps half a dozen have been on topic and the remainder have been related to re-implementing IPv4/IPv4 NAT in an IPv6/IPv6 world, something which is specifically not the topic of the list.

Regarding NAT, though, in http://www.ietf.org/rfc/rfc4864.txt, some strong proponents of the transparent model addressed what they thought were the primary reasons for the use of NAT. They didn't cover this one, so to speak. But it might be worth your while to acquaint yourself with their viewpoint. In short, NATs not only achieve a certain level of obfuscation of the network layer, they make it harder to build applications of a certain class - applications in which the address of one's peer must be known at the time one wants to use it. Real time applications, such as VoIP and Video/IP, fall in this category. More generally, the entire realm of peer-to-peer applications does. The imposition of NAT has not altogether stopped such development, though; what it has done is make it a lot harder, resulting in companies like Napster, BitTorrent, and Skype building byzantine overlay networks to overcome the issues it presents. In the realm of voice and video, it has engendered RSIP and the use of SIP Proxies as gateways between domains. NAT hasn't actually protected any networks, I will argue; it has merely made scaling the walls a little harder. 

The goal of those that would like to not have any translation at all - here, Keith, I'm putting words into your mouth, so please feel free to correct them - is essentially the counterpoint of that. The world is poorer for the applications that have not been developed due to firewall and NAT boundaries, and they would like to be able to build interesting applications that don't need the byzantine structures to bypass what they consider to be ineffective and deluded security architectures. If using NAT to flatten the addresses expressed at the DMZ has been ineffective in preventing attacks (the vast majority of which come from behind the firewall anyhow) and have made application development more difficult, what's the point? They would rather go with the end to end principle as stated by Saltzer (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf) and enable users to make the Internet and the applications that use it more valuable.

For my part, and the part of this proposal (and the ILNP proposal that RRG is putting forward), I am all for the free development of useful applications. I don't see the value of NAT, given its history of not stopping attacks and of preventing applications. I see a problem that needs addressing though, related to management of the backbone route table. In short, we now have O(10^5) prefixes in the IPv4 route table, and perhaps two years from now will easily have O(10^6) as people buy and sell prefixes. As an equipment vendor, I have no problem with that - if you'll pay for the memory, I'll happily sell it to you. But I don't want to hear about either capex or opex, I don't want to hear about "green" aspirations, and I don't want to hear about the price of the equipment. You make the bed, you lie in it. As we collectively move to IPv6, we have a choice. We can replicate the IPv4 swamp, complete with its route table, or we can change it. I vote that we change it.

In the area of addressing, networks at the edge are pushing back very hard on the provider-allocated addressing model, and are driving for provider-independent addressing. Reason: they don't want to be captives of their providers. I'm sympathetic with them. But consider the implications: if they all have PI addresses, we are enumerating the objects at the edge, and even today we have O(10^7) or more objects at the edge. PI addresses take us in the direction of a swamp at least as bad as that in the IPv4 network. Service providers find the PA model very attractive, both because it provides a market lock on their customers and because it helps them manage their route tables.

From my perspective, I would like to achieve some of the goals of all of the players. I obviously can't both lock and unlock customers, so whatever I do is wrong there from someone's perspective. But by Network Prefix Translation, the subject of this list, I can give edge networks the appearance of PI (they are independent of their providers for addressing) and the service providers the appearance of PA (they enumerate the ISPs at the edge, O(10^3 to 10^4) instead of objects at the edge, O(10^5, 10^6, or 10^7)). The boundaries are address-translucent, not either transparent or opaque, so while I don't give you what you want I give you something a step in its direction. And I give Keith what he wants - if he can find it in his heart to have applications use names instead of addresses, he gets all of the access between applications that he needs. And for those that operate networks, it reduces their capex and opex. It requires everyone to think a little differently, but if they are willing, they get most of what they are looking for.

I hope this is useful.

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 May 2010 11:54:27 -0700

There is one additional comment I should make and overlooked. Folks like Keith and Brian will point to shim6, the notion that PA prefixes allocated to edge networks by each of their ISPs, can be used to provide a PA view of the world to the ISPs. Yes, and notice how great the uptake is. In short, that (like LISP) moves the complexity of the network to those least motivated and least equipped to manage it. If you buy RFC 3439's "Principle of Simplicity", the network has to be simple in all of its places, not just the ones of interest to you. Moving the complexity to the part time IT manager is not a recipe for success. So no, I don't see shim6 as a solution.

I see two solutions that work: exchange-based addressing (what has been called Metropolitan Addressing) and GSE or some variant of it. Network Prefix Translation at the IP layer, with application use of names in preference to addresses, to my small mind produces the simplest of all networks, and comes most closely to meeting the combined list of goals.

On May 3, 2010, at 11:21 AM, Fred Baker wrote:
> Personally, I think the term "NAT" in the moniker for this draft was particularly unfortunate, and said that to Margaret when I agreed to co-author. Since we are talking about something fundamentally different than IPv4/IPv4 NAT, we have the same issue that has been discussed with the term "realm". We wind up with this discussion, which is not a stupid discussion, but is off topic with respect to the proposal in question. When the IETF had a BOF on the topic, that was incredibly clear. We had a proposal on the table which was most decidedly *not* re-implementing IPv4/IPv4 NAT in an IPv6/IPv6 world, but the entire discussion from the floor was "we don't want to re-implement IPv4/IPv4 NAT in an IPv6/IPv6 world", largely non-responsive to the topic at hand. It winds up consuming a lot of cycles, is very emotional, and drowns out reasonable discussion on anything else. Take a look at this thread as an example. We have collectively exchanged 39 messages (this is the 40th), of whic
> h perhaps half a dozen have been on topic and the remainder have been related to re-implementing IPv4/IPv4 NAT in an IPv6/IPv6 world, something which is specifically not the topic of the list.
> 
> Regarding NAT, though, in http://www.ietf.org/rfc/rfc4864.txt, some strong proponents of the transparent model addressed what they thought were the primary reasons for the use of NAT. They didn't cover this one, so to speak. But it might be worth your while to acquaint yourself with their viewpoint. In short, NATs not only achieve a certain level of obfuscation of the network layer, they make it harder to build applications of a certain class - applications in which the address of one's peer must be known at the time one wants to use it. Real time applications, such as VoIP and Video/IP, fall in this category. More generally, the entire realm of peer-to-peer applications does. The imposition of NAT has not altogether stopped such development, though; what it has done is make it a lot harder, resulting in companies like Napster, BitTorrent, and Skype building byzantine overlay networks to overcome the issues it presents. In the realm of voice and video, it has engendered RSIP 
> and the use of SIP Proxies as gateways between domains. NAT hasn't actually protected any networks, I will argue; it has merely made scaling the walls a little harder. 
> 
> From my perspective, I would like to achieve some of the goals of all of the players. I obviously can't both lock and unlock customers, so whatever I do is wrong there from someone's perspective. But by Network Prefix Translation, the subject of this list, I can give edge networks the appearance of PI (they are independent of their providers for addressing) and the service providers the appearance of PA (they enumerate the ISPs at the edge, O(10^3 to 10^4) instead of objects at the edge, O(10^5, 10^6, or 10^7)). The boundaries are address-translucent, not either transparent or opaque, so while I don't give you what you want I give you something a step in its direction. And I give Keith what he wants - if he can find it in his heart to have applications use names instead of addresses, he gets all of the access between applications that he needs. And for those that operate networks, it reduces their capex and opex. It requires everyone to think a little differently, but if they
>  are willing, they get most of what they are looking for.
> 
> I hope this is useful.

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 3 May 2010 12:34:38 -0700

Shim6 is very different from LISP.  Shim6 is implemented in the host, and LISP in the CPE router (like, for example, NAT66 would be).  Shim6 seems to have more in common to ILNP than LISP.  So your point below doesn't make much sense to me.

-Darrel

---

From: Chris Engel <[email-masked]>
Date: Mon, 3 May 2010 15:40:24 -0400

Fred,

On 10,000 ft level, I think that the real success story of the internet is that it allows for a wide diversity of usage cases and supports organizations with a wide diversity of goals. If it's going to continue to be successful in future, I think it will need to continue to support such diversity of goals/usage. Those goals/usage cases don't have to be compatible with each other. In fact, I think that would be an unachievable goal. However, I believe there needs to be room for all of them to continue to exist on the Net.

I really don't have any problem with anyone who values "end-to-end transparency" as their goal for their OWN usage case of the NET. I have a big problem when some-one is trying to tell me that goal MUST apply to my usage case as well, whether I want it to or not....and then work to retard any public standards being published which describe how my desired goals might be enacted.

For example, peer to peer networking is pretty much anthetical to the standards that my organization embraces. That being said, I have never had a problem with anyone attempting to publish protocols involved with peer-to-peer applications. The end result of such publication might even make peer-to-peer applications more popular...which could even increase MY workload in attempting to prevent unauthorized use of such applications on my network. However, I've never seen that as a justification for my attempting to interfere with the publication of such standards. I'm pretty sure that the authors of such protocols are attempting to provide a solution for people who WANT to embrace it... not make the lives of people who don't more difficult.... even if that is part of the effective result.

If you or Keith or others don't see the value in the kind of NAT solution that I want to use, that's fine. I can't make you see it if you don't want to do so. If Cisco or Apple or whoever don't want to sell that sort of equipment for IPv6 that's fine as well. All that will do is limit the market segment to which you can sell your products. It's a free market economy, if you don't offer such solutions, I'm pretty sure if there is a strong economic demand for them (which I believe there will be) that those of us who strongly desire such solutions will eventually find a vendor willing to fill that demand and accept our cash. All that is really happening right now without that is another factor slowing wide scale adoption of IPv6.

I think on the very first exchange of e-mail I had with Margaret, I mentioned that this particular proposed implementation of NAT66 didn't sufficiently cover my usage requirements. However, I was happy to see it brought forward, as I definitely could see how it might prove useful to certain usage cases. From my perspective, the greater variety of options available the better.... and having publication of standards for those options is better then not having them.

My purpose here is simply as a reminder that there is a large user segment that is currently under represented in discussions taking place on the subject of NAT in IETF and certain other venues.....and that indeed there is VERY far from universal agreement on the goals of end-to-end transparency or reachability. In essence, I'm attempting to provide a counter-point for those who consider such goals as an apriori that everyone is going to be willing to embrace.

Christopher Engel

> Sent: Monday, May 03, 2010 2:21 PM
> To: Chris Engel
> Cc: Keith Moore; NAT66 HappyFunBall
> Subject: Re: [nat66] A bit of perspective
>
>
>
> > On the network level, I basicaly want something that entirely
> > abstracts my internal architecture from my external
> advertisement of
> > services...and essentialy functions as a proxy/intermediary
> between my
> > internal devices and thier external presence at the
> boundary between
> > internal/external. NAT very handly does that currently in
> IPv4. From
> > the discussions that I've had with alot of people involved with
> > IPv6...and many of the people who have strongly argued against any
> > sort of NAT in IPv6... they basicaly seem to be disagreeing
> not just
> > with the particular method I want to use....but with my end goal
> > itself.
>
> I would agree that many in the IPv6 community disagree with
> your goal. Their fundamental objective is end to end
> transparency, and your fundamental objective is end to end
> opaqueness. You disagree with each other. I understood from
> your previous emails in this thread that you felt they were
> "wrong" or that you felt that they felt you were "wrong"; I
> don't think either is "wrong" per se, but you certainly disagree.
>
> Personally, I think the term "NAT" in the moniker for this
> draft was particularly unfortunate, and said that to Margaret
> when I agreed to co-author. Since we are talking about
> something fundamentally different than IPv4/IPv4 NAT, we have
> the same issue that has been discussed with the term "realm".
> We wind up with this discussion, which is not a stupid
> discussion, but is off topic with respect to the proposal in
> question. When the IETF had a BOF on the topic, that was
> incredibly clear. We had a proposal on the table which was
> most decidedly *not* re-implementing IPv4/IPv4 NAT in an
> IPv6/IPv6 world, but the entire discussion from the floor was
> "we don't want to re-implement IPv4/IPv4 NAT in an IPv6/IPv6
> world", largely non-responsive to the topic at hand. It winds
> up consuming a lot of cycles, is very emotional, and drowns
> out reasonable discussion on anything else. Take a look at
> this thread as an example. We have collectively exchanged 39
> messages (this is the 40th), of which perhaps half a dozen
> have been on topic and the remainder have been related to
> re-implementing IPv4/IPv4 NAT in an IPv6/IPv6 world,
> something which is specifically not the topic of the list.
>
> Regarding NAT, though, in
> http://www.ietf.org/rfc/rfc4864.txt, some strong proponents
> of the transparent model addressed what they thought were the
> primary reasons for the use of NAT. They didn't cover this
> one, so to speak. But it might be worth your while to
> acquaint yourself with their viewpoint. In short, NATs not
> only achieve a certain level of obfuscation of the network
> layer, they make it harder to build applications of a certain
> class - applications in which the address of one's peer must
> be known at the time one wants to use it. Real time
> applications, such as VoIP and Video/IP, fall in this
> category. More generally, the entire realm of peer-to-peer
> applications does. The imposition of NAT has not altogether
> stopped such development, though; what it has done is make it
> a lot harder, resulting in companies like Napster,
> BitTorrent, and Skype building byzantine overlay networks to
> overcome the issues it presents. In the realm of voice and
> video, it has engendered RSIP and the use of SIP Proxies as
> gateways between domains. NAT hasn't actually protected any
> networks, I will argue; it has merely made scaling the walls
> a little harder.
>
> The goal of those that would like to not have any translation
> at all - here, Keith, I'm putting words into your mouth, so
> please feel free to correct them - is essentially the
> counterpoint of that. The world is poorer for the
> applications that have not been developed due to firewall and
> NAT boundaries, and they would like to be able to build
> interesting applications that don't need the byzantine
> structures to bypass what they consider to be ineffective and
> deluded security architectures. If using NAT to flatten the
> addresses expressed at the DMZ has been ineffective in
> preventing attacks (the vast majority of which come from
> behind the firewall anyhow) and have made application
> development more difficult, what's the point? They would
> rather go with the end to end principle as stated by Saltzer
> (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend
> .pdf) and enable users to make the Internet and the
> applications that use it more valuable.
>
> For my part, and the part of this proposal (and the ILNP
> proposal that RRG is putting forward), I am all for the free
> development of useful applications. I don't see the value of
> NAT, given its history of not stopping attacks and of
> preventing applications. I see a problem that needs
> addressing though, related to management of the backbone
> route table. In short, we now have O(10^5) prefixes in the
> IPv4 route table, and perhaps two years from now will easily
> have O(10^6) as people buy and sell prefixes. As an equipment
> vendor, I have no problem with that - if you'll pay for the
> memory, I'll happily sell it to you. But I don't want to hear
> about either capex or opex, I don't want to hear about
> "green" aspirations, and I don't want to hear about the price
> of the equipment. You make the bed, you lie in it. As we
> collectively move to IPv6, we have a choice. We can replicate
> the IPv4 swamp, complete with its route table, or we can
> change it. I vote that we change it.
>
> In the area of addressing, networks at the edge are pushing
> back very hard on the provider-allocated addressing model,
> and are driving for provider-independent addressing. Reason:
> they don't want to be captives of their providers. I'm
> sympathetic with them. But consider the implications: if they
> all have PI addresses, we are enumerating the objects at the
> edge, and even today we have O(10^7) or more objects at the
> edge. PI addresses take us in the direction of a swamp at
> least as bad as that in the IPv4 network. Service providers
> find the PA model very attractive, both because it provides a
> market lock on their customers and because it helps them
> manage their route tables.
>
> From my perspective, I would like to achieve some of the
> goals of all of the players. I obviously can't both lock and
> unlock customers, so whatever I do is wrong there from
> someone's perspective. But by Network Prefix Translation, the
> subject of this list, I can give edge networks the appearance
> of PI (they are independent of their providers for
> addressing) and the service providers the appearance of PA
> (they enumerate the ISPs at the edge, O(10^3 to 10^4) instead
> of objects at the edge, O(10^5, 10^6, or 10^7)). The
> boundaries are address-translucent, not either transparent or
> opaque, so while I don't give you what you want I give you
> something a step in its direction. And I give Keith what he
> wants - if he can find it in his heart to have applications
> use names instead of addresses, he gets all of the access
> between applications that he needs. And for those that
> operate networks, it reduces their capex and opex. It
> requires everyone to think a little differently, but if they

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 May 2010 12:39:24 -0700

OK, so for your usage case, you want the exact concepts in IPv4/IPv4 NAT re-implemented in an IPv6/IPv6 world. Got it.

Can we who are talking about something else discuss the topic of this list, please?

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 3 May 2010 12:46:55 -0700

> Actually, this seems like what IPv6 Privacy Addresses were made for. 

IPv6 privacy addresses have to be managed by the application and/or the OS,
and to achieve the same result as NAPT would need to be changed _much_ more
often than every 24 hours (24 hours is the Windows 7 default for changing the
host's privacy address, per my understanding).  Changing them more often,
without coordination with the application, is *very difficult* without
breaking the application.  For example, if the OS decides to change the IPv6
privacy address during a long-lived FTP session transferring thousands of
files, new FTP data connections have to continue using the old address until
the FTP control connection is closed (reference
http://cr.yp.to/ftp/security.html).  This is an awkward case, but solvable (OS
can determine if a process has other sockets already open) but gets worse with
multi-process applications and gets impossible if the application has a
signaling channel to a server that isn't the endpoint while also
creating/destroying data channels to a remote peer (as is common with SIP,
XMPP, and perhaps things like BitTorrent).

In short:  IPv6 privacy addresses need more fleshing out before they are
equivilent substitutes for today's NAPT44.

-d

---

From: Chris Engel <[email-masked]>
Date: Mon, 3 May 2010 16:07:27 -0400

Fred,

I was not trying to hijack your discussion here. If that was the end result, then I apologize profusely.

If you note, I don't post to this list very often (doesn't seem to be all that active anyway). However, since it is titled "NAT66", I think it isn't particularly harmful to interject once every 6  or 12 months that not everyone is looking for the same flavor of solution of NAT66 that is being discussed here.

More specifically to the point, I think the current discussion originated from the idea that there wasn't going to be any concept of "Realm" similar to that which exists in IPv4, under an IPv6 network...... that the entire IPv6 internet was going to be one big "realm". I just was trying to point out that I didn't believe that was going to be necessarily true in practice...even if it was what some people might desire.

Christopher Engel

> Sent: Monday, May 03, 2010 3:39 PM
> To: Chris Engel
> OK, so for your usage case, you want the exact concepts in
> IPv4/IPv4 NAT re-implemented in an IPv6/IPv6 world. Got it.
>
> > On 10,000 ft level, I think that the real success story of the
> > internet is that it allows for a wide diversity of usage cases and
> > supports organizations with a wide diversity of goals. If
> it's going
> > to continue to be successful in future, I think it will need to
> > continue to support such diversity of goals/usage. Those
> goals/usage
> > cases don't have to be compatible with each other. In fact, I think
> > that would be an unachievable goal. However, I believe
> there needs to
> > be room for all of them to continue to exist on the Net.
> >
> > I really don't have any problem with anyone who values "end-to-end
> > transparency" as their goal for their OWN usage case of the NET. I
> > have a big problem when some-one is trying to tell me that
> goal MUST
> > apply to my usage case as well, whether I want it to or not....and
> > then work to retard any public standards being published which
> > describe how my desired goals might be enacted.
> >
> > For example, peer to peer networking is pretty much
> anthetical to the
> > standards that my organization embraces. That being said, I
> have never
> > had a problem with anyone attempting to publish protocols involved
> > with peer-to-peer applications. The end result of such publication
> > might even make peer-to-peer applications more
> popular...which could
> > even increase MY workload in attempting to prevent
> unauthorized use of
> > such applications on my network. However, I've never seen that as a
> > justification for my attempting to interfere with the
> publication of
> > such standards. I'm pretty sure that the authors of such
> protocols are
> > attempting to provide a solution for people who WANT to
> embrace it...
> > not make the lives of people who don't more difficult....
> even if that
> > is part of the effective result.
> >
> > If you or Keith or others don't see the value in the kind of NAT
> > solution that I want to use, that's fine. I can't make you
> see it if
> > you don't want to do so. If Cisco or Apple or whoever don't want to
> > sell that sort of equipment for IPv6 that's fine as well. All that
> > will do is limit the market segment to which you can sell your
> > products. It's a free market economy, if you don't offer such
> > solutions, I'm pretty sure if there is a strong economic demand for
> > them (which I believe there will be) that those of us who strongly
> > desire such solutions will eventually find a vendor willing to fill
> > that demand and accept our cash. All that is really happening right
> > now without that is another factor slowing wide scale adoption of
> > IPv6.
> >
> > I think on the very first exchange of e-mail I had with Margaret, I
> > mentioned that this particular proposed implementation of
> NAT66 didn't
> > sufficiently cover my usage requirements. However, I was
> happy to see
> > it brought forward, as I definitely could see how it might prove
> > useful to certain usage cases. From my perspective, the greater
> > variety of options available the better.... and having
> publication of
> > standards for those options is better then not having them.
> >
> > My purpose here is simply as a reminder that there is a large user
> > segment that is currently under represented in discussions taking
> > place on the subject of NAT in IETF and certain other
> venues.....and
> > that indeed there is VERY far from universal agreement on
> the goals of
> > end-to-end transparency or reachability. In essence, I'm
> attempting to
> > provide a counter-point for those who consider such goals as an
> > apriori that everyone is going to be willing to embrace.
> >
> >
> >
> >
> >
> > Christopher Engel
> >
> >> I would agree that many in the IPv6 community disagree with your
> >> goal. Their fundamental objective is end to end transparency, and
> >> your fundamental objective is end to end opaqueness. You disagree
> >> with each other. I understood from your previous emails in this
> >> thread that you felt they were "wrong" or that you felt that they
> >> felt you were "wrong"; I don't think either is "wrong" per se, but
> >> you certainly disagree.
> >>
> draft was
> >> particularly unfortunate, and said that to Margaret when I
> agreed to
> >> co-author. Since we are talking about something fundamentally
> >> different than IPv4/IPv4 NAT, we have the same issue that has been
> >> discussed with the term "realm". We wind up with this discussion,
> >> which is not a stupid discussion, but is off topic with respect to
> >> the proposal in question. When the IETF had a BOF on the
> topic, that
> >> was incredibly clear. We had a proposal on the table which was
> http://www.ietf.org/rfc/rfc4864.txt, some
> >> strong proponents of the transparent model addressed what they
> >> thought were the primary reasons for the use of NAT. They didn't
> >> cover this one, so to speak. But it might be worth your while to
> >> The goal of those that would like to not have any
> translation at all
> >> - here, Keith, I'm putting words into your mouth, so
> please feel free
> >> to correct them - is essentially the counterpoint of that.
> The world
> >> is poorer for the applications that have not been developed due to
> >> firewall and NAT boundaries, and they would like to be
> able to build
> >> For my part, and the part of this proposal (and the ILNP proposal
> >> that RRG is putting forward), I am all for the free development of
> >> useful applications. I don't see the value of NAT, given
> its history
> >> of not stopping attacks and of preventing applications. I see a
> >> problem that needs addressing though, related to management of the
> >> backbone route table. In short, we now have O(10^5) prefixes in the
> >> In the area of addressing, networks at the edge are
> pushing back very
> >> hard on the provider-allocated addressing model, and are
> driving for
> >> provider-independent addressing. Reason: they don't want to be
> >> captives of their providers. I'm sympathetic with them.
> But consider
> >> the implications: if they all have PI addresses, we are
> enumerating
> >> the objects at the edge, and even today we have O(10^7) or more
> >> objects at the edge. PI addresses take us in the direction
> of a swamp
> >> at least as bad as that in the IPv4 network. Service providers
> goals of all
> >> of the players. I obviously can't both lock and unlock
> customers, so
> >> whatever I do is wrong there from someone's perspective. But by
> >> Network Prefix Translation, the subject of this list, I
> can give edge
> >> networks the appearance of PI (they are independent of their
> >> providers for
> >> addressing) and the service providers the appearance of PA (they
> >> enumerate the ISPs at the edge, O(10^3 to 10^4) instead of
> objects at
> >> the edge, O(10^5, 10^6, or 10^7)). The boundaries are
> >> address-translucent, not either transparent or opaque, so while I
> >> don't give you what you want I give you something a step in its
> >> direction. And I give Keith what he wants - if he can find
> it in his
> >> heart to have applications use names instead of addresses, he gets
> >> all of the access between applications that he needs. And
> for those
> >> that operate networks, it reduces their capex and opex. It

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 May 2010 09:28:33 +1200

On 2010-05-04 07:34, Darrel Lewis wrote:
> Shim6 is very different from LISP.  Shim6 is implemented in the host, and LISP in the CPE router (like, for example, NAT66 would be).  Shim6 seems to have more in common to ILNP than LISP.

That's true if your helicopter is hovering at about 250 metres.
But if you take it up to half a kilometre, all these solutions
are isomorphic, in the sense that prefixes for multimhomed sites
are no longer visible in BGP4; whether they are eliminated
in the host or at the ISP ingress doesn't matter to the core.

The one property that separates stateless NAT66 (which is not NAPT)
from shim6, ILNP and LISP is that the end to end address as seen by
transport protocols gets changed.

However, I agree with Fred: on *this* list we should talk about
draft-mrw-behave-nat66. We could start with a naming competition.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 May 2010 23:13:55 -0400

> On 10,000 ft level, I think that the real success story of the internet is that it allows for a wide diversity of usage cases and supports organizations with a wide diversity of goals. If it's goin…
I agree so far.
> I really don't have any problem with anyone who values "end-to-end transparency" as their goal for their OWN usage case of the NET. I have a big problem when some-one is trying to tell me that goal…
The thing is, the end-to-end transparency of the core network is the
primary feature of the Internet that allows "the wide diversity of usage
cases" that you find valuable. 

But few of us get to connect directly to the core network, so it's not
just the transparency of the core network that matters.   When
enterprise networks and consumer ISPs don't also support end-to-end
transparency, the Internet loses its ability to support that "wide
diversity of usage cases".

Now you may say that you have a right to do what you will with your own
network, and you're correct about that.   But as a practical matter, the
large numbers of networks that have NATs in between themselves and the
core Internet have crippled the ability of the Internet to support a
wide diversity of applications.

And yes, security is an important issue.   But as compared to a stateful
firewall, the additional security provided by NATs is very, very
marginal.   Furthermore, valuable security tools to do intrusion
detection and packet tracing are hampered by NATs.   And the firewall is
much more flexible than the NAT in allowing the site to tailor its
security policy to support the applications it wants to support and
block the applications it wants to block.   NATs don't give you
flexibility at setting security policy, they take it away (unless you
have some silly idea that a security policy should act like a NAT).

IETF doesn't tell people what to do with their networks.  There are no
jackbooted network police with black helicopters that follow IETF's
bidding (though that would be cool...just kidding).   What IETF does is
essentially to provide advice of the form "if you implement things this
way, they should work well". 

What we know from around 15 years of experience is that NATs -- at
least, NATs like we've had in IPv4 -- do not work well.    They hinder
the ability of the network to support applications.  The applications
that do manage to work in the presence of NATs become more expensive,
more complex, less reliable.  They provide an illusion of increased
security while actually degrading it.

So while people can continue to do what they want with their own
networks, it would be irresponsible of IETF to recommend use of NATs in
IPv6 unless a valid use case for use of NATs were known.  And after 15
years of experience with IPv4, the only convincing use case for NATs has
been to slow down the consumption of IPv4 addresses.   That's it.  Until
we have a looming address shortage in IPv6, there's no proven
justification for using NATs in IPv6.

(I consider the jury still out for the nat66 proposal.   I understand
why people want it.  I think there are better ways to skin that cat. 
But I think the question boils down to this: Who gets to feel the pain
of solving the routing scaling problem?  Should the users and
application developers feel the pain, or should the enterprise network
operators feel the pain, or should the carrier networks feel the pain? 
And because users and application developers are less-well represented
in IETF, there's a lot of pressure to put the hurt on them.   Nobody
sees it that way, but that's the effect.   The people doing routing want
it to be Somebody Else's Problem so it will go away.  I don't blame
them, but the truth is, the problem doesn't go away just because you
give it to somebody else.)
>
> For example, peer to peer networking is pretty much anthetical to the standards that my organization embraces.
I don't know what standards your organization embraces, but to me that's
a really bizarre statement.  Why should any organization care about the
pattern of communication between parties in an application, unless
you're doing traffic analysis?  What is inherent about p2p that makes it
less deserving of support from the network?
>  That being said, I have never had a problem with anyone attempting to publish protocols involved with peer-to-peer applications. The end result of such ple or whoever don't want to sell that sort of equipment for IPv6 that's fine as well. All that will do is limit the market segment to which you can sell your products. It's a free market economy, if you don't offer such solutions, I'm pretty sure if there is a strong economic demand for them (which I believe there will be) that those of us who strongly desire such solutions will eventually find a vendor willing to fill that demand and accept our cash. All that is really happening right now without that is another factor slowing wide scale adoption of IPv6.
There's also a strong market demand for methamphetamine.  Should IETF
promote that as well?  Seems like NATs in IPv6 and meth have something
in common - both provide the illusion of a benefit while actually doing
considerable harm.   And both have their proponents who are in denial
about the harm that they cause because they can only see the
money-making potential.
> I think on the very first exchange of e-mail I had with Margaret, I mentioned that this particular proposed implementation of NAT66 didn't sufficiently cover my usage requirements. However, I was h…
In general, the existence of too many standards in the same space, or
standards with too many options, hinder interoperability rather than
enhance it.
>
> My purpose here is simply as a reminder that there is a large user segment that is currently under represented in discussions taking place on the subject of NAT in IETF and certain other venues.....and that indeed there is VERY far from universal agreement on the goals of end-to-end transparency or reachability. 
You're correct about that.  Applications developers and end users are
grossly under-represented in IETF, and have been so ever since the mid
1990s.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 May 2010 23:59:35 -0400

On 5/3/10 2:21 PM, Fred Baker wrote:
>
> Personally, I think the term "NAT" in the moniker for this draft was particularly unfortunate, and said that to Margaret when I agreed to co-author. Since we are talking about something fundamentally different than IPv4/IPv4 NAT, we have the same issue that has been discussed with the term "realm". We wind up with this discussion, which is not a stupid discussion, but is off topic with respect to the proposal in question. 
Well, nat66 *is* a NAT in the literal sense - it does address
translation.  But the nat66 draft appeared at about the same time that
people were starting to use natXY (or NATxy) as a general notation for
NATting between two addressing realms, and it's always been a bit
confusing that "nat66" was supposed to mean a specific proposal while
other usages of natXY were not specific proposals.  So it's not
surprising if the nat66 group has attracted discussion broader than that
proposal.  And there's no obvious other place to discuss other proposals
for NAT between v6 and v6.

(In hindsight, the best use of the nat66 name would have been as a
discussion group equivalent of the Golgafrincham B Ark.  Seriously.)

The other problem is that we've come to associate several things with
NAT that were not, strictly speaking, inherent in address translation,
e.g: port translation (NAPT), automatic implicit assignment of bindings
within the NAT based on heuristics and observed traffic, lack of
fate-sharing between the NAT and its endpoints, etc.  But there have
always been various kinds of NAT even in IPv4, and we never minded using
the term NAT to apply to all of these.  It's just that the more common
NAT44 configurations involved all of these, so we tended to use "NAT" as
a shorthand for the most common case.

So I do think that associating the nat66 name with a specific proposal
was unfortunate.  But even if the name were to be changed, it would
still need to have the word "NAT".  It still involves address
translation, and it still has some of the issues associated with address
translation, and the discussion needs to attract people who care about
those issues.

> The goal of those that would like to not have any translation at all - here, Keith, I'm putting words into your mouth, so please feel free to correct them - is essentially the counterpoint of that.…
That's an accurate reflection of my view.
> From my perspective, I would like to achieve some of the goals of all of the players. I obviously can't both lock and unlock customers, so whatever I do is wrong there from someone's perspective. But by Network Prefix Translation, the subject of this list, I can give edge networks the appearance of PI (they are independent of their providers for addressing) and the service providers the appearance of PA (they enumerate the ISPs at the edge, O(10^3 to 10^4) instead of objects at the edge, O(10^5, 10^6, or 10^7)). The boundaries are address-translucent, not either transparent or opaque, so while I don't give you what you want I give you something a step in its direction. And I give Keith what he wants - if he can find it in his heart to have applications use names instead of addresses, he gets all of the access between applications that he needs.
Maybe I've missed it -  I'm certainly not in the loop as much as I used
to be.  But so far, I've yet to see a name mapping system that is fast,
secure, reliable, scalable, location-independent, and with enough
support behind it that it will get widely deployed.   Frankly, I have no
idea how to build such a thing.  But until we come up with such a naming
system, we're not solving the routing scalability problem - at best
we're just moving it, and we could be replacing a merely very difficult
problem with an intractable one.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 May 2010 00:09:59 -0400

On 5/3/10 3:46 PM, Dan Wing wrote:
> host's privacy address, per my understanding).  
As an application developer, what I really want for privacy addresses is
to be able to use a different source address for every outgoing
connection, and to not hold on to that address-to-interface binding any
longer than needed to do FIN-ACKs (or equivalent for other transport
protocols) on that connection.    I want the host to keep a pool of
available addresses to use for privacy addresses, allocate more from the
local network when the pool goes below a threshold, and free old
addresses up when they're no longer needed.

I want to be able to specify, on a per-connection basis, whether (a) the
source address should be a privacy address and (b) whether the host
should accept connections at that address.

It doesn't work nearly as well to reuse a privacy address across
multiple connections, because you never know how long an app will need
to use that connection.

But since you said 24 hours isn't short enough (and I pretty much agree)
- do you think that typical NAT44 internal-to-external address binding
times /are/ short enough?  My impression was that most NATs would
maintain such bindings indefinitely as long as there were active
connections using them.

Keith