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

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

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

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

If there is a valid need, yes Behave should make sure we minimize the kinds
of impacts that applications have to deal with. Lacking a valid need,
standardizing 66nat only ensures that applications will have to deal with
these unnecessary topology warts ---forever---. This is ---NOT--- making
things 'better' for applications developers, and end users. Making it easier
for a few product vendors to throw in 66nat while they are doing 46/64 is
not in the long term best interest of the Internet, and therefore the IETF
should not be doing this work. The charter of Behave should be amended to
remove this entire discussion until someone demonstrates that we actually
need a 66nat because there is no way to solve a real problem without it.

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

Tony

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

---

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

On Nov 21, 2008, at 9:39 PM, Tony Hain wrote:

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

Yes, there is a very clear anti-NAT religion that drives a lot of  
thought. It's not clear that any other opinion is tolerated.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

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

Tony,

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

Jari

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

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 22 Nov 2008 14:37:54 -0500

[Dropped the IETF list, because I think we're told the interested  
folks to come to behave.  IAB & IESG, I'd be glad to drop you on  
future messages if you prefer...]

Hi Tony,

On Nov 21, 2008, at 10:39 PM, Tony Hain wrote:
> necessary due to the limited address range,

Actually, I think it's a misconception that the primary motivation for  
the use of IPv4 NAT is (or ever was) a shortage of IPv4 addresses.  In  
fact, I have come to believe that, at least in most enterprise  
networks, the "address amplification" feature of NAT is often a side- 
effect of the decision to use IPv4 NAT for other reasons.

> So far there has not been any valid need documented
> for why a 66nat should exist.

RFC 4864 does a good job of breaking down the needs that have  
motivated network administrators to use NAT in IPv4, and describes how  
the same functionality might be achieved in IPv6.  It is clear that  
some of those needs (such as "address amplification") aren't  
applicable to IPv6.  Some of them (such as "simple security") can be  
achieved in other ways with approximately the same amount of effort  
and cost as deploying NAT.  However, there are other areas (such as  
"topology hiding" and "address autonomy") where the solutions  
described in RFC 4864 would be significantly more complex or costly to  
deploy than NAT.  And there are other areas (such as "subnet topology  
masking" and "site multihoming") where RFC 4864 identifies gaps in  
current IPv6 technology that have yet to be filled.   Even though RFC  
4864 does describe a number of alternatives that meet some portion of  
the requirements that have driven the adoption of IPv6 NAT, deploying  
any significant subset of those alternatives would be _considerably_  
more complex, expensive and time-consuming than just deploying one or  
more IPv6 NAT boxes.

You should also read "Renumbering still needs work" (draft-carpenter- 
renum-needs-work-00.txt), for an explanation of why "address autonomy"  
is still quite important to network administrators to avoid the need  
for renumbering their internal networks.  Using two sets of addresses  
inside the network (ULAs and global addresses) makes configurations,  
management and maintenance of the network more complex, and it doesn't  
make it any easier to renumber the global addresses, although it is  
possible that they will be used in fewer places.

Between them, the two documents listed above do a good job of  
explaining the reasons why network administrators are deploying (or  
planning to deploy) IPv6 NAT devices in their IPv6 networks.

> of impacts that applications have to deal with.

I think that the IETF needs to be _very_ careful to avoid two things  
here:

1) Believing that if we claim that we don't understand why someone is  
doing something, they will stop doing it.

2) Attempting to identify superior architectural choices to IPv6 NAT,  
and expecting corporations or end-users to care about our notions of  
architectural purity enough to bear the costs (in $$, complexity and  
time) to preserve abstract properties of the Internet that do not  
result in any immediate and quantifiable benefits (in $$,  
functionality or time savings) to them.

According to RFC 4864, an enterprise network can get the full benefits  
provided by NAT by doing a number of fairly complex things.  However,  
it doesn't explain why a network administrator would _choose_ to do  
all (or even a significant number) of those things instead of  
deploying one or more NAT boxes.

For folks who don't want to read RFC 4864 right now, it claims that  
NAT can be replaced in IPv6 by doing the following things:

Simple Gateway:
- Use of two sets of addresses (ULAs and Global addresses) throughout  
the network
- DHCP with Prefix Delegation (DHCP-PD) to get Global address prefix
- Configure the source address selection table on every node to prefer  
ULAs for local communication
- In a more complex case, configure local internal routing protocols  
to know about both addresses
Simple Security:
- Use IPv6 privacy address and configure a sort lifetimes for privacy  
suffixes
- Deploy and configure a stateful firewall
User/Application Tracking:
- Use the flow label to collect this information.  Incompatible with  
use of IPv6 privacy addresses, recommended above?
For Privacy and Topology Hiding:
- Use Privacy Addresses to hide Interface Identifiers which can  
identify specific hosts
- Randomize subnet allocations
- If real topology hiding is needed:  Do one of three things:
a) Use host routes in all internal routers
b) Use Mobile IPv6 or another (undefined) tunneling mechanism
 >> With either of the above, accept that you can no longer limit the  
scope of multicast (or broadcast equivalent) traffic
c) Use VLANs to force all internal traffic to bounce off of a single  
router
And
- Configure DHCPv6 for assignment of addresses to the hosts
Address Autonomy:
- No solution described.  Some discussion of why ISPs may renumber us  
less often?
Multihoming:
- Configure multiple sets of Global addresses throughout the network.
- Recognition that there is a technology gap in this area
Renumbering:
- Use DHCP-PD to minimize impacts of renumbering routers and hosts.
- If you can convince your ISP to give you overlapping address  
availability, handle address lifetimes to allow traffic to transition  
from one prefix to the other.
- Manually renumber global addresses that appear elsewhere (ACLs,  
firewall pinholes, etc.), minimized due to internal use of ULAs.

So, do we understand now why they're planning to deploy IPv6 NAT?

Note:  I _do_ understand that NAT has some significant impacts on the  
network architecture, and I do think that we should continue to try to  
identify superior solutions to IPv6 NAT (where "superior" includes the  
notion that they have benefits for the people who have to pay for  
them), and we should try to get those solutions deployed.  It is my  
hope that we will do a good enough job at this (through SHIM6, the  
RRG, renumbering work, etc.) that networks will widely deploy our new  
solutions, thus eliminating the use of IPv6 NAT.  In the meantime,  
though, I believe that administrators will deploy IPv6 NAT, and that  
we can do a lot of good by helping them do it in a more consistent and  
less damaging way.

I think we have a fairly small window of opportunity to offer some  
advice to the engineers who are building IPv6 NAT products, so that  
they will do it better than they might otherwise.
> not aware and voicing their objections to this discussion,

There has been considerable e-mail on this subject on the IETF list,  
and I know that it has been discussed in the IESG and IAB.  We've  
received considerable feedback from applications-layer folks, so at  
least those people are aware of it.  If there are other steps you  
think that Fred and I should take to make the applications development  
community more aware of this work, please suggest them.

Margaret

---

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

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

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

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

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

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

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

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

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

> Making it easier for a few product vendors to throw in 66nat while they are
> doing  46/64 is not in the long term best interest of the Internet, and
> therefore the IETF should not be doing this work. The charter of Behave
> should be amended to remove this entire discussion until someone
> demonstrates that we actually need a 66nat because there is no way to solve
> a real problem without it.

Makes me think...

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

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

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

---

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

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

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

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Fred Baker
> Sent: Friday, November 21, 2008 10:08 PM
> To: [email-masked]
> Cc: [email-masked] WG; IAB; IETF Discussion; IESG IESG
> Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
> application developers
> 
>

---

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

> future messages if you prefer...]

I specifically sent that note to the wide list because I don't think people
appreciate what is going on in Behave. I absolutely agree that working
through details should be limited scope, but as I said at the mic, the broad
community is being impacted here but the WG is not discussing who we are
trying to make things better for ... In the long term, making 66nat
kind-of-work in limited situations is the worst possible outcome for the
application development community, because it guarantees that the boxes will
be deployed forever. On the other hand, having an inconsistent set make it
more likely that people will find the alternative approaches that accomplish
the goal without breaking things. 

As I said before, in IPv4 the nat function had to exist so it makes sense to
make it work as well as it can. In IPv6 it does not need to exist, so making
it work only raises costs around the edge forever.

> > developers

You are listening to the marketing departments. Most organizations can't get
as much address space as they need from the RIRs, so they take what they can
get and use nat to backfill.

> more complex, expensive and time-consuming than just deploying one or

Who sees this as complex and more expensive ??? The application developers
and end users are not being represented in this discussion. Making it easy
to perpetuate a broken architecture lowers the costs for the network
manager, at the much higher cost to the application developer and end user. 

> possible that they will be used in fewer places.

The cost and complexity move around due to the different implementation.
Today there are very complex access control lists to deal with the
overlapped use of one address range for both internal and external access.
That becomes much simpler (therefore lower cost boxes) when the access
control only has to say 'disallow ULA over this interface'. Yes hosts that
need external access will have to get another address, but that can easily
be done through DHCP. This moves the control point from the set of massive
edge devices to a central service. Which is more complex is a local
implementation issue.

> planning to deploy) IPv6 NAT devices in their IPv6 networks.

This is simply justification for the real issue, which is people have sold
nat and don't want to change their marketing story so they need a reference
document to say that the IETF told them to do it.

> doing something, they will stop doing it.

People will do whatever they want to, despite what the IETF says. What will
drive them is their localized costs. The only way to raise the localized
cost for the network manager is to have the pain of dealing with the
application developers and end users be so high that it outweighs any cost
savings of perpetuating the nat silliness. 

> functionality or time savings) to them.

This is not about architectural purity, it is about distribution of cost,
and the more significant impact to application developers and end users
dealing with an unnecessary topology wart. If it were necessary, make it as
good as it can be. Since it is not, make it an indulgence to placate the
laziness of the network manager. 

> deploying one or more NAT boxes.

That was because it made no sense to explain how these were better than a
non-existent technology. The entire point was that people have goals to
accomplish, and they have latched onto IPv4-nat because it was there. They
needed guidance on how to accomplish those goals without a 66nat. 

You have yet to show why we actually ---need--- a 66nat, and just keep
saying that people want one so we have to give it to them. 

> scope of multicast (or broadcast equivalent) traffic

You know there is no broadcast traffic, and there is a clear trade-off
between limiting the scope or unicasting to a topology hidden node which is
true of any tunneling technology.

> c) Use VLANs to force all internal traffic to bounce off of a single

THIS IS ABSOLUTE BS, and you are the one that insisted we put VLANs in the
document. Nodes can be members of multiple vlans, and could select between a
set of exit routers, so traffic does not have to bounce off a single router.
Get real.

> So, do we understand now why they're planning to deploy IPv6 NAT?

Get real... 99.9999999% of people that are asking for 66nat have never read
an RFC, let alone 4864. 

> we can do a lot of good by helping them do it in a more consistent and

Focusing on the small number of people that are impacted as network
managers, while completely ignoring the costs for the application developers
and end users is guaranteed to skew the definition of 'superior'. That is my
entire point, who are we making things better for? The IETF is supposed to
be looking at the architectural impact over the entire system, not reacting
to the whims of those that don't want to learn how to move forward.

