Subject: RE: Please move this thread to BEHAVE mailing list ... Was Re: [BEHAVE] Lack of need for 66nat : Long term impact toapplicationdevelopers

From: "Tony Hain" <[email-masked]>
Date: Mon, 1 Dec 2008 11:30:41 -0800

Cullen Jennings wrote:
> I'm sure that the IAB and IESG is keenly interested in this topic but
> everyone that cares is subscribed to behave. 

While I agree that everyone interested in defining nat behavior is
subscribed to Behave, I doubt that everyone in the application community is,
yet every one of them will be impacted by the fundamental architectural
implications of this backroom rush to market effort. There has been no
justification of the need for a 66nat, only wild claims that we need to do
something now because people will be shipping them in the next few months.
While I have no doubt that vendors will ship what their customers are asking
for, it is not clear that the IETF should endorse an effort with such a wide
ranging architectural impact. Never mind that if the vendors are really
shipping in the next few months there is no chance that an IETF document
would be published before there are products on the street....

Hosting this discussion in Behave assumes the outcome, and is absolutely the
wrong place for an architectural discussion. This should be held in the
Applications area, and only moved to Behave to resolve the implementation
details once it is decided that a 66nat is absolutely necessary. Trying to
do it by having people pre-disposed to an answer and without any concern for
the impact to the application community is guaranteed to result in
perpetuating an unnecessary architectural wart.

Tony

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Dec 2008 15:52:05 -0500

> perpetuating an unnecessary architectural wart.

Mumble.  As usual in IETF when we are talking about issues that have a
profound effect on the architecture, the discussion is fragmented.

- The greatest concentration of NAT experts in the IETF are probably in
the BEHAVE group.  They do have a NAT-centered view of the
problem/solution space.  But don't discount them entirely, as many of
the participants in that group have a deeper grasp of the implications
of NAT (at least when viewed from that angle) than the average IETF
participant.

- Some of the pressure to have NATs (other than for IPv6 transition)
seems to be coming from routing area people who can't figure out how to
make the core routing scale, so they want to push part of the problem to
the edges.   So clearly we need input from routing people.

(I'm not saying it's an inherently unreasonable approach, though
sometimes I do wonder if it smacks of "let's make this somebody else's
problem so we don't have to deal with it".  And BTW, no area has a
monopoly on this kind of wishful thinking.)

- Other pressures to have NATs are from network operators who see it
(and not entirely without justification, though in some cases it's
marginal) as something that helps their security and/or decreases their
management effort in the face of (a) renumbering and/or (b) reducing
granularity of access control.  So we need input from operations people
also, though it's not clear (to me anyway) how well those people are
represented in IETF.

- And of course we also need input from applications people.  But
historically most IETF standard applications protocols have not been
peer-to-peer or distributed apps.  So IETF applications area people (in
general) may actually not be adequately sensitive to the needs of apps
outside of the two-party (i.e. client-server) space.  This implies that
moving this discussion to an apps area group would not automatically
bring with it a lot of clue about how NATs affect apps.    But we
certainly need input from people with distributed / p2p apps expertise.

--

I haven't followed IETF as closely for the past few years as I did for
the decade or so before that.  But in the past it used to be the case
that ADs would deliberately narrow the scope of some of these
discussions to avoid endless ratholes in discussion between people who
could never learn to speak the same language, or respect one another's
experience or needs.  I don't know if that tactic is still being used,
but my impression from some distance is that IETF is even more
fragmented about architectural issues (particularly use of NATs) than it
used to be - though today it seems that a bit more of the NAT discussion
is coalescing in BEHAVE than it was, say, a year ago.  And having the
discussion in a single WG is IMO far better than having a half-dozen
different groups all trying to solve more-or-less the same problem, from
narrow points-of-view, in relative isolation from one another.

I guess what I'm concluding is this:  Yes, we need to have input from
all of these different kinds of people.  Yes, the BEHAVE group has a
NAT-centric view.  But unless we can find some way to get a more diverse
set of interests into the same (virtual) room AND get them to actually
speak the same language and respect one another's views, moving the
discussion elsewhere isn't going to help convergence of any kind of
solution - with or without NAT.