> they will do it better than they might otherwise.

Reacting without understanding is the most brain-dead thing we can do. Yes
these developers will build whatever they think they can sell. That does not
mean we need to cave to their whims and define a technology that will have a
perpetual impact amplified around the edges. 

> community more aware of this work, please suggest them.

Taking them off the list of discussing impact and cost was the wrong first
step. Yes technical details are small WG issues, but it is clear from the
words you are using that both you and Fred are focused on the small number
of network managers, and completely ignoring the massive impact to the
larger community of end users and application developers. Raise this
discussion up a level, because we don't need to discuss how to fix the
broken proposed technical approaches when we don't even have a documented
need for the technology to begin with. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Nov 2008 18:39:30 -0500

> it work only raises costs around the edge forever.

I'm not sure a convincing case has (yet) been made that NAT does not
need to exist in any form in IPv6.  If we really believe that, we need
to look at revising RFC 4864 to make a more convincing case (perhaps in
light of new or emerging technology) that it currently does.

Part of the problem, I suspect, is that we as a community have never
developed a shared understanding of either the benefits or the drawbacks
of NAT - especially the latter.  It's a complex picture, so there's a
strong tendency to simplify it in order to try to keep it in one's head.
 And it's easy to do the simplification according to one's preferred
mode of wishful thinking.

I think it helps to view NAT as a symptom of one or more tussles.  Some
of those tussles exist, perhaps, because we don't have good solutions to
certain problems - e.g. core routing scalability or host security.
Other tussles might be inherent - e.g. application writers who want
their applications to see a consistent view of the world (including
addressing of hosts) vs. security personnel who want to obscure the
identity of hosts to increase the difficultly for attackers who want to
target specific hosts.  Articulating these tussles might shed light on
the picture, either by showing us more precisely what problem we need to
solve to resolve a tussle, or by making it clear that in some cases
we're trying to resolve competing concerns that are fundamentally
unresolvable.

But here's what I find myself wondering:  Let's say we did a thorough
investigation into NAT66, decided what it would look like for those
devices to work as optimally as possible, and then looked at the
implications (good and bad) for operators, applications developers, and
users.

1. If we had rough community consensus that there was really no good use
case for NAT66 (no case where the benefits justified the harm done), how
could we best influence the net to discourage their use?  And how
effective could we be at doing that?

2. If we had rough community consensus that the benefits for NAT66
outweighed the harm only in corner cases, how could we best influence
the net to discourage their use except in those cases?  Would
"standardizing" NAT66 (presumably with a narrow applicability statement)
 further that purpose, or is there a better way?

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 23 Nov 2008 20:18:16 -0500

Hi Tony,

> get and use nat to backfill.

I used to work for Wind River, a company with a few thousand  
employees.  According to whois, Wind River has at least three directly  
assigned prefixes: 128.224.0.0/16 (64K addresses), 192.124.127/24 (255  
addresses), 192.103.52/24 (255 addresses), yet the vast majority of  
Wind River's IPv4 network is behind an IPv4 NAT.  In this case, I  
spoke with Wind River's IT people directly about this choice, and I  
know for a fact that as of ~2000, at least, Wind River's primary  
motivation for choosing to use IPv4 NAT was _not_ address space  
shortage.  They used NAT as part of their security architecture and to  
avoid the need to have their ISPs route their /16 prefix.

According to Fred Baker's presentation in behave, Cisco is currently  
using IPv4 NAT in their network.  Using whois, it appears that Cisco  
has at least three directly assigned IPv4 network prefixes:   
64.100.0.0/14 (~256K addresses), 128.107.0.0/16 (~64K addresses) and  
198.133.219.0/24 (255 addresses).  So, it doesn't seem likely that  
Cisco's primary motivation for using NAT is IPv4 address space  
shortage.  According to Fred's presentation, Cisco's IT department has  
also expressed a need for IPv6 NAT, despite the fact that Cisco has  
its own provider-independent IPv6 address block.  So, apparently  
Cisco's IT department has reasons for using NAT that extend beyond  
address space shortage and address independence.  Perhaps you could  
talk to the Cisco IT folks to help us understand why they require IPv6  
NAT?

I have been told of similar choices that are being made by competent  
enterprise network administrators at a variety of companies that range  
in size from dozens to tens of thousands of employees.  I think that  
RFC 4864 does a good job of covering all of the reasons that I've  
heard for why network administrators are choosing to use IPv6 NAT.

I do believe that address space shortage is a primary motivator for  
home users to deploy IPv4 NAT, although home users also benefit from  
the "simple security" feature described in RFC 4864.  I am hopeful  
that the IPv4 NAT in consumer devices will be replaced in IPv6 by a  
stateful firewall that offers greater configuration flexibility than  
the security side-effect of IPv4 NA(P)T.  We know (based on public  
information from Apple) that at least one major consumer gateway is  
including firewall support instead of NAT in IPv6.  Do you have  
information about any others?

> savings of perpetuating the nat silliness.

If I'm understanding you correctly, you _do_ believe that a large  
number of "lazy" enterprise network administrators will choose to  
deploy IPv6 NAT.  However, you believe that the IETF should  
intentionally refuse to develop solutions that work with IPv6 NAT, in  
order to _increase_ the amount of pain that end users will feel when  
they are moved to NAT-based IPv6 networks.  It is your hope that  
things will become painful enough, from the combined pressure of IPv4  
address space shortage and end users screaming about applications that  
don't work on IPv6, that network administrators and ISPs will be  
forced to move to a NAT-free IPv6 network architecture.  Is that right?

Isn't that basically what we tried to do when we refused to  
acknowledge NAT in IPv4?  Why do you think the results will be  
different this time?

> non-existent technology.

Well, that's a problem then, because IPv6 NAT is definitely _not_ a  
non-existent technology.  Please don't confuse "the IETF hasn't  
documented it" with "it doesn't exist".  It's already out there, and  
even you seem to agree that it will be widely available (due to the  
"marketing departments" you mentioned earlier) and widely deployed  
(due to "lazy" network administrators).

> saying that people want one so we have to give it to them.

This and the last quote seem to be where we are out-of-sync...  You  
think that Fred and I are trying to create IPv6 NAT, and that it won't  
exist if the IETF doesn't write a document about it.

We're saying that IPv6 NAT _already_ exists, that network  
administrators are _already_ deploying it or planning to deploy it,  
and that we should try to do what we can to minimize the damage to the  
transport and application layers.
> true of any tunneling technology.

By "(or broadcast equivalent)", I meant to point out that IPv6  
multicast traffic corresponds to both the broadcast and multicast  
traffic in IPv4.  Sorry for being too terse.
> set of exit routers, so traffic does not have to bounce off a single  

When we discussed this document, I pointed out that one good  
architecture for topology hiding might be to run a layer-2 switched  
network, so that there is no layer 3 topology to hide.  I'm not sure  
who provided the rest of the text about VLANs.  I think the text is  
correct, but once you've introduced VLANs, you've reintroduced Layer 3  
topology that you need to hide.

RFC 4864 says "The downside of this approach is that all internal  
traffic would be directed over suboptimal paths via the edge router,  
as well as the complexity of managing a distributed logical LAN."  As  
you point out, there could potentially be more than one edge router,  
but I missed that in my quick summary.  So please mentally change "off  
of a single router" to "off of an edge router" in my text.

> Get real... 99.9999999% of people that are asking for 66nat have  

True, most of the people who deploy IPv4 NAT are consumers, and I  
agree that they don't read RFCs.  It's likely that many enterprise  
network administrators have read some RFCs, but not that they've read  
RFC 4864, specifically.  But, what is your point?

These people want the benefits associated with IPv4 NAT for their IPv6  
networks.  It's unlikely that many of them have worked through all of  
the benefits and determined what they would need to do to recreate  
them without NAT, because they don't have any motivation to create  
them without NAT.  But, even if they knew as much about the subject as  
the aggregate of the RFC 4864 authors (highly unlikely) and could come  
up with the best possible alternatives, it seems extremely unlikely  
that they would choose the alternatives outlined in RFC 4864 instead  
of NAT.

You don't really believe that someone would use host routes throughout  
a large network or deploy MIP6 to avoid deploying an IPv6 NAT, do you?

The people who hopefully _do_ read RFCs are the vendors who implement  
networking products.  If we tell NAT vendors that they shouldn't sell  
NAT products to customers because NATs are "topology warts" that  
stifle innovation and destroy vague principle of the Internet, they  
won't listen to us.  If we tell them to sell products that incorporate  
all of the technologies listed in RFC 4864 instead of selling NAT,  
they'll look at us funny and build NATs based on their IPv4 code.   
They'll just assume that application vendors will incorporate NAT  
traversal, just as they have in IPv4, and that's what the applications  
developers will do.

However, if we tell them an interoperable way to build NATs that will  
cause less problems for their customers, break fewer applications and  
result in less brittleness than IPv4 NAT, they just might listen to  
us...  In fact, I hope that some of them will make an effort to  
communicate to their customers (enterprise administrators and  
consumers) that they want RFC XXXX compliant NATs, and that those  
customers will listen.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Nov 2008 23:18:04 -0500

Margaret Wasserman wrote:
> 
> I used to work for Wind River, a company with a few thousand employees. 
> According to whois, Wind River has at least three directly assigned
> prefixes: 128.224.0.0/16 (64K addresses), 192.124.127/24 (255
> addresses), 192.103.52/24 (255 addresses), yet the vast majority of Wind
> River's IPv4 network is behind an IPv4 NAT.  In this case, I spoke with
> Wind River's IT people directly about this choice, and I know for a fact
> that as of ~2000, at least, Wind River's primary motivation for choosing
> to use IPv4 NAT was _not_ address space shortage.  They used NAT as part
> of their security architecture and to avoid the need to have their ISPs
> route their /16 prefix.
> 
> using IPv4 NAT in their network.  Using whois, it appears that Cisco has
> at least three directly assigned IPv4 network prefixes:  64.100.0.0/14
> (~256K addresses), 128.107.0.0/16 (~64K addresses) and 198.133.219.0/24
> (255 addresses).  So, it doesn't seem likely that Cisco's primary
> motivation for using NAT is IPv4 address space shortage.  According to
> Fred's presentation, Cisco's IT department has also expressed a need for
> IPv6 NAT, despite the fact that Cisco has its own provider-independent
> IPv6 address block.  So, apparently Cisco's IT department has reasons
> for using NAT that extend beyond address space shortage and address
> independence.  Perhaps you could talk to the Cisco IT folks to help us
> understand why they require IPv6 NAT?
> 
> in size from dozens to tens of thousands of employees.  I think that RFC
> 4864 does a good job of covering all of the reasons that I've heard for
> why network administrators are choosing to use IPv6 NAT.

Even assuming that there are sufficient technical mechanisms to do
without NAT in place (and I have reason to doubt that), there's a huge
mindshare (or "religious") barrier to overcome.  I've never talked to an
enterprise network admin who didn't think that NATs were both legitimate
and essential - though when pressed for a reason why, they have rarely
mentioned anything that a firewall couldn't do better.  The fact that
NATs became so widely used in IPv4 (somewhat out of necessity) has
bestowed a kind of legitimacy for NATs in network admins' minds - not
that NAT vendors haven't helped, of course.

At the same time, I've never talked to an enterprise network admin who
had any clue about what it meant to do a systematic security threat
analysis.  Which is not to say that they're completely clueless about
security, but rather, that they would have a difficult time being
convinced that they could actually dispense with a mechanism like NAT.
 (Especially when, if they delete the NAT for their v6 configuration,
and some attack happens, they'll probably be forced to answer to some
superior who knows even less about network security than they do, but
who has been convinced by some vendor salesman that NATs are still the
best thing since sliced bread.)

All that is to say that, from a marketing perspective, it's probably a
lot easier to sell the public on something called "v6 NAT" (even if it
acts fairly differently than "v4 NAT") than it is to sell the public on
the idea that NATs shouldn't be used in v6.

(There's also a reason I called my latest proposal "NAT-XC" rather than
something else.)

As people are surely aware by now, I strongly dislike NATs.  I also
generally think that IETF's job is to describe, in as clear a language
as possible, what it believes will work well -- rather than (e.g.) to
endorse existing practice, or to tell people what they want to hear.

But if our ultimate goal is to promote the continued development,
flexibility, and maintainability of the Internet - then it's possible
that the best path for doing this is to "embrace and extend" NAT and to
do so in such a way that (a) there's a clearly defined standard way for
applications to code around them, and (b) every standards-conforming v6
NAT has built-in mechanisms to aid migration away from it.  For example,

- standardize the functionality in such a way that the firewall and NAT
functions are logically independent, and the NAT can be disabled without
impacting the firewall;

- allow (non-identity) NAT mappings to be enabled/disabled on a per-host
basis, so that NAT can be enabled (when needed) or disabled (when it
gets in the way) on a fine-grained basis...rather than forcing an admin
to NAT or not NAT his entire network;

- a mechanism is built in as part of the standard to allow apps
(multiparty apps in particular) to know their public IP addresses, use
them even "behind" the NAT (hairpinning), explicitly request bindings,
and listen for traffic from outside - provided they are granted such
access and credentials by the network administrators.

And for me this is the clincher:  Unless we can make an airtight case
that v6 NAT is almost never more beneficial than harmful, then I think
it makes more technical sense to define (perhaps, but not necessarily,
standardize) how to make them as harmless as possible (with strong
statements about their limitations and applicability), than to merely
say "don't use them".

Or - to make a slightly weaker case - we at least have to do the
_exercise_ of seeing whether we can make v6 NATs "mostly harmless",
"occasionally beneficial", and provide a path away from them.

If after having done that exercise, we can't convince ourselves that v6
NATs can meet these criteria, we should re-think publishing the
document.  And we shouldn't take on the exercise without being willing
to be honest with ourselves about what we find, regardless of our
preconceptions.

--

I'm of the belief that at least some network admins would turn off v4
NAT today, if they could do so easily and without much apparent risk -
if for no reason than to save themselves from stress and premature
baldness resulting from trying to get B2B apps working across
back-to-back NATs, or from trying to trace flows across NAT boundaries,
or the fragility caused by NATs losing bindings on occasion, or the
difficulties getting P2P apps working, etc.  (Actually I suspect the
combined burden of these on network admins is considerable.)

If a few admins tried to get rid of NATs in v6, and it worked well for
them, the word would spread and others would follow as long as it were
easy to make the change.  It might take a few years, but admins (and
even users, and for that matter IETFers) do learn eventually.  But for
that to happen, we have to give them mechanisms that make it easy for
them to give up NAT _after_ they migrate to v6.   They're not going to
do it _before_ they migrate because you simply can't get rid of NATs in v4.

Keith

p.s. People who have known me for awhile may wonder if, in hindsight,
I've changed my mind about v4 NATs.  The answer is "I don't think so."
I remember arguing, sometime around 10 years ago, that if we were going
to have NATs, that we needed to make sure there was a clear transition
path away from NATs.  The prevailing belief within IETF at the time
seemed to be that the NATs couldn't be changed at all - we'd just have
to work around their deficiencies without touching them.   I strongly
objected to that strategy, and to suggestions that NAT was somehow a
part of the Internet architecture rather than a half-baked hack.  (And
of course, that belief turned out to be wrong as demonstrated by both
UPnP and NAT-PMP.)

Essentially I'm making the same argument for now v6 NATs as I once made
for v4 NATs - we need a transition path away from them.

However I also don't worry about v6 NATs causing the same degree of harm
as v4 NATs have, especially after deprecating site-locals.  A huge part
of the problem with v4 NATs is related to address space scarcity (and
port mapping), and conflicting use of v4 addresses in different realms.

---

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

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

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

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

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

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

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

---

From: "Eric Klein" <[email-masked]>
Date: Mon, 24 Nov 2008 13:07:20 +0200

On Sat, Nov 22, 2008 at 9:37 PM, Margaret Wasserman <[email-masked]>wrote:

> notion that they have benefits for the people who have to pay for them), and
> we should try to get those solutions deployed.  It is my hope that we will
> do a good enough job at this (through SHIM6, the RRG, renumbering work,
> etc.) that networks will widely deploy our new solutions, thus eliminating
> the use of IPv6 NAT.  In the meantime, though, I believe that administrators
> will deploy IPv6 NAT, and that we can do a lot of good by helping them do it
> in a more consistent and less damaging way.
>
Margaret,

I agree with most of your post, so I did not include it in the response. But
I think the last point that you made is the most important reason to not
push your proposed draft at this time. The key line you wrote here is

"we should continue to try to identify superior solutions to IPv6 NAT (where
"superior" includes the notion that they have benefits for the people who
have to pay for them), and we should try to get those solutions deployed."

My concern is that if we put out any draft or RFC on NAT66 now, prior to
working on the "superior solutions" then there is no point in working on
them as NAT will be deployed and will be irreversibly part of the network.

And that would be causing harm in both the short and long run.

Eric

---

From: "Eric Klein" <[email-masked]>
Date: Mon, 24 Nov 2008 13:49:25 +0200

> the idea that NATs shouldn't be used in v6.

This may be a resolution to the whole problem, let's find a solution that
replaces NAT v4 with what will work best (based on needs) and still call it
NAT to make everyone comfortable. This way we all win.

> statements about their limitations and applicability), than to merely
true

> "occasionally beneficial", and provide a path away from them.

But the goal needs to be not destroy the network while meeting the needs of
the various users, carriers, programmers, LAN Admins, etc.

> to be honest with ourselves about what we find, regardless of our

Agreed

Eric

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Nov 2008 13:15:57 +0100

Tony Hain skrev:
> The charter of Behave should be amended to

The BEHAVE charter does not include anything about NAT66 for the moment.
We Area Directors have taken the decision that NAT66 is to be discussed
in Behave for moment. If we find more suitable home for the discussion
we will move it.

I also don't think we are yet ready to make a decision or not of
chartering any NAT66 work. So please let this discussion continue.
Especially the one that brings technical or operational requirements to
the table and help increase our understanding of the benefits and
downsides and potential alternatives.

Best Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

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

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

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

> 2. Is there is a better solution than using NAT

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

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

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

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

Margaret

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Nov 2008 11:10:55 -0500

Eric Klein wrote:

> This may be a resolution to the whole problem, let's find a solution
> that replaces NAT v4 with what will work best (based on needs) and still
> call it NAT to make everyone comfortable. This way we all win.

well, it probably still has to be able to do address translation, at
least under some circumstances.

> But the goal needs to be not destroy the network while meeting the needs
> of the various users, carriers, programmers, LAN Admins, etc.

if it destroyed the network it wouldn't be "mostly harmless" etc.

but we need to also keep in mind that the network exists to run a wide
variety of applications, including those that haven't been invented yet
- and not just web and email and telephony.

Keith

---

From: Rémi Després <[email-masked]>
Date: Tue, 25 Nov 2008 17:17:53 +0100

Margaret,

Time having been insufficient to discuss this subject in
Minneapolis, here is a contribution on how IETF, IMHO, could handle the
NAT66
endorsement or non-endorsement issue.

Regards,

RD

Rémi Denis-Courmont on 11/23/08 9:33 AM:

I just hope that NAT66 is NOT deployed in
access and unmanaged IPv6 networks in any case, and shall stick to
managed/corporate policed networks. That is why I argued for a clear
unambiguous applicability statement to NAT66 should the IETF go forward with
it.

FULL AGREEMENT on this.

It is VERY important that IPv6 users can be sure their IPv6 packets
are NOT stealthily modified within the  network.

PROPOSAL:

"When a packet crosses an IPv6 local/global address space
border in the outbound direction,  a NAT66 mapping IS PROHIBITED IF the
packet contains a
globally routable source address."

NOTE 1:

- This permits NAT66 if the source address is a
ULA (RFC 4193), and the next header field indicates TCP or UDP.

- But this prohibits NAT66 if an IPv6 packet arrives with a
source address that contains the global IPv6 prefix of the customer
site. Thus, in unmanaged networks where the global IPv6 address space
is extended (as  Free customer networks today), IPv6 capable host can
rely on end-to-end  network transparency.

- This also prohibits NAT66 if the outbound packet encapsulated in an
IPv4 packets according to ISATAP (RFC 5214).

NOTE 2:

- This does not say that where NAT66 mappings are "not prohibited",
they
are "recommended": they are just permitted.

-  Indeed, alternative methods are being worked on that are expected to
be superior to
NAT66 because the can   operate statelessly (MW,
RD).

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 25 Nov 2008 17:24:55 +0100

Margaret,

FULL AGREEMENT on this.

PROPOSAL:

NOTE 1:

- This permits to use NAT66 if the source address is a
ULA (RFC 4193), and if the next header field indicates TCP or UDP.

- But this prohibits using NAT66 if an IPv6 packet arrives with a
source address that contains the global IPv6 prefix of the customer
site. Thus, in unmanaged networks where the global IPv6 address space
is extended (like  Free customer networks today), IPv6 capable host can
rely on end-to-end  network transparency.

- This also prohibits using NAT66 for IPv6 outbound packets taht are
encapsulated in
IPv4 packets according to ISATAP (RFC 5214).

NOTE 2:

- This does not say that, where NAT66 mappings are "not prohibited",
they
are "recommended": they are just permitted.

-  Indeed, alternative methods we work on, to get topology hiding and
host privacy,  are expected to
be superior to
NAT66 because of their stateless operation (MW,
RD).

Regards,

RD

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Nov 2008 11:30:22 -0500

> PROPOSAL:
> "When a packet crosses an IPv6 local/global address space border in the
> outbound direction,  a NAT66 mapping IS PROHIBITED IF the packet
> contains a globally routable source address."

I'm not sure this is a good idea.  In particular, I don't want network
administrators to stop advertising global prefixes on their networks
just because they have a NAT installed.  And I think there might be a
case to be made for NATing _some_ hosts on a network but not all of them.