But IF the discussion is going to happen there, what I'd really like is
for the BEHAVE group to stop trying to enumerate and define in detail
every possible solution to the NAT problem -- and instead focus on
developing a single, common framework that would let NATs provide the
functionality and visibility that both applications and operators need.

If they were to take that approach, I think they could do a decent job
at defining the "Optimal" NAT and also enumerating its warts.  And then
the rest of us could look at it and see how bad (or tolerable) it really
is.  And the routing people could look at it and see if it's really
possible to use NATs to handle multihoming to stub networks, without
painting the internet architecture into an undesirable corner.

(Because at present the "we need NATs for routing" argument looks, to my
intuition, a bit like handwaving.   And I am not convinced that the
proponents of using NATs to simplify the routing problem really
understand the implications of doing that, either for the applications
or for the internet architecture in general. But I do think that it's
worth exploring that, and that the proponents of this approach need to
be able to make the best case they can for it.  And in order to do that
they really need a definition of "optimal NAT" to work with.)

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Dec 2008 12:02:25 +1300

Keith,

With some reluctance, I have't changed your cc list. But
my conclusion is that this particular discussion belongs
on the RRG list as much as anywhere.

On 2008-12-02 09:52, Keith Moore wrote:
...
> intuition, a bit like handwaving. 

I don't think that is quite the argument. It is more like this:

1. We know of no alternative to a longest-match based approach to
routing lookup for the inter-AS routing system (commonly known
as the DFZ).

2. To control the long-term scaling of that approach, we need to
control the long-term size of the lookup table and the long-term
rate of dynamic updates to that table.

3. We assume there will be continued unbounded growth in the
number of sites requiring multihoming, but today each site that
requires multihoming thereby requires its own entry in the DFZ
lookup table. In the long term, this is unsustainable.
[Digression about numbers and dates omitted.]

4. The known solutions to this all require some mechanism for
aggregating site prefixes into ISP prefixes. [There's space for
a digression about the related advantages of separating
the transport ID from the network address, and about the
application layer's view of all this, but that doesn't
affect what I just said.]

5. One solution to that is a multi-prefix model (a site runs
multiple prefixes), which is of course the IPv6 design assumption.
Another solution is a map-and-encap model. A third solution is
a map-and-translate model. There are many variants of all these
models, but I don't know of a fourth one. All solutions have
advantages and disadvantages.

IMHO the reason we're hearing about NAT66 is because people
still find the IPv6 multi-prefix model unfamiliar and there is
no consensus-based map-and-encap solution yet. So it's natural
to look at map-and-translate, and NAT66 is one of the solutions
in that category.

    Brian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 1 Dec 2008 17:47:07 -0800

> [Digression about numbers and dates omitted.]

This does not necessarily follow ... Even so, we could easily scale a couple of orders of magnitude from the existing number of multihomed edge networks, so they aren't the problem. The fundamental problem with route scaling is that people choose to pollute the system to do rudimentary traffic engineering with BGP. 

> aggregating site prefixes into ISP prefixes.

BS... Containing the size requires aggregation, but ISP based prefixes is a choice rather than a requirement.