More broadly, I don't really think we can develop an applicability
statement before understanding/deciding what NAT66 looks like.

Keith

---

From: Rémi Després <[email-masked]>
Date: Tue, 25 Nov 2008 17:56:48 +0100

Margaret Wasserman   on 11/24/08 2:18 AM:

We're saying that IPv6 NAT _already_ exists, that network
administrators are _already_ deploying it or planning to deploy it, and
that we should try to do what we can to minimize the damage to the
transport and application layers.

This is IMHO the main reason why alternative designs, like the one you
propose with Fred, and the one I propose, should be called differently,
whatever the chosen name.

Here are some proposals:

SAT66:  Stateless Address Translation

NAC66:  Network Address Conversion

ARC66: Address Reversible Conversion

ART66: Address reversible Translation

Etc., etc.

Anyone is better that NAT66.

Incidentally, the fact that IP checksums are based on one's complement
prevents, in your NAT66
draft, full reversibility of address conversions.  I will soon post a
message to explain.

Then, UDP/TCP checksums having to be modified, our proposals could
become closer to one another. I am open to work on it.

RD

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 24 Nov 2008 13:56:46 -0500

Do you really think that you'll fool anyone by not calling a NAT a NAT?  
 
It'll be like calling Windows Vista by the name Project Mojave...
 
If the IETF really does have consensus to standardize IPv6-to-IPv6 NAT, then we should have the guts to call it for what it is.
 
Also, as Margaret points out, it'll just make it harder for those who want to implement NAT66 to be able to find the specification.
 
- Wes

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Tuesday, November 25, 2008 11:57 AM
To: Margaret Wasserman
Cc: 'Behave WG'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

	We're saying that IPv6 NAT _already_ exists, that network administrators are _already_ deploying it or planning to deploy it, and that we should try to do what we can to minimize the damage to the transport and application layers. 

This is IMHO the main reason why alternative designs, like the one you propose with Fred, and the one I propose, should be called differently, whatever the chosen name.

Here are some proposals:

Incidentally, the fact that IP checksums are based on one's complement prevents, in your NAT66 <http://tools.ietf.org/html/draft-mrw-behave-nat66-01>  draft, full reversibility of address conversions.  I will soon post a message to explain. 

Then, UDP/TCP checksums having to be modified, our proposals could become closer to one another. I am open to work on it.  

RD

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Nov 2008 11:22:32 -0800

[distribution narrowed to BEHAVE]

On Nov 23, 2008, at 17:18, Margaret Wasserman wrote:
> They used NAT as part of their security architecture and to avoid  
> the need to have their ISPs route their /16 prefix.

You didn't happen to see a security analysis to go along with that,  
did you?

I mention this because I work at one of the few organizations with a  
legacy /8 allocation from IANA, and our IS&T people A) do not require  
NAT as a part of their security architecture, and B) don't seem to  
have any problem getting ISP's to route their /8 prefix (and their  
other, smaller, allocations).

> [...] although home users also benefit from the "simple security"  
> feature described in RFC 4864.

It would be safer to say that residential users respond well to  
marketing and branding efforts that represent IPv4/NAT as a security  
mechanism worth its cost in application transparency.  Localized  
address scarcity is the only *technical* reason for home users to  
deploy IPv4/NAT now.  (I foresee this continuing to be the case going  
forward, c.f. service providers turning to NAT444 instead of SP-NAT44  
w/ firewall CPE.)

Nearly all vendors of residential IPv4 gateway appliances now ship  
their products with dynamic port mapping services, e.g. NAT-PMP and  
UPnP-IGD, enabled in the factory default configuration.  A more secure  
"firewall configuration" would be for these services to be turned  
off.  That they are enabled instead, it seems to me, is clear evidence  
that few vendors take very seriously the notion that any security  
benefit is to be had by blocking from incoming connections from  
unsolicited endpoint nodes.

The motivations for IPv4/NAT have always been and remain today as  
follows: A) node address assignment for multi-homed IPv4 enterprise  
networks, and B) coping at all levels with localized address  
shortage.  For IPv6, both of these issues have been addressed in the  
architecture, as noted well in RFC 4864.

I'd really like to see us stop pretending that NAT is a security  
mechanism.  It isn't one, and it never was.  It has only been sold  
that way by the marketing departments of equipment vendors, and  
customers have responded to such marketing communications in the  
predictable ways.  We, as engineers, have a responsibility to remain  
focused only on the technical considerations and to leave the  
marketing departments to their own devices.

> I am hopeful that the IPv4 NAT in consumer devices will be replaced  
> in IPv6 by a stateful firewall that offers greater configuration  
> flexibility than the security side-effect of IPv4 NA(P)T.

You should read draft-ietf-v6ops-cpe-simple-security then.  It has one  
very important level of configuration flexibility that IPv4/NAT does  
not offer: users will be able to turn it off when they discover that  
it quite naturally breaks their applications without providing any  
measurable security benefit in exchange.

It could be a lot worse.  They could find themselves behind a NAT66  
box with no way of turning it off.

> We know (based on public information from Apple) that at least one  
> major consumer gateway is including firewall support instead of NAT  
> in IPv6.

Again, this is more because of widely-held misperceptions about local  
network protection with IPv6 and non-technical matters relating to  
marketing and branding than any technical considerations.

>  Do you have information about any others?

I know of at least one other vendor of IPv6 residential gateway gear  
that quite sensibly doesn't turn on their NAPT-alike firewall in its  
factory default configuration.  Fortunately, for them, they don't have  
quite the spotlight on them in the trade press that Apple does, so I  
imagine they might be able to continue doing the right thing for some  
time before anyone notices and makes them stop.

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

---

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

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

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

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

				Ted

---

From: Rémi Després <[email-masked]>
Date: Tue, 25 Nov 2008 21:21:52 +0100

Keith Moore   (1-12/1-31/200x) 11/24/08 5:30 PM:

PROPOSAL:

I'm not sure this is a good idea. In particular, I don't want network
administrators to stop advertising global prefixes on their networks
just because they have a NAT installed.

I don't want either

Global addresses can be used in encapsulated packets, as proposed in SAMs.

It combines two advantages:

- Hostshave the  choice between using their local address, tgheir
global address, or one of their global addresses if  the site is
multihomed.

- There is only one routing plan in the site, and no need to change it
in case of renumbering.

And I think there might be a
case to be made for NATing _some_ hosts on a network but not all of them.

This is tprecisely the point I made in sec. 3.6 of SAMs.

If NAT66 means essentially the same as NAT44, but working in IPv6, I
believe we know well enough what it is. If it is taken as meaning
something else, I see great confusion of concepts ahead of us.

RD

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Nov 2008 15:30:14 -0500

> something else, I see great confusion of concepts ahead of us.

There is a lot of potential for NAT66 to be different than NAT44 and
still (a) use address translation and (b) provide similar "benefits".

If we aren't willing to try to make NAT66 any better than NAT44, we
should give up now, have a wake for the Internet, and find other careers
where we can do something useful.

Keith

---

From: Fred Baker <[email-masked]>
Date: Mon, 24 Nov 2008 13:40:10 -0800

I understand your point here. That said, I think you're  
misinterpreting a point.

In behave, on Thursday and again on Friday, and on this combination of  
the [email-masked], [email-masked], [email-masked], and [email-masked]  
lists, I resisted comments at mikes and in email that said "please  
don't even breath the words 'IPv6' and 'NAT' in the same sentence, and  
especially don't make a way for it to be possible" at times when that  
was specifically the subject under discussion.

I will work with any reasonable discussion; I don't consider "don't  
discuss this" to be reasonable discussion.

Any reasonable discussion has to take into account the reasons  
proposed to work on it, one of which has come up in this email  
exchange in Margaret's note commenting on Cisco's use of IP addresses.  
The more important one relates to the rrg work on GSE/8+8. If you  
prefer "lots of little tubes", we can avoid GSE, but if rrg winds up  
taking a gse path, a good NAT implementation (whatever you call it) is  
pretty important. I think I understand the reasons to not do it, which  
largely have to do with the end to end principle and the unintended  
consequences (see "Law of...") that it has had in the IPv4 network.

On Nov 24, 2008, at 2:56 AM, Eric Klein wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Nov 2008 10:54:43 +1300

On 2008-11-26 05:17, Rémi Després wrote:
...
> PROPOSAL:
> "When a packet crosses an IPv6 local/global address space border in the outbound 
> direction,  a NAT66 mapping IS PROHIBITED IF the packet contains a globally 
> routable source address."

This won't fly, as it purports to prevent the usage of NAT66 to convert
a site's PI prefix into a PA prefix, i.e. NAT66 as a solution to the
scaleable multihoming problem.

Absent a better solution to that problem, such a prohibition would
be loudly laughed at by operations people.

   Brian

---

From: Dave Hudson <[email-masked]>
Date: Mon, 24 Nov 2008 22:24:43 +0000

james woodyatt wrote:
> mechanism worth its cost in application transparency.  Localized address 
> scarcity is the only *technical* reason for home users to deploy 
> IPv4/NAT now.  (I foresee this continuing to be the case going forward, 
> c.f. service providers turning to NAT444 instead of SP-NAT44 w/ firewall 
> CPE.)

I daresay that the firewalling element was not planned in the past but 
NAT44 implementations have given a framework for implementing firewall 
functionality and some amount of topology hiding.  While users may not 
actually need address translation I think most have been educated into 
wanting firewalling (especially given the number of documented attacks 
against ports that were otherwise left open solely for other local users).

> Nearly all vendors of residential IPv4 gateway appliances now ship their 
> products with dynamic port mapping services, e.g. NAT-PMP and UPnP-IGD, 
> enabled in the factory default configuration.  A more secure "firewall 
> configuration" would be for these services to be turned off.  That they 
> are enabled instead, it seems to me, is clear evidence that few vendors 
> take very seriously the notion that any security benefit is to be had by 
> blocking from incoming connections from unsolicited endpoint nodes.

I believe almost all offer the option to disable these, but there's at 
least one major certification program (and I have a feeling more than 
one) that requires OEMs to enable UPnP-IGD by default in order to pass 
so unless those certifications cease to be seen to be significant then 
that's unlikely to change.

The other problem is that as more applications choose to rely on UPnP it 
becomes harder to get reliable application behaviour without enabling 
UPnP.  There's also a presumption (whether we believe it or not) that 
hosts on the local network are trusted and therefore won't go mapping 
ports without good reason.

> very important level of configuration flexibility that IPv4/NAT does not 
> offer: users will be able to turn it off when they discover that it 
> quite naturally breaks their applications without providing any 

Would you really want to expose all of your local services or require 
that all end-users learn what multihoming is all about?

> time before anyone notices and makes them stop.

One of the major problems with firewalling is that without something 
like UPnP-IGD the end-user experience for things such a media, VoIP, 
etc., can be frustrating to say the least, but consider the flipside of 
this now - end-users now know that those types of apps can be made to 
work quite nicely through their IPv4 NAT/firewall and are unlikely to be 
convinced that IPv6 apps that aren't able to perform likewise are 
somehow ok.

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Nov 2008 17:31:42 -0500