> [There's space for
> models, but I don't know of a fourth one. 

Choosing to ignore Geo approaches does not make them go away. Yes that means that topology would have to follow routing rather than the other way around, but that could be done at a global scale with regional deaggregates where routing follows topology and the result would be carving up the scaling problem to whatever size ISPs could get routers to support. 

> All solutions have advantages and disadvantages.

True enough, and geo requires the ISPs to consider something besides local optimization at a cost to the entire rest of the world. These are all trade-offs...

> to look at map-and-translate, and NAT66 is one of the solutions

While that is somewhat true, the majority of the reason has been clearly stated by the proponents: Vendors are building 46/64, and will be throwing in 66 just because they can. There has been no outcry from the masses trying to deploy IPv6, it is strictly vendor driven because they want something they can point to as justification for building something that is totally unnecessary. 

Tony

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 1 Dec 2008 19:20:37 -0800

Fair Enough. I was not thinking of the behave mailing list as  
presuming the answer but I see your point.

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Dec 2008 23:37:04 -0500

> advantages and disadvantages.

Nice summary.  I mostly agree with all of the above.

> to look at map-and-translate, and NAT66 is one of the solutions

I don't think it's just that the multi-prefix model is unfamiliar.
There's plenty of reason to believe that it won't work well. Static
address selection rules, no way for hosts to know which prefixes will
work better, inability of most existing transport protocols to fail over
 to alternate addresses.  I won't claim that the problems can't be
fixed, but I don't think they're solved problems yet - so this looks
like moving a problem rather than fixing it.  And it also blurs the
division between the network's responsibility and the host's
responsibility, which doesn't seem like a good thing.

Regarding map-and-translate: To me it seems important to make a clear
distinction between the case where a network at the edge uses a NAT to
translate between "private" addresses (e.g. ULAs) and PA addresses
(which is what I understand NAT66 to be); and the case where there
address translation is done by routers at the edge of the network core
in order to efficiently transmit packets through the network, and the
inverse translation is done when the packet exits the core so the packet
as received has the same source and destination addresses as the one
sent.  Even if the hardware required to do the two kinds of translation
is pretty similar, the impact on applications is very different.  I
don't think the latter would have much effect on apps at all, though it
would affect diagnostic tools.

It would be really interesting to try to evaluate each of multi-prefix,
map-and-encap, and map-and-translate according to (a) how much each
approach affects applications and hosts in general, and (b) how
deployable each approach is - where deployability has a lot to do with
having the parties that benefit most (probably those that want to
multihome) being the ones that bear the additional cost, and having the
benefit be worth the cost.

Keith

---

From: David Morris <[email-masked]>
Date: Mon, 1 Dec 2008 22:05:51 -0800 (PST)

> benefit be worth the cost.

A key analysis point needs to be diagnostic support.. how hard any
individual approach will be to support is in my mind a significant part of
the deployability cost analysis.

Dave Morris

---

From: Keith Moore <[email-masked]>
Date: Tue, 02 Dec 2008 01:21:41 -0500

> the deployability cost analysis.

agreed. absolutely.

and to address Brian's point from a few messages back that maybe this
should be discussed in RRG instead of among the current set of
recipients - does RRG have any established evaluation criteria like
these, with which to compare potential solutions?  if not, why not?

Keith

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Dec 2008 11:01:21 +0100

> perpetuating an unnecessary architectural wart.

Tony,

We had quite some discussion in IESG about where to discuss this topic.
There is no perfect fit. I think it is time to move it from Behave to
its own list as the discussion continues to go on and impacts Behave's
chartered work. However, the issues as you say is that it is an
architectural discussion and it affects all layers from routing up to
application. Which means that we need insights from all layers. But, we
can't continue to have a good discussion by cross posting to all area
list or the [email-masked] list.

Also be certain that we haven't decided anything about what to do with
NAT66, except saying that we are allowing the discussion. There will be
a BOF before anything if any is chartered on this topic.

Cheers

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: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2008 11:57:07 +0100

On 2 dec 2008, at 5:37, Keith Moore wrote:

> to alternate addresses.

One way to fix that would be multipath transport protocols. Rather  
than try to guess what works best, just use all of them (or at least  
several) and get better performance without having to make difficult  
choices.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dan York <[email-masked]>
Date: Mon, 1 Dec 2008 17:27:56 -0500

I would suggest that there is at least one other block of people who  
are missing from the list of stakeholders in the "To NAT or not to NAT  
in IPv6" discussion that Keith Moore listed:

On Dec 1, 2008, at 3:52 PM, Keith Moore wrote:

> the BEHAVE group.  <snip>
> seems to be coming from routing area people <snip>
>
> - Other pressures to have NATs are from network operators <snip>
>
> - And of course we also need input from applications people.  <snip>

.... namely:

- The system/network administrators and network architects at  
companies/enterprises who are managing and deploying enterprise  
networks.

I don't know how well this particular group is represented within the  
IETF.  I know there are some people from that group at IETF meetings  
because I've met a few. But only a few. My sense from interacting with  
a good number of them over the past 10 years or so is that they are  
probably way too busy dealing with their networks to be involved with  
what goes on here inside of the IETF.  In fact, in some conversations  
over the years where I brought up the IETF with some folks in the sys/ 
netadmin space, the IETF (if it was known, which was not always the  
case) was this vague amorphous body out there "making standards".  But  
that was it.  Relevance of the IETF to their daily job was viewed as  
slim to none.

Now this group is also the group setting up enterprise networks,  
allocating IP addresses, deploying infrastructure, etc.

And they pretty much all use NAT.  And the ones I've talked to all  
*like* NAT.

Sure, they have to use NAT with IPv4 in many/most network situations,  
but I've known of companies with large IPv4 address blocks  
(unfortunately the names escape me right now) who *chose* to use NAT  
and RFC1918 addresses and to not use much of their large IPv4 blocks  
internally.  Why?

Control.

As has been pointed out by others in this thread, there is immense  
value to a company/organization/entity in maintaining control over  
their IP addresses.  They are not locked into their current ISPs...  
with a sufficient amount of randomness they can hopefully easily  
integrate with other acquisitions... they don't have to renumber,  
etc., etc.... the various reasons people have pointed out.

I personally don't see them ever giving up NAT.

Oh, we can point out how broken it makes their networks... we can  
point out how IPv6 apps will work so much better without NAT.... we  
can point out how ULA and RFC 3484 make NAT unnecessary.

Some will listen.  Some will use ULAs and put in place the appropriate  
routing policies, etc. to make it all work.

Others - and I personally think it will be *most* - will simply just  
NAT their IPv6 network just exactly like they did for their IPv4  
network.  Why?

Because it's simple and easy and **that's what they know**.  They  
maintain all the control they want.  They have even fewer external IP  
addresses to think about (just the ones on the NAT boxes).  Many view  
NAT as part of a security plan with topology-hiding, etc. (And yes, we  
can argue debate that point endlessly, too.)  To them, it makes their  
lives simpler, reduces the workload they have, etc., etc.

We can argue that they shouldn't think this way... that with IPv6 they  
have a new and better way to do things... but these are the same folks  
who are just-trying-to-keep-their-networks-running-while-not-having- 
their-jobs-outsourced-as-their-budgets-are-being-cut-and-they-just- 
want-to-keep-things-stable-while-the-idiot-on-the-second-floor-keeps- 
losing-their-system-password-and-the-turkey-on-the-third-floor-has- 
somehow-deleted-their-critical-document-for-the-zillionth-time-and-the- 
marketing-people-want-web-2.0-apps-implemented-yesterday-and-the-CFO- 
is-demanding-better-realtime-stats-and-oh-by-the-way-another-company- 
was-just-acquired-and-needs-their-network-to-be-integrated-and-the- 
pager-going-off-at-2am-every-night-this-week-is-getting-really-really- 
old-and....and....and...and...and-now-the-CIO-says-that-we-have-to- 
have-IPv6-addresses-deployed-by-next-month...

I think NAT will go away for these folks when we pry the cold dead  
fingers of the last sysadmin away from the keyboard...

I'd love to be wrong on this, but I think a great number of enterprise  
IT folks actually like NAT and will continue to use it even as they  
move into IPv6.  Our choice within the IETF seems to me to be either  
ignoring it entirely and hoping that somehow all these networks will  
"see the light" and embrace networks without NAT - or alternatively to  
come up with ways that NAT can work in IPv6 spaces (while still  
encouraging people to look more at how to deploy without NAT).

And to return to my original point, I think we need to see if there  
are ways to include more people from the actual system/network admin  
sphere into these discussions.... (unless I'm wrong and that segment  
is already very well represented and I just haven't noticed)...  
because at the end of the day, *they* are the ones who are actually  
going to be implementing (or not) all these standards we create.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Dec 2008 09:46:15 -0800

>several) and get better performance without having to make difficult 

It's not clear to me from the above whether you mean something
like "use SCTP", something like "build ICE-like candidate selection
algorithms into the transport protocols, so that the best path gets
selected", or "run all available transports from all available flow
endpoints for as long as the flow lasts".

Care to clarify?

			Ted Hardie

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2008 19:45:49 +0100

> like "use SCTP",

Note that although SCTP is aware of multiple addresses, it won't  
actually use them concurrently. What I have in mind is a TCP that can  
use multiple paths at the same time. For the purposes of this  
discussion that would have to be a multiaddressing aware multipath TCP  
or a multipath TCP integrated with shim6/MIPv6.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Scott Brim <[email-masked]>
Date: Tue, 2 Dec 2008 13:52:31 -0500

Excerpts from Brian E Carpenter on Tue, Dec 02, 2008 12:02:25PM +1300:
> routing lookup for the inter-AS routing system (commonly known as
> the DFZ).
> 
> 3. We assume there will be continued unbounded growth in the number
> of sites requiring multihoming, but today each site that requires
> multihoming thereby requires its own entry in the DFZ lookup table.
> In the long term, this is unsustainable.  [Digression about numbers
> and dates omitted.]
> 
> aggregating site prefixes into ISP prefixes. [There's space for a
> digression about the related advantages of separating the transport
> ID from the network address, and about the application layer's view
> of all this, but that doesn't affect what I just said.]
> 
> Another solution is a map-and-encap model. A third solution is a
> map-and-translate model. There are many variants of all these

All good but 

> to look at map-and-translate, and NAT66 is one of the solutions

My suspicion is that it's seen as easier to deploy, right now.  Show
me your IPv6 multiprefix deployments, now show me your NAT
deployments.  And NAT66 is just NAT, right?  

Scott

---

From: Scott Brim <[email-masked]>
Date: Tue, 2 Dec 2008 14:02:47 -0500

Excerpts from Iljitsch van Beijnum on Tue, Dec 02, 2008 11:57:07AM +0100:
> One way to fix that would be multipath transport protocols. Rather than 
> try to guess what works best, just use all of them (or at least several) 
> and get better performance without having to make difficult choices.

This doesn't help with site renumbering problems, just endpoint
renumbering.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2008 20:11:53 +0100

On 2 dec 2008, at 20:02, Scott Brim wrote:

>> than

> This doesn't help with site renumbering problems, just endpoint

NAT also helps very little with renumbering. The only thing that it  
buys you is that you don't have to renumber routers and other devices  
that have their addresses configured staticially sitting behind the  
NAT. But routers can receive prefixes over DHCPv6 and then use those  
prefixes to number their stuff rather than have this done by hand, so  
there is _very_ little need for static address configuration.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ralph Droms <[email-masked]>
Date: Tue, 2 Dec 2008 14:31:54 -0500

Iljitsch - I understand the theory behind what you're describing...in  
practice, it's a hard problem to know where all the prefixes are that  
should be changed; worse yet, it's hard to know which prefixes in  
which parts of the configuration should be replaced with new prefixes,  
and which shouldn't be changed.

In theory (where theory == reductio ad absurdum), renumbering is just  
a network and host management problem.  In practice, while SLAAC and  
prefix delegation address some (I'll wager a fairly small percentage;  
for that matter, DHCPv4 addressed the host renumbering problem years  
ago) renumbering problems, most of the places where IP addresses are  
configured were never designed with renumbering or any sort of  
"signaling" in mind, and will be very difficult to automate.

- Ralph

On Dec 2, 2008, at Dec 2, 2008,2:11 PM, Iljitsch van Beijnum wrote:

> buys you is that you don't have to renumber routers and other  
> devices that have their addresses configured staticially sitting  
> behind the NAT. But routers can receive prefixes over DHCPv6 and  
> then use those prefixes to number their stuff rather than have this  
> done by hand, so there is _very_ little need for static address  
> configuration.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Dec 2008 10:55:53 +0100

On 2 dec 2008, at 20:31, Ralph Droms wrote:

> Iljitsch - I understand the theory behind what you're  
> describing...in practice, it's a hard problem to know where all the  
> prefixes are that should be changed; worse yet, it's hard to know  
> which prefixes in which parts of the configuration should be  
> replaced with new prefixes, and which shouldn't be changed.

It doesn't have to be if it's designed for this. I know a few years  
back Cisco routers had a limited capability in this area:

!
interface Ethernet1
  ipv6 address autoconfig
  ipv6 dhcp client pd dhcpv6prefix
!
interface Ethernet2
  ipv6 address dhcpv6prefix 0:0:0:A0::/64 eui-64
!

(The prefix is put in the variable "dhcpv6prefix" which is then ORed  
with the prefix 0:0:0:a0::/64 later.)

Seems to me this can easily be extended to all places where addresses  
appear.

But note that I was specifically addressing the presence vs absense of  
NAT in relationship to renumbering. All the difficult stuff is other  
people not directly under your control having pointers to your  
addresses, this is the same with or without NAT.

> most of the places where IP addresses are configured were never  
> designed with renumbering or any sort of "signaling" in mind, and  
> will be very difficult to automate.

Right, so vendors need to step up.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 2 Dec 2008 11:30:49 -0800

There are really two separate questions here:

1) Should application developers write protocols that make assumptions as to the Source/Destination IP headers remaining constant end to end?

2) Should NAT66 be prohibited in order to allow such assumptions to be made?

And then there is the question of what NAT66 should look like if it existed which folk can take to BEHAVE.

>From the application protocol developer point of view:

* The existing network does not allow for the assumption to be made
* There is no real benefit to allowing the assumption to be made
* If I see a protocol that makes such an assumption I consider it HISTORIC [as per BCP9]
* If I see a protocol proposal that makes such an assumption I consider it BROKEN [as per PHB]

I really do not see a mass of application developers who are chomping at the bit to develop protocols with this type of assumption. There are folk who want to get around the inbound connection filtering that is a byproduct of NAT. But that is going to remain regardless. We need a means of securely communicating inbound port requests and that needs to be independent of the IP transport and IP address mapping.

Given that there is no demand from the application developers, the second question must fall. The insistence on prohibiting NAT66 is not driven by application developer concerns as has been repeatedly asserted. We know we are going to have to deal with NAT44, NAT64 and NAT46 for the foreseable future. The portion of the Internet where we can assume IPv6-6 to be supported without mapping is negligible and will not be close to a workable assumption for decades.

The reaction to NAT66 is exclusively driven by network layer concerns. It is not an architectural assumption that modern application designs exploit or could exploit if they wanted to. 

If folk want to make a network argument against NAT66 then please go away to BEHAVE. But if we have a case where the applications world is being cited as the source of a requirement and the applications world is saying that it is not so, this is the forum for that discussion.