> against ports that were otherwise left open solely for other local users).

agreed, and I think this is a good part of the justification for "v6
NAT".  address translation might actually be an optional feature, but
firewall (along with deny-by-default, and a NAT/firewall control
protocol) are essential features.

> ports without good reason.

we know better.  clearly any IETF standard for doing NAT traversal /
hole punching would need to include an authentication mechanism.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Nov 2008 16:39:08 -0700

On Nov 24, 2008, at 12:22 PM, james woodyatt wrote:

> UPnP-IGD, enabled in the factory default configuration.

This may be true if you buy your NATs at the apple store, but I assure  
you it is not true if you buy your NATs at Best Buy.

Cullen as an individual contributor.

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Nov 2008 15:58:58 -0800

On Nov 24, 2008, at 15:39, Cullen Jennings wrote:
> This may be true if you buy your NATs at the apple store, but I  
> assure you it is not true if you buy your NATs at Best Buy.

Hmmm.  It's possible I've been misinformed.  I was given to understand  
that my concerns about enabling NAT-PMP in the factory default  
configuration being a violation of the "secure by default" principle  
were dismissed on the grounds that competing products were enabling  
UPnP-IGD by default and that certification programs for Windows Vista  
were even requiring it.

My apologies.

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Nov 2008 16:19:29 -0800

On Nov 24, 2008, at 14:24, Dave Hudson wrote:
> james woodyatt wrote:
>>
>> [...]
>> You should read draft-ietf-v6ops-cpe-simple-security then.  It has  
>> one very important level of configuration flexibility that IPv4/NAT  
>> does not offer: users will be able to turn it off when they  
>> discover that it quite naturally breaks their applications without  
>> providing any measurable security benefit in exchange.
>
> Would you really want to expose all of your local services or  
> require that all end-users learn what multihoming is all about?

Of course not.

p1. If you insist on not using a real AAA system in your application  
server, then the way to expose services to local networks only is to  
bind them to RFC 4193 interface addresses and route accordingly.

p2. If end-users even have to learn about 128-bit IP addresses, much  
less multi-homing, then they have every right to demand that we be  
fired and replaced with somebody who won't abuse them.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Nov 2008 17:46:33 -0700

No Worry - all of the data that I am aware of that I think of as good  
data sets, is unfortunately data that is not allowed to be made public  
which means no one has verified the data. I think we need some public  
data from a reasonable sized sample set.

I've been working with a few folks to see if we can have one group of  
people write a program that helps characterize the NAT (things like  
does it do NAT-PMP or not) and then work with some others to see if we  
can get it rolled out in a way to collect a relatively large sample  
set. Not sure if any of this will happen, but it would be easier to  
come up with a good design if we had more data about the real world.

---

From: Rémi Després <[email-masked]>
Date: Wed, 26 Nov 2008 10:23:48 +0100

Wes Beebee (wbeebee)   (1-12/1-31/200x) 11/24/08 7:56 PM:

Do you really think that you'll fool anyone by not
calling a NAT a NAT?

I certainly don't think it, and precisely look for bot to fool anyone.

1.

As Margaret points out, some vendors already have IPv6 NATs.

In my understanding, they have done it the obvious way: taking a NAT44,
and extending it to support IPv6 both internally and externally.

What I did contend is that:

- It is by refusing to call _these NATs_ NAT66  that confusion will be
created.

- By having name for mechanisms which don't exist yet, and that ensure
reversible mappings, IETF will avoid confusing people.

What I hope is that what everybody naturally understands as being a
NAT66 may
still be called a NAT66.

2.

Trying to prevent people from including NAT66s in their products, while
we know they already have them,
is bound to fail.

What should be useful is designing for IPv6 something better
than the NAT66s. Then, vendors will implement it,  in addition to
NAT66, and users will have the choice to use it.

If the IETF really does have consensus to standardize
IPv6-to-IPv6 NAT, then we should have the guts to call it for what it
is.

In my understanding, it is not a matter of guts, but only a
matter of finding how to make clear what we are doing.

Here is a _modified proposal_, which I hope takes care of your point:

The already existing NAT66, which is derived from NAT44, and is
stateful, is named the "stateful NAT66" (SF-NAT66 or NAT66-SF); the new
one, which is stateless, is named the "stateless NAT66" (SL-NAT66 or
NAT66-SL).

Also, as Margaret points out, it'll just make it harder
for those who want to implement NAT66 to be able to find the
specification.

Assuming that IETF has specified a useful stateless alternative to the
existing stateful NAT66s, I cannot imagine that vendors will find it
difficult to find the document.

Please note that these comments are not against working on Margaret's
and Fred's proposal. Just the
opposite.

Regards,

RD

- Wes

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Rémi Després

To: Margaret Wasserman

Cc: 'Behave WG'; [email-masked]; [email-masked];
[email-masked]

Subject: Re: [BEHAVE] Lack of need for 66nat : Long term
impact to application developers

Here are some proposals:

Etc., etc.

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 26 Nov 2008 15:25:48 +0100

Brian E Carpenter   (1-12/1-31/200x) 11/24/08 10:54 PM:

PROPOSAL:

Sorry I don't get the point.

In my understanding, a source address that begins with a Provider
Independent prefix is NOT a globally routable source address?

If this is right,  NAT66 is NOT prohibited with my proposal, right?

Laughing from time to time, loudly or not, being good for one's health,
I am glad to have provided an opportunity for it :-).

But I still don't understand where I made a mistake. (Maybe one more
opportunity for sound joy!).

Thanks for a clarification.

Regards,

RD

---

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

> application development are not being heard.

Not sure that's entirely true...

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 25 Nov 2008 13:07:10 -0600

> originally specified, I seem to recall ice-tcp succeeded something like 40%

ICE and in particular ICE-TCP are complicated for three reasons:

1) lack of endpoint-independent mapping in many existing NATs, or
other bizarre NAT behaviors
2) firewalling with other than endpoint-independent filtering (which
can generally be worked around when (1) isn't a problem)
3) poor OS implementations, such as XP not supporting TCP-SO

(3) is going away.  (1) is starting to improve with better
understanding and specifications of how NATs should behave.

But let's be clear, firewalls (2) are never going away.  Even if we
have no NATs, firewalls will still require some sort of rendezvous
protocol.  If NATs have sane behavior (1 goes away), then ICE will
have a remarkably high success rate, essentially working whenever
firewall policy doesn't prohibit it.

A world without NATs will be less painful than one with NATs, but
firewalls still mean that unfettered end-to-end connectivity is a
fantasy.  A world with well-behaved NATs is really only marginally
more complicated.

Hell is continuing (actually regressing some) with NATs with totally
unspecified and bizarre behavior that makes it impossible to reliably
establish end-to-end connections.

I would like to have an IPv6 world without NATs.  There's absolutely
no question about that.  But there's a strong need for realism here,
and there's a need for the understanding that the price of being wrong
about the lack of need for NATs is MUCH MUCH higher than the cost of
pulling an ICE implementation off the shelf.

Bruce

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Nov 2008 12:09:47 -0800

> fantasy.  A world with well-behaved NATs is really only marginally

The word "marginally" doesn't really add anything meaningful to that  
last sentence above.  Recommend rewriting it to say: "A world with  
well-behaved NATs is really only more complicated."

Also, why do we need NAT66 again?

> establish end-to-end connections.

That's true.  Why do we need NAT66 again?

> I would like to have an IPv6 world without NATs.

I fail to see why we cannot have an IPv6 world without deploying NAT66  
everywhere.

> There's absolutely

Why is an IPv6 world without NAT66 everywhere an unrealistic vision  
for you?

---

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

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

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

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Nov 2008 10:15:36 +1300

On 2008-11-26 22:23, Rémi Després wrote:
...
> The already existing NAT66, which is derived from NAT44, and is stateful, is 
> named the "stateful NAT66" (SF-NAT66 or NAT66-SF); the new one, which is 
> stateless, is named the "stateless NAT66" (SL-NAT66 or NAT66-SL).

This still "allows" two different objects to exist in the market,
simply by defining two names. I think it is much better that
the distinction be between "RFC5xxx NAT66" and undocumented proprietary
NAT66.

Alternatively, I propose
Stateless Locally Useful Translation between IPv6 and IPv6 (SLUT66)   ;-)

  Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 25 Nov 2008 16:19:51 -0500

> Stateless Locally Useful Translation between IPv6 and IPv6  

Dude, you rock!  :-)

Margaret

---

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

> Stateless Locally Useful Translation between IPv6 and IPv6 (SLUT66)   ;-)

cute name :)

But I really hope that application developers aren't expected to cope
with a dozen different kinds of NATs (between variants of NAT44, NAT46,
NAT64, and NAT66, all with different idiosyncrasies.

Keith

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 25 Nov 2008 16:31:50 -0500

On Tue, Nov 25, 2008 at 3:09 PM, james woodyatt <[email-masked]> wrote:
> The word "marginally" doesn't really add anything meaningful to that last
> sentence above.  Recommend rewriting it to say: "A world with well-behaved
> NATs is really only more complicated."

Feel free to rewrite it, but there are various degrees of complexity.
There is a vast differences in engineering complexity between a
problem that is solved with a drop-in ICE component vs one that
requires an infrastructure of TURN servers.

> Why is an IPv6 world without NAT66 everywhere an unrealistic vision for you?
>

My message never said whether IPv6 will be possible with or without
NAT66.  That's somewhat outside my area of expertise.  I do, however,
have concerns that serious questions have been brought up various
people about 4864, commercial (hotel) networks, cisco's example, and
the current existence of NAT66 technology.  If there are good
solutions to these questions, that's ideal, but there seems to be
serious lack of consensus here.  If there isn't consensus among our
participants, that's a problem.

Like I said, the cost of making a mistake is huge here.

For the purposes of this discussion, I'm an appliction developer.
There are known solutions that I'm comfortable deploying for
well-behaved NATs.  I would much rather have a world of well-behaved
NATs than a world full of NATs that can't be dealt with effectively.

The original point of my post was to point out that the existence of
NAPT isn't to be blamed for the low success rate of ICE/ICE-TCP.
Inconsistent, unspecified behavior is what has caused those problems.

Bruce

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Nov 2008 10:37:23 +1300

Rémi,

PI prefixes are certainly globally routeable; they are assigned
by RIRs just like PA prefixes. Whether they get routed in the real
world depends on BGP4 policy, of course.

2001:0DF0::/47 is the University of Auckland PI prefix
assigned by APNIC, for example. It's routed in the research
networks by KAREN (whose PA prefix is 2404:0138::/32)
but not in the commercial networks. If it was NAT66'ed
into 2404:0138:xxxx::/47, there would be no separate BGP4
advertisement for it. Every site that does that would reduce
the BGP4 table by one entry.

   Brian

On 2008-11-27 03:25, Rémi Després wrote:
> In my understanding, a source address that begins with a Provider Independent 
> prefix is NOT a globally routable source address?
> Laughing from time to time, loudly or not, being good for one's health, I am 
> glad to have provided an opportunity for it :-).
> But I still don't understand where I made a mistake. (Maybe one more opportunity 
> for sound joy!).
>