I suggest that the only circumstance in which this discussion is worth continuing in any forum is if the opponents can identify an application where : 

1) The constant IP address assumption is required for any reason other than enabling an inbound connection to be made.
2) There is no acceptable means of implementing the requirement that does not rely on the assumption

-----Original Message-----
From: [email-masked] on behalf of Dan York
Sent: Mon 12/1/2008 5:27 PM
To: Keith Moore
Cc: 'Cullen Jennings'; 'behaveietforg WG'; 'IETF Discussion'; 'Ned Freed'; 'Eric Klein'; 'IESG IESG'; 'IAB'; 'Fred Baker (fred)'
Subject: Re: where to have the NAT66 discussion (was Re: [BEHAVE] Please movethis thread to BEHAVE mailing list ... )

.... namely:

Control.

My 2 cents,
Dan

---

From: Keith Moore <[email-masked]>
Date: Tue, 02 Dec 2008 14:41:22 -0500

Hallam-Baker, Phillip wrote:
> 1) Should application developers write protocols that make assumptions
> as to the Source/Destination IP headers remaining constant end to end?

no, that's not the question at all.

the question is whether application developers should be able to assume
that the address of a peer as viewed from one location, can be used to
reach that peer from a different location?

and the answer is clearly yes.  but NATs break that.  however, if NATs
adhere to certain rules (e.g. they support hairpinning, and their
bindings are not dependent on external peers' addresses, and they have a
STUN-like facility built in, and internal apps can explicitly request
bindings for the purpose of listening to incoming traffic) and certain
disciplines are imposed on their deployment, then applications can
obtain addresses which have these characteristics.

which might or might not be adequate overall, but it's a lot easier and
more reliable than what can be done with existing NATs in IPv4.

> 2) Should NAT66 be prohibited in order to allow such assumptions to be made?

no, that's not a well-formed question either - because it's not at all
clear that IETF prohibiting NAT66 would have any significant beneficial
effect.

the question is, what can IETF do to
(a) make NATs as sane as possible
(b) discourage NATs as much as possible and
(c) encourage such NATs as are used to be sane ones?

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Dec 2008 17:01:24 -0800

> a BOF before anything if any is chartered on this topic.

I look forward to the announcement about the new list. 

Tony