---

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

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

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

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

Tony

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kind regards
Peter

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

---

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

David Morris wrote:

> Actually, he did not say the server forwarded traffic, just that it
> provided a way to learn how 'my' address was mapped through 'my' nat. 

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

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

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

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

Keith

---

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

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

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

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

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

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

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

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

---

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

Tony,

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

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

> The only justifications being given are

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

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

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

Regards,
-drc

---

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

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

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

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

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

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

Keith

---

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

> meet the needs described above?

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

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

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

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

---

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

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

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

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

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

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

Tony

---

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

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

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

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

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

> NAT66 "solution," then I would humbly suggest that it doesn't make much
> sense for there to be a single global DNS horizon where we have multiple
> global address realms.

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

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

Keith

---

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

Tony Hain wrote:

> trying to build it'.

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

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

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

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

Keith

---

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

Tony,

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

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

> something known to be detrimental,

Standards development effort != endorsement.

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

> Instead all we get is complaints that anyone not

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

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

Regards,
-drc

---

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

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

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

> Standards development effort != endorsement.

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

> of the underlying disease.

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

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

Keith

---

From: <[email-masked]>
Date: Wed, 26 Nov 2008 08:08:54 +0100

Keith,

I think you provide a very good and precise analysis of the reasons why NATs are often perceived as security elements.

Here are some straightforward facts that could convince people that NATs are not true security elements:

1)How you proceed with firewalls:
You define a security policy
You write filters in the firewall
You implement your rules from your policy
permit
.
.
.
permit
deny all

2)How you proceed with NATs:
NAT filters (it is a matter of fact)
The filters you sometimes write are to open doors(e.g. port forwarding in CPE NAT)
Basically all outbound connections traverse the NAT and all inbound connections are blocked
But! Actually it depends on:
-the type of NAT (and most of the time you don't know it)
-the communication history (and most of the time you can't know it)
You are never sure of what the NAT filters
There is no way to implement YOUR rules from YOUR policy

Regards

Pierre

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Keith Moore
> Envoyé : lundi 24 novembre 2008 05:18
> À : Margaret Wasserman
> Cc : 'Behave WG'; [email-masked]; [email-masked]; [email-masked]
> Objet : Re: [BEHAVE] Lack of need for 66nat : Long termimpact 
> to application developers
> 
> > 198.133.219.0/24
> > Fred's presentation, Cisco's IT department has also 
> expressed a need 
> > for
> > RFC
> > 4864 does a good job of covering all of the reasons that I've heard 
> > for why network administrators are choosing to use IPv6 NAT.
> 
> Even assuming that there are sufficient technical mechanisms 
> to do without NAT in place (and I have reason to doubt that), 
> there's a huge mindshare (or "religious") barrier to 
> overcome.  I've never talked to an enterprise network admin 
> who didn't think that NATs were both legitimate and essential 
> - though when pressed for a reason why, they have rarely 
> mentioned anything that a firewall couldn't do better.  The 
> fact that NATs became so widely used in IPv4 (somewhat out of 
> necessity) has bestowed a kind of legitimacy for NATs in 
> network admins' minds - not that NAT vendors haven't helped, 
> of course.
> 
> At the same time, I've never talked to an enterprise network 
> admin who had any clue about what it meant to do a systematic 
> security threat analysis.  Which is not to say that they're 
> completely clueless about security, but rather, that they 
> would have a difficult time being convinced that they could 
> actually dispense with a mechanism like NAT.
>  (Especially when, if they delete the NAT for their v6 
> configuration, and some attack happens, they'll probably be 
> forced to answer to some superior who knows even less about 
> network security than they do, but who has been convinced by 
> some vendor salesman that NATs are still the best thing since 
> sliced bread.)
> 
> All that is to say that, from a marketing perspective, it's 
> probably a lot easier to sell the public on something called 
> "v6 NAT" (even if it acts fairly differently than "v4 NAT") 
> than it is to sell the public on the idea that NATs shouldn't 
> be used in v6.
> 
> (There's also a reason I called my latest proposal "NAT-XC" 
> rather than something else.)
> 
> As people are surely aware by now, I strongly dislike NATs.  
> I also generally think that IETF's job is to describe, in as 
> clear a language as possible, what it believes will work well 
> -- rather than (e.g.) to endorse existing practice, or to 
> tell people what they want to hear.
> 
> But if our ultimate goal is to promote the continued 
> development, flexibility, and maintainability of the Internet 
> - then it's possible that the best path for doing this is to 
> "embrace and extend" NAT and to do so in such a way that (a) 
> there's a clearly defined standard way for applications to 
> code around them, and (b) every standards-conforming v6 NAT 
> has built-in mechanisms to aid migration away from it.  For example,
> 
> - standardize the functionality in such a way that the 
> firewall and NAT functions are logically independent, and the 
> NAT can be disabled without impacting the firewall;
> 
> - allow (non-identity) NAT mappings to be enabled/disabled on 
> a per-host basis, so that NAT can be enabled (when needed) or 
> disabled (when it gets in the way) on a fine-grained 
> basis...rather than forcing an admin to NAT or not NAT his 
> entire network;
> 
> - a mechanism is built in as part of the standard to allow 
> apps (multiparty apps in particular) to know their public IP 
> addresses, use them even "behind" the NAT (hairpinning), 
> explicitly request bindings, and listen for traffic from 
> outside - provided they are granted such access and 
> credentials by the network administrators.
> 
> 
> And for me this is the clincher:  Unless we can make an 
> airtight case that v6 NAT is almost never more beneficial 
> than harmful, then I think it makes more technical sense to 
> define (perhaps, but not necessarily,
> standardize) how to make them as harmless as possible (with 
> strong statements about their limitations and applicability), 
> than to merely say "don't use them".
> 
> Or - to make a slightly weaker case - we at least have to do 
> the _exercise_ of seeing whether we can make v6 NATs "mostly 
> harmless", "occasionally beneficial", and provide a path away 
> from them.
> 
> If after having done that exercise, we can't convince 
> ourselves that v6 NATs can meet these criteria, we should 
> re-think publishing the document.  And we shouldn't take on 
> the exercise without being willing to be honest with 
> ourselves about what we find, regardless of our preconceptions.
> 
> --
> 
> I'm of the belief that at least some network admins would 
> turn off v4 NAT today, if they could do so easily and without 
> much apparent risk - if for no reason than to save themselves 
> from stress and premature baldness resulting from trying to 
> get B2B apps working across back-to-back NATs, or from trying 
> to trace flows across NAT boundaries, or the fragility caused 
> by NATs losing bindings on occasion, or the difficulties 
> getting P2P apps working, etc.  (Actually I suspect the 
> If a few admins tried to get rid of NATs in v6, and it worked 
> well for them, the word would spread and others would follow 
> as long as it were easy to make the change.  It might take a 
> few years, but admins (and even users, and for that matter 
> IETFers) do learn eventually.  But for that to happen, we 
> have to give them mechanisms that make it easy for
> p.s. People who have known me for awhile may wonder if, in 
> hindsight, I've changed my mind about v4 NATs.  The answer is 
> "I don't think so."
> I remember arguing, sometime around 10 years ago, that if we 
> were going to have NATs, that we needed to make sure there 
> was a clear transition path away from NATs.  The prevailing 
> belief within IETF at the time seemed to be that the NATs 
> couldn't be changed at all - we'd just have
> objected to that strategy, and to suggestions that NAT was 
> somehow a part of the Internet architecture rather than a 
> half-baked hack.  (And of course, that belief turned out to 
> be wrong as demonstrated by both UPnP and NAT-PMP.)
> 
> Essentially I'm making the same argument for now v6 NATs as I 
> once made for v4 NATs - we need a transition path away from them.
> 
> However I also don't worry about v6 NATs causing the same 
> degree of harm as v4 NATs have, especially after deprecating 
> site-locals.  A huge part of the problem with v4 NATs is 
> related to address space scarcity (and port mapping), and 
> conflicting use of v4 addresses in different realms.
>

---

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

On 24 nov 2008, at 22:40, Fred Baker wrote:

> taking a gse path, a good NAT implementation (whatever you call it)  
> is pretty important.

Note that GSE assumes it can change addresses to any other address in  
any packet at any time.

With NAT this is not the case, if you start rewriting to a different  
address in the middle of a session, the session breaks.

This can partially be addressed with something like shim6, but in that  
case you still need to make sure that packets towards non-shim6  
destinations and packets for which no shim6 state has been negotiated  
yet are rewritten to the same address.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

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

On 24 nov 2008, at 23:31, Keith Moore wrote:

> but

Nonsense. Hosts that move (like laptops and PDA/smartphone type  
systems) must be able to handle being connected to untrusted networks  
without a firewall in between. Since these hosts run the same OSes as  
non-movable hosts all OSes must be able to function securely in  
untrusted networks. I believe this is in fact the case today for the  
latest versions of all major OSes. The perceived need for firewalls is  
the generals trying to win the previous war.

> clearly any IETF standard for doing NAT traversal /

Again, nonsense. If people want authentication here, fine. But we  
shouldn't force them to have this if they don't want it. People seem  
to get by just fine without it today.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

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

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

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

---

From: Rémi Després <[email-masked]>
Date: Wed, 26 Nov 2008 10:22:37 +0100

Thanks, Brian, for the information.

Is there a more complete description of the Auckland configuration on
which to see:

- which translations are done where

- how it solves the scalable multihoming problem.

I still don't see which problem would appear if  by default NAT66 would
be prohibited,
at a given border point,  for packets that, at this point, have an
operational reverse path (i.e. are really globally routable there).

RD

Brian E Carpenter   (1-12/1-31/200x) 11/25/08 10:37 PM:

Rémi,

Brian

PROPOSAL:

Regards,

RD

---

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

WARNING: contains banned part

Subject: RE: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Behave WG" <[email-masked]>
Cc: "IETF Discussion" <[email-masked]>
Date: Wed, 26 Nov 2008 08:45:09 -0800

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

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

Please,

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

Regards

Magnus

--

Magnus Westerlund

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

---

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

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

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

---

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

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

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

Dave Morris

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

All feedback and opinions are welcome!

Margaret

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

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

---

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

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

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

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Nov 2008 12:53:33 -0500

Iljitsch van Beijnum wrote:
> Nonsense. Hosts that move (like laptops and PDA/smartphone type systems)
> must be able to handle being connected to untrusted networks without a
> firewall in between. Since these hosts run the same OSes as non-movable
> hosts all OSes must be able to function securely in untrusted networks.
> I believe this is in fact the case today for the latest versions of all
> major OSes. 

That's all true (except the "nonsense" part).  But it doesn't obviate
the use case for firewalls.

Consider that personal hygiene is more important in a dense community of
individuals, than it is in a sparse community of individuals, because
disease is more easily spread within the dense population.

Similarly, virus propagation and other kinds of attack are easier in a
enterprise network (where hosts know more about one another, have more
ability to passively observe others' traffic and actively interfere with
it, etc.)  So there's an argument to be made that hosts in an enterprise
network need more protection, or at least different protection, than
when plugged into an arbitrary place in the network.

Consider also that when viewed in the aggregate, host security is a
statistical phenomenon rather than something you either have or you
don't.  On any given enterprise network, X% of the hosts are vulnerable
to a particular attack that exists in the wild.

If you're a network admin, you can (and should) work to minimize X, of
course.  But you certainly don't have sufficient tools, energy,
authority, and expertise to reduce X to 0 and keep it there.  And yet,
if a sufficient number of those vulnerable hosts are compromised, it's
going to be viewed as _your_ problem rather than the users' problems.
And if those compromised hosts become vectors to mount other attacks on
machines behind your firewall - compromising more hosts and/or
disrupting your network - it's doubly _your_ problem.

Bottom line: network admins are _not_ going to give up tools that they
think help them deal with the potential for host attacks or network
disruption.

> shouldn't force them to have this if they don't want it. People seem to
> get by just fine without it today.

I should clarify - I don't necessarily think clients should be required
to authenticate to NATs/firewalls.

But it's also clear to me that to be viable, any standard for NAT has to
consider firewall functionality and incorporate that into the standard.
And that standard has to define an authentication mechanism, and
probably, to make some of it mandatory to implement - though probably
not mandatory to use.

Keith

---

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

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

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

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

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

I really hope you aren't correct about this, but I fear you are.

> 2) Should they regard the assumption that there is no NAT6 as a design
>    fault that may lead to lack of interoperability.

> The only way that the effort being expended to kill NAT66 makes any sense is
> if the idea is to allow this type of argument to be rulled out of scope as
> similar arguments were ruled out of scope when they were brought up in existing
> protocols that simply do not work properly because the design was intentionally
> made to be unfriendly to NAT.

Unfortunately, protocol-unfriendly middleboxes are a fact of life even for
protocols that have no specific issues with NAT. In the case of email,
for example, NAT rarely presents problems even though a significant fraction
of message submission occurs from NATted systems.

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

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

> If we recognize that there is no consensus that applications that are not
> NAT66-agile will work in future then we should agree that the reasonable
> default requirement for an apps WG should be that it should build a protocol
> that is NAT66 tolerant. But I suspect that there will be severe pushback
> against that.

I'm sure there will. That said, perhaps one alternative is to attempt to reduce
the extent to which NAT66 will be needed by doing what Fred Baker suggests and
looking clearly and carefully at the reasons for NAT use. But it is very hard
to do this in the present climte of what amounts to religious hysteria on both
sides.

> I would NAT66 my network for the simple reason that very few endpoint devices
> actually tollerate a change in the IP address without at a minimum a service
> interruption. Since I cannot guarantee that my IPv6 address from my ISP will
> never change I am going to NAT66 my internal network for the sake of having
> static numbering inside the network.

Bingo. That's exactly the reason long-term I'll probably do it too.

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

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

I went for something like 10 years without having to renumber, and as a result
IP addresses got put in all sorts of nooks and crannies on my network. Then
suddenly and without warning my ISP announced an emeergency numbering change
due to an upstream provider switch. The announcement went out at 11:00PM Sunday
night; the renumbering occurred the next morning.

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

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

                                Ned

---

From: Peter Dambier <[email-masked]>
Date: Wed, 26 Nov 2008 20:12:40 +0100

Hallam-Baker, Phillip wrote:
...
>  
> The only thing global about DNS is that there is only one consensus
> holder of a particular name. You can override ietf.org in your local DNS
> server but you cannot persuade a large number of folk to do that at a
> global level.

sorry but I guess it is the censoring method most often used.
You might find a lot of DNS-servers in europe doing that.

It is done in the resolvers of your ISP.

That is one of the reasons why I am running my own local root-server.

> Can is opened, Do you want to borrow a soldering iron and a spoon to try

Tried my gluing gun but they got out again when that stuff cooled down.

How about NAT66 naturally supports the idea of more than one root :)

I dont dare repeating that on the IETF list yet.

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

---

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

> essential step in minimizing the use of NAT66.

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

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

Margaret

---

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

Hi Ned,

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

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

Margaret

---

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

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

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

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

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Nov 2008 09:57:37 +1300

Hi Rémi,

There's nothing specific to the University of Auckland here;
I just chose a concrete example. I'm not sure how I can say
it more clearly: we can avoid adding a specific BGP4 route for
a given prefix if that prefix is systematically NAT66'ed
into a PA prefix for each provider of a multihomed site. This works
in three cases that I can think of:

1. A site is using ULAs internally.
2. A site is using a PI prefix internally.
3. A site is using a single PA prefix internally (but in this
   case, NAT66 is not needed on the link to the ISP that this
   PA prefix is derived from).

The case where it doesn't apply is what I call Plan A for IPv6,
where the site is using multiple PA prefixes internally, i.e.
one prefix derived from each provider. Obviously, this case
cannot provide automatic failover (unless SHIM6 is in use).

   Brian

On 2008-11-26 22:22, Rémi Després wrote:
> Is there a more complete description of the Auckland configuration on which to see:
> I still don't see which problem would appear if  by default NAT66 would be 
> prohibited, at a given border point,  for packets that, at this point, have an

---

From: Rémi Després <[email-masked]>
Date: Wed, 26 Nov 2008 22:57:15 +0100

Keith Moore  -  le (m/j/a) 11/26/08 9:18 PM:

Full agreement.

What I hope will be clear is that, if a host has at least one IPv6
globally routable address:

- Packets sent by this host with this address as source will NOT be
modified before reaching the IPv6 globally routed Internet.

- Packets this host  receives with this address as destination will NOT
have been modified between the IPv6 globally routable Internet and
itself.

Opinions?

RD

---

From: Peter Dambier <[email-masked]>
Date: Wed, 26 Nov 2008 23:29:57 +0100

Rémi Després wrote:
> have been modified between the IPv6 globally routable Internet and itself.
> 
> Opinions?
> 
> RD
> 
> 

Sounds good.

Peter

- --
Peter and Karin Dambier

---

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

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

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

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

/TJ

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Nov 2008 01:52:36 -0500

> have been modified between the IPv6 globally routable Internet and itself.

other than that being woefully insufficient?

Keith

---

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

Joel M. Halpern wrote:
> As far as I can tell, most of what is being asked for here has little,
> if anything, to do with NAT.  To paraphrase:
> 
> If we are going to have firewalls which block incoming connections,
> communication between entities behind such firewalls should still be
> possible without any "external" servers.
> 
> That is a tall (not impossible, but quite tall) order, which we have
> attempted to address several times with little effect.
> 
> And let us be very clear.  Network admins have been asking for and using
> such features for at least 18 years, well before NAT.
> 
> I would recommend separating the problems.  The NAT solution, as I
> understand it, does not make this problem worses.  That is about all one
> can ask of the NAT side of the equation.

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

Keith

---

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

Mark Andrews wrote:

> 
> 	And if you stop thinking IPv6 == IPv4 + big addresses and
> 	start thinking multiple IPv6 addresses including a ULA IPv6
> 	address + RFC 3484 you get local address stability without
> 	needing a NAT.  You use ULAs for internal communication and
> 	global addresses for external communication.
> 
> 	This isn't future stuff, you can do this today.  You can
> 	renumber your external addresses daily and keep internal
> 	sessions up for weeks.

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

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

Keith

---

From: Rémi Després <[email-masked]>
Date: Thu, 27 Nov 2008 11:09:22 +0100

Hi, Brian,
Continued analysis below.
RD

Brian E Carpenter  -  le (m/j/a) 11/26/08 9:57 PM:
> into a PA prefix for each provider of a multihomed site.
"Yes we can" (as heard recently in a different context).

But what I don't see is *why we would want to systematically NAT if the 
prefix is globally routable*.

>  This works
No problem here, the rule I propose permits NATs to be used (and there 
is no other choice).

> 2. A site is using a PI prefix internally.
In my understanding, this site should return it PI prefix to IANA, since 
it doesn't use it as a routable address,  and use addresses in a local 
space instead.

>    PA prefix is derived from).
This one is more complex.

I checked with Mark Townsley what Cisco does internally: NATs for all 
users that are tunnel-connected to their company network (they have RFC 
1918 addresses); no NAT anywhere for their internal users (they use the 
IPv4  PI prefix of the company). Clean and simple.

Now, you consider a site where, depending on which exit of a private 
network is used, packets would be natted or not.

In my understanding, this breaks the benefit on E2E transparency of 
routed PI prefixes.  It can make sense however if the natted exit is 
only used as a last resort solution, when all transparent exits are down 
(advertised with a dissuasively high metric). But in this case the rule 
I proposed below does work:  since there is no reverse path for the PI 
prefix at this exit, NAT is permitted.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Nov 2008 13:37:55 +0100

> course.

I understand that. But a port blocking firewall is an extremely crude  
tool for this purpose. But the real problem is that many  
administrators refuse to open ports for legitimate applications,  
forcing the applications and users to work around the firewall, which  
of course defeats the purpose of having one.

What we need is a middlebox that knows which software is trying to  
communicate, and then block that software if it's not allowed to  
communicate by policy. What I would love is such a middlebox that  
subscribes to a feed of vulnerabilities, so it automatically blocks  
Quicktime when there is another exploit - but only the vulnerable  
versions. So as soon as I update, the middlebox allows me through again.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Nov 2008 13:44:49 +0100

On 26 nov 2008, at 22:57, Rémi Després wrote:

> - Packets this host  receives with this address as destination will  
> NOT have been modified between the IPv6 globally routable Internet  
> and itself.

So that means NAT66 may only occur when hosts have (U)LA addresses.

Makes sense to me.

---

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

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

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

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

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

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

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Nov 2008 10:35:58 -0500

Iljitsch van Beijnum wrote:

> communicate by policy.

I've come to a similar conclusion.

> What I would love is such a middlebox that subscribes to a feed of vulnerabilities, so it automatically blocks

Yep, clearly it needs to be version-dependent.

Keith

---

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

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

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

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

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

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

---

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

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

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

Eric

---

From: Rémi Després <[email-masked]>
Date: Thu, 27 Nov 2008 16:57:53 +0100

> So that means NAT66 may only occur when hosts have (U)LA addresses.
Thanks, Iljitsch.

Wouldn't it be nice to reach consensus on this.

Brian seems to have objections though.

They might lead to more complex a rule, to cover some special cases he 
believes are important.  As I understand it,  case of failure of normal 
global-address route(s), a fallback via another exit where Natting is 
unavoidable could be better that no connectivity at all. (Note that if 
hosts would all have two addresses, a global one and a local one, 
modifying the rule would not be needed. But AFAIK my Apple can have only 
one IPv6 address, at least for the time being.

Cheers,
RD

---

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

> Wouldn't it be nice to reach consensus on this.

Consensus on what?  A model which is totally insufficient to permit apps
to work?  What would be the point of that?

Keith

---

From: Rémi Després <[email-masked]>
Date: Thu, 27 Nov 2008 17:34:22 +0100

Keith Moore  -  le (m/j/a) 11/27/08 5:23 PM:

Makes sense to me.

Thanks, Iljitsch.

That was certainly not the intention.

Could you be more explicit on where, in your understanding, it fails?

RD

---

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

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

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

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

---

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

> Could you be more explicit on where, in your understanding, it fails?

I had just started to write an email, and realized that (a) an email
would not be sufficient to address the topic and (b) that it would take
more than a few hours to write.  So I'm taking notes from which I will
hopefully generate an I-D in a few days.

But the basic idea is that any attempt to define a comprehensive set of
restrictions on the use of NATs has to follow from a thorough
understanding of what applications need in order to function reliably.

And restricting NATs to ULAs is neither necessary nor sufficient.

Keith

---

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

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

Respectfully, Cullen

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

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

---

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

Ned

---

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

> solution to site renumbering:  NAT.

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

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

				Ned

---

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

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

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

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

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

---

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

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

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

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

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

>Standards development effort != endorsement.

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

Happy Thanksgiving,
				Ted

---

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

Yours,
Joel M. Halpern

---

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

In line comments...

> it doesn't use it as a routable address,  and use addresses in a local

That just won't happen, for socio-economic reasons. Also, any attempt
by the IETF to prohibit NAT66 for PI prefixes will certainly be ignored.

> (advertised with a dissuasively high metric). 

If there is a refusal to use the multi-prefix model, there is only one
transparent exit (i.e. the ISP that the PA prefix is derived from).
In that case, NAT66 prevents punching a hole in that ISP's prefix and
therefore saves one entry in the DFZ. That is the whole point I think.
The tradeoff is: multi-prefix vs (single prefix + lost address transparency)
vs (single prefix + bigger DFZ). And it really doesn't matter whether
the single prefix is PI, ULA or PA: the market will decide about that.

Oh, OK, here's a matrix:

On-site address       Connection       Advantages        Disadvantages
type                  to ISP
_________________________________________________________________________

Multiple PA           Normal border    e2e transparent;  Admin complexity
prefixes              routing          no DFZ entry      for user site;
                                                         no TCP failover

Single PI prefix      Normal border    e2e transparent   Extra DFZ entry
                      routing + BGP4
                      advertisement

Single prefix         NAT66            No extra          Not transparent
(ideally ULA, but                      DFZ entry
PI not impossible)

Single PA prefix      Normal routing   No extra          Semi-transparent
                      to main ISP;     DFZ entry
                      NAT66 to others

   Brian

> But in this case the rule
>>> I still don't see which problem would appear if  by default NAT66
>>> would be prohibited, at a given border point,  for packets that, at
>>> this point, have an operational reverse path (i.e. are really
>>> globally routable there).
>>>
>>>     
> 
>

---

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

Brian E Carpenter  -  le (m/j/a) 11/28/08 2:51 AM:

Agreed. The "should" was theoretical.

(Yet, getting a globally routable prefix and Natting it in all CPEs
would be a waste of address space, not to be recommended.)

Nice matrix.

About the first line, the SAM approach I propose, still to be
stabilized and clarified, is believed to make administration simple.
Also,  with host participation, it should  provide TCP failover, and
even connection continuity with SCTP (but this is another story!).

Regards,

RD

---

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

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

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

There are issues like split DNS and address selection.

Stig
Using ULAs for intra-site stability

1. Introduction

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

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

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

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

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

2. Unique Local Addresses (ULA)

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

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

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

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

2.2 ULA Global ID

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

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

2.3 Routing of ULAs

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

2.4 Scope and reachability

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

2.5 ULAs and DNS

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

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

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

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

3. ULAs for intra-site stability

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

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

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

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

3.1 Address selection

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

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

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

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

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

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

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

4. IPv4 addresses for intra-site stability

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

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

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

5. Conclusions

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

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

---

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

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

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

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

	Mark

---

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

On Fri, Nov 28, 2008 at 21:50, Hallam-Baker, Phillip <[email-masked]>wrote:

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

Not necessarily, but it would be nice if we could both have systems that are
not coded badly and networks that are not broken by design.

And I really doubt that the lines of code, in say Vista, that relate to IP
stack and addressed makes up even 0.01% of their code.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "TJ" <[email-masked]>
Date: Sat, 29 Nov 2008 08:43:55 -0500

"And restricting NATs to ULAs is neither necessary nor sufficient."

I agree with that statement, but at the same time think having a separate
range (I mentioned fc00::/8 previously, someone else (RD?) mentioned using a
subset of that - something like FC00::/48) that is explicitly meant to be
NATed would be useful.  This would also allow applications make a more
informed decision when it has to differentiate between a global unicast and
a global-scope ULA.

/TJ

---

From: Keith Moore <[email-masked]>
Date: Sat, 29 Nov 2008 12:06:57 -0500

> informed decision when it has to differentiate between a global unicast and

You don't make things easier for applications by either (a) making
addresses ambiguous, or (b) giving them more complex decisions to make
(even if they're "more informed" about those decisions)

If anything, IPv6 applications need fewer kinds of addresses to deal
with, not more kinds.

Keith

---

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

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

On 11/28/08, Hallam-Baker, Phillip <[email-masked]> wrote:
> In message
> <[email-masked]

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

---

From: james woodyatt <[email-masked]>
Date: Sun, 30 Nov 2008 13:12:42 -0800

On Nov 27, 2008, at 08:39 , Iljitsch van Beijnum wrote:
>> growth of NAT, and endorsing NAT.  Of the 3 I only object to the  
>> 2nd one.  So we either kill NAT so dead that it can not be brough  
>> back in any form or we find a way to meet the needs in a way that  
>> will not "break the internet" nor prevent new p2p applications.
>

I must vigorously disagree with Mr. van Beijnum.  A predictable and  
consistent NAT66 cannot be contained.  It will overwhelm the Internet  
architecture in IPv6 just like it did with IPv4.

I also differ from Mr. Klein in that I find only the first option  
really acceptable.  We need to kill NAT66 dead dead dead.  If that  
means something as radical as elevating SHIM6 to mandatory, then so be  
it.  I hope that won't be required, but I'd rather see *that* than to  
see these NAT66 proposals go forward.

I'm see option two as the best alternative to option one, because  
NAT66 isn't intended to mitigate any localized address shortage  
problem.  I see a plethora of unpredictable and inconsistent, non- 
*STANDARD* designs that break applications in completely non-intuitive  
and mysterious ways as much more easily contained than IPv4/NAPT ever  
was.  Users will discover that turning it off makes their networks  
work better than leaving it on.  IPv4/NAPT users do not have the  
option to turn off NAT in their gateways.  It's cost prohibitive for  
too many of them, particularly residential subscribers.  This should  
not be the case with IPv6.

By standardizing the behavior of NAT66, and thus issuing an IETF and  
IAB blessing of it, we will be giving the pathogen of NAT exactly the  
vectors it needs to spread with highest efficiency through the IPv6  
public Internet.

---

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

James,

On 2008-12-01 10:12, james woodyatt wrote:
...
> By standardizing the behavior of NAT66, and thus issuing an IETF and IAB
> blessing of it, we will be giving the pathogen of NAT exactly the

Then you need to hurry over to the RRG and invent an alternative
solution to the multihoming problem that is acceptable to application
writers, o/s writers, router and CPE vendors, ISPs, and site IT managers
alike.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 Nov 2008 17:29:45 -0500

> writers, o/s writers, router and CPE vendors, ISPs, and site IT managers

I have to wonder - how much representation is there from application and
o/s writers in the RRG?

It's hard to avoid the impression that IPv6 design decisions were made
without much input from application writers -- even though the purpose
of the network is to support applications.

Keith

---

From: james woodyatt <[email-masked]>
Date: Sun, 30 Nov 2008 18:11:56 -0800

> writers, o/s writers, router and CPE vendors, ISPs, and site IT  

I suspect the "acceptable to application writers, o/s writers, router  
and CPE vendors, ISPs, and site IT managers alike" condition is the  
one on which we are all hanging.  For a significant fraction of those  
communities, nothing less than NAT à la IPv4 will suffice for reasons  
that cannot be articulated.

I know what I'd propose as an alternative to NAT for the multihoming  
problem, but I suspect it has already been rejected by one of those  
communities basically on the grounds that it isn't full-blown NAT à la  
IPv4, which is the only thing that can be ever be acceptable to  
somebody with enough clout to stall any alternative that might arise.

Here's what I'd do: define a new end-to-end extension header, kinda  
like the existing source routing header, but intended to be packed  
by... let us say... a certain kind of border gateway rather than the  
initiating endpoint node.  In the "outbound" flow, the source address  
in the outer IPv6 header would be replaced with a source address  
configured by the gateway, and the original source address would be  
pushed into the extension header.  The rule would be that transport  
protocols must use the source address at the bottom of the stack when  
composing the pseudo-header for payload verification.  Transport  
endpoints would also be required to respond in the reverse direction  
by copying the extension header from the most recently received packet  
from the destination transport address.  Routers receiving packets in  
the reverse flow would be responsible for unpacking those extension  
headers the same way they are packed in the forward direction.   
Transport endpoints would not use this extension header for the  
initial packet in a flow.

In this fashion, IPv6 nodes capable of processing this extension  
header might receive flow initiations from anywhere on the Internet,  
including nodes without globally reachable interface addresses.   
Depending on administrative policy, this extension could also be used  
to permit servers to be made available to any subset of the global  
Internet on nodes that do not have any globally reachable interface  
addresses so long as the routers configured to push these extension  
headers for them are using globally routed addresses which the clients  
can use to initiate flows.

I think this would more than adequately address all the multihoming  
concerns without requiring the use of NAT.  It would make operating  
systems vendors sad, but not *that* sad, because it's not like IPv6 is  
completely unusable without this extension.  They could roll it out  
around the same time they get around to rolling out MIPv6, MLDv2,  
etc.  Speaking as a CPE gateway developer, I can say I'd much rather  
have a standard like this than have to respond to marketing demands  
for NAT66 kludgery.  Testing an encapsulation mechanism is a lot  
easier than testing a full-blow NAT implementation.

Where I predict this proposal will meet with hostile resistance is  
from site IT managers who I will likely find it unacceptable because  
it discloses the internal addresses of endpoint nodes in their private  
networks to networks outside their control.  Many of these people want  
full-blown port-changing NAT66 for its topology hiding function,  
despite its dubious security value in real, measurable terms.  I  
contend those people have yet to put forward an explanation for this  
demand that stands up to rational analysis.  They've had plenty of  
time to do so, and lately, it seems like they've stopped trying  
altogether.  To me, they seem to be saying simply that they need NAT66  
because nothing else will soothe their emotional discomfort with IPv6  
migration issues.  [Inappropriate summarizing rhetoric, using words  
like "crackpot" and "stupid," deleted for the sake of comity.]

So, okay— where is the draft, which was no doubt written up ten years  
ago by somebody like Brian Carpenter, that does what I'm proposing  
above?  I'd like to read the archives to see how and why it got shot  
down.