Fw: WG Action: Conclusion of IP Version 6 (ipv6)
The subject line is amazing... Begin forwarded message: Date: Tue, 25 Sep 2007 14:30:02 -0400 From: IESG Secretary <iesg-secretary@ietf.org> To: ietf-announce@ietf.org Cc: Robert Hinden <bob.hinden@nokia.com>, Brian Haberman <brian@innovationslab.net>, ipv6@ietf.org Subject: WG Action: Conclusion of IP Version 6 (ipv6) The IP Version 6 Working Group (ipv6) in the Internet Area has concluded. The IESG contact persons are Jari Arkko and Mark Townsley. +++ A new Working Group, 6MAN, has been created to deal with maintenance issues arising in IPv6 specifications. The IPv6 WG is closed. This is an important milestone for IPv6, marking the official closing of the IPv6 development effort. The ADs would like to thank everyone -- chairs, authors, editors, contributors -- who has been involved in the effort over the years. The IPv6 working group and its predecessor, IPNGWG, produced 79 RFCs (including 5 in the RFC queue). Issues relating to IPv6 should in the future be taken up in 6MAN if they relate to problems discovered during implementation or deployment; V6OPS if they relate to operational issues; BOF proposals, individual submissions etc. for new functionality. The mailing list of the IPv6 WG stays alive; the list will still be used by the 6MAN WG in order to avoid people having to resubscribe and/or adjust their mail filters. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Steve Bellovin, http://www.cs.columbia.edu/~smb
true enough. i guess this means that we get IPv6 "as is, where is" and there will be limited new development of same. --bill On Tue, Sep 25, 2007 at 06:59:28PM +0000, Steven M. Bellovin wrote:
The subject line is amazing...
Begin forwarded message:
Date: Tue, 25 Sep 2007 14:30:02 -0400 From: IESG Secretary <iesg-secretary@ietf.org> To: ietf-announce@ietf.org Cc: Robert Hinden <bob.hinden@nokia.com>, Brian Haberman <brian@innovationslab.net>, ipv6@ietf.org Subject: WG Action: Conclusion of IP Version 6 (ipv6)
The IP Version 6 Working Group (ipv6) in the Internet Area has concluded.
The IESG contact persons are Jari Arkko and Mark Townsley.
+++
A new Working Group, 6MAN, has been created to deal with maintenance issues arising in IPv6 specifications. The IPv6 WG is closed. This is an important milestone for IPv6, marking the official closing of the IPv6 development effort.
The ADs would like to thank everyone -- chairs, authors, editors, contributors -- who has been involved in the effort over the years. The IPv6 working group and its predecessor, IPNGWG, produced 79 RFCs (including 5 in the RFC queue).
Issues relating to IPv6 should in the future be taken up in 6MAN if they relate to problems discovered during implementation or deployment; V6OPS if they relate to operational issues; BOF proposals, individual submissions etc. for new functionality.
The mailing list of the IPv6 WG stays alive; the list will still be used by the 6MAN WG in order to avoid people having to resubscribe and/or adjust their mail filters.
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
--Steve Bellovin, http://www.cs.columbia.edu/~smb
You make this sound negative. The IETF has since I have been involved with it had a problem with standing working groups. Some of the "temporary" working groups have taken a huge long time; IPsec lived seven years before it published its first RFC, for example. But in course of time, the IETF says "that phase is over, we're starting a new phase". That's how I read this. We started discussions in 1992, IIRC, with IPNG, which looked at several options and decided on the one we now call IPv6. That set of documents is 25 documents in the range from RFC 1550 (1993) through 1955 (1996) plus documents regarding TUBA, CATNIP, PIP, NIMROD, and the original Deering and Hinden proposals that merged to form IPv6. That working group was called "IP Next Generation". It closed, and an "IPv6" Working Group was opened. The initial development of IPv6 took perhaps five years, starting from the Deering and Hinden proposals (internet drafts) and culminating with a batch of documents in winter 1998-1999, some of which were at Draft Standard (proven functional and interoperable). Those documents, centering around RFC 2460, have been and are IPv6, whatever your opinion of that may be. Like RFC 791, that is the basis. It hasn't been changing, and it's not likely to change. These include the basic IPv6 ICMP, OSPF, Neighbor Discovery, "how to run it on Ethernet etc", address format, and that sort of thing. Since then, the IPv6 WG and several satellite WG including multi6, shim6, and v6ops, has dealt with "topics" more than "protocols" - renumbering, privacy addressing, transition mechanisms, multihoming, and so on - 124 RFCs working through various issues, many of them operational in nature. As I read this statement, it is saying that the working group opened in, what was it, 1995 maybe, has largely done what it was intended to do. There is still work to do, which is why there is an IPv6 Maintenance WG, IPv6 Operations, and a couple of others, but that is not to be confused with the definition work done in the mid-late 1990's or what has gone on the past eight years. To me, the idea that the previous phase is over and we're in a new phase is a positive statement, not a negative one. On Sep 25, 2007, at 5:48 PM, bmanning@vacation.karoshi.com wrote:
true enough. i guess this means that we get IPv6 "as is, where is" and there will be limited new development of same.
--bill
On Tue, Sep 25, 2007 at 06:59:28PM +0000, Steven M. Bellovin wrote:
The subject line is amazing...
Begin forwarded message:
Date: Tue, 25 Sep 2007 14:30:02 -0400 From: IESG Secretary <iesg-secretary@ietf.org> To: ietf-announce@ietf.org Cc: Robert Hinden <bob.hinden@nokia.com>, Brian Haberman <brian@innovationslab.net>, ipv6@ietf.org Subject: WG Action: Conclusion of IP Version 6 (ipv6)
The IP Version 6 Working Group (ipv6) in the Internet Area has concluded.
The IESG contact persons are Jari Arkko and Mark Townsley.
+++
A new Working Group, 6MAN, has been created to deal with maintenance issues arising in IPv6 specifications. The IPv6 WG is closed. This is an important milestone for IPv6, marking the official closing of the IPv6 development effort.
The ADs would like to thank everyone -- chairs, authors, editors, contributors -- who has been involved in the effort over the years. The IPv6 working group and its predecessor, IPNGWG, produced 79 RFCs (including 5 in the RFC queue).
Issues relating to IPv6 should in the future be taken up in 6MAN if they relate to problems discovered during implementation or deployment; V6OPS if they relate to operational issues; BOF proposals, individual submissions etc. for new functionality.
The mailing list of the IPv6 WG stays alive; the list will still be used by the 6MAN WG in order to avoid people having to resubscribe and/or adjust their mail filters.
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
--Steve Bellovin, http://www.cs.columbia.edu/~smb
On Wed, 26 Sep 2007 09:05:22 -0700 Fred Baker <fred@cisco.com> wrote:
You make this sound negative.
I was more amused by the Subject: line -- that IP Version 6 has concluded, rather than the working group... I agree that closing old groups will often -- though not always -- result in focusing on the newer and more important issues, rather than spending time polishing the chrome on the old issues. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On 26-sep-2007, at 18:24, Steven M. Bellovin wrote:
You make this sound negative.
I was more amused by the Subject: line -- that IP Version 6 has concluded, rather than the working group... I agree that closing old groups will often -- though not always -- result in focusing on the newer and more important issues, rather than spending time polishing the chrome on the old issues.
Maybe the IETF should "conclude BGP version 4"? Iljitsch PS. :-)
Steven,
I was more amused by the Subject: line -- that IP Version 6 has concluded, rather than the working group...
The subject line was indeed funny. All IETF WG termination announcements are of this form. I guess we must change the format or stop naming our WGs with the name of a still useful technology :-) Jari
What Fred said is right. Indeed, we closed the working group because it had completed its task. The base is done and its time to move on. That being said, everyone's painfully aware that the Internet isn't complete yet and there are significant challenges ahead. IPv6 -- just like any other technology that we have (SIP, DHCP, ...) doesn't work well in all situations, needs new features, has bugs, etc. And there are many known issues in IPv6, from technical to deployment barriers. For these reasons we already have a set of focused groups (6man, v6ops, rrg/shim6, various IPv6 over Foo WGs, ...) looking at specific problems. If there is a need for more groups, we can create new ones. Jari Fred Baker kirjoitti:
You make this sound negative.
The IETF has since I have been involved with it had a problem with standing working groups. Some of the "temporary" working groups have taken a huge long time; IPsec lived seven years before it published its first RFC, for example. But in course of time, the IETF says "that phase is over, we're starting a new phase". That's how I read this.
We started discussions in 1992, IIRC, with IPNG, which looked at several options and decided on the one we now call IPv6. That set of documents is 25 documents in the range from RFC 1550 (1993) through 1955 (1996) plus documents regarding TUBA, CATNIP, PIP, NIMROD, and the original Deering and Hinden proposals that merged to form IPv6.
That working group was called "IP Next Generation". It closed, and an "IPv6" Working Group was opened.
The initial development of IPv6 took perhaps five years, starting from the Deering and Hinden proposals (internet drafts) and culminating with a batch of documents in winter 1998-1999, some of which were at Draft Standard (proven functional and interoperable). Those documents, centering around RFC 2460, have been and are IPv6, whatever your opinion of that may be. Like RFC 791, that is the basis. It hasn't been changing, and it's not likely to change. These include the basic IPv6 ICMP, OSPF, Neighbor Discovery, "how to run it on Ethernet etc", address format, and that sort of thing.
Since then, the IPv6 WG and several satellite WG including multi6, shim6, and v6ops, has dealt with "topics" more than "protocols" - renumbering, privacy addressing, transition mechanisms, multihoming, and so on - 124 RFCs working through various issues, many of them operational in nature.
As I read this statement, it is saying that the working group opened in, what was it, 1995 maybe, has largely done what it was intended to do. There is still work to do, which is why there is an IPv6 Maintenance WG, IPv6 Operations, and a couple of others, but that is not to be confused with the definition work done in the mid-late 1990's or what has gone on the past eight years.
To me, the idea that the previous phase is over and we're in a new phase is a positive statement, not a negative one.
If there is a need for more groups, we can create new ones.
with all due respect, jari; maybe the number of groups is neither the problem nor the solution too much energy has been and is still being wasted dealing with overly cute/complex ideas these wgs invent to fancy up ipv6 so it will be deployed; from tla/nla/... to ula to sham6. this has prevented focusing on the real problems of deployment so they can be solved. and the unscalable tunneling schemes are making a mess, in architecture, in implementation, in user experience. the latter is causing folk to turn off ipv6. there is a problem that the ivtf is dominated by the very vendors who are holding up deployment by incomplete, poorly performing, expensive to scale products. and adding complexity and features is not helping this either. randy
On Sep 27, 2007, at 2:25 PM, Randy Bush wrote:
there is a problem that the ivtf is dominated by the very vendors who are holding up deployment by incomplete, poorly performing, expensive to scale products. and adding complexity and features is not helping this either.
It's not like the operators aren't welcome. Change that.
It's not like the operators aren't welcome.
fred, you are talking to the guy harald alvestrand, ietf chair, fired. sorry i was so sensitive that it made me feel unwelcome. hint: the operators did not leave because of the bad food. randy
well, if it's any consolation, you're the guy that routinely tells me on public mailing lists that anyone that is not an operator, and especially senior people from vendor companies, is completely clueless on all topics relating to the Internet. I have my days of feeling unwelcome too. Harald was two IETF chairs back. I was three IETF chairs back. You offered repeatedly to resign when you and I worked together, and I always talked you into staying. There, we're even. Now, can we please get constructive? I chair a working group called IPv6 Operations. It's mailing list is hosted on your computer - v6ops@ops.ietf.org. The purpose of the working group is to provide operators, quite a number of which attend, with a place where they can say anything they want and give very clear guidance to the IETF. If the operators have anything to say on the topic, I don't know how much more clearly the IETF can say "we're listening". Crabbing about it doesn't get it fixed. Help us fix it. On Sep 27, 2007, at 2:30 PM, Randy Bush wrote:
It's not like the operators aren't welcome.
fred, you are talking to the guy harald alvestrand, ietf chair, fired. sorry i was so sensitive that it made me feel unwelcome.
hint: the operators did not leave because of the bad food.
randy
I chair a working group called IPv6 Operations.
how droll. does an operator chair the ipv6 vendors group? there sure is a lot of work to be done in that area.
Crabbing about it doesn't get it fixed. Help us fix it.
i am spending a *lot* of my time doing that, see <http://www.civil-tongue.net/clusterf/>. i just don't happen to think the ivtf is a useful place to do so. <http://rip.psg.com/~randy/051000.ccr-ivtf.html> randy
On Sep 27, 2007, at 2:55 PM, Randy Bush wrote:
I chair a working group called IPv6 Operations.
how droll. does an operator chair the ipv6 vendors group? there sure is a lot of work to be done in that area.
no, but m co-chair is an operator - Kurtis Lingqvist. Get constructive.
On 27-sep-2007, at 23:25, Randy Bush wrote:
and the unscalable tunneling schemes are making a mess, in architecture, in implementation, in user experience. the latter is causing folk to turn off ipv6.
So run IPv6 natively and your tunneling issues are history.
there is a problem that the ivtf
IVTF? That sounds like a fertility treatment...
is dominated by the very vendors who are holding up deployment by incomplete, poorly performing, expensive to scale products. and adding complexity and features is not helping this either.
Strange. What I keep hearing is "we can't possibly deploy IPv6 until it has <insert favorite IPv4 feature>". (And then when that feature becomes available somehow IPv6 still isn't deployed.) The simple truth is that IPv6 will be widely deployed as soon as it reduces cost / increases income / enables features that can't be had otherwise. The rest is just details which we generally get 80% right, which makes for an annoying 20% but that's life.
On 27-sep-2007, at 23:57, Randy Bush wrote:
So run IPv6 natively and your tunneling issues are history.
son, get a clue. i work for the first isp on the bleeping planet to deploy native ipv6
I know. I've been following your work for some time now: ,3,Oceania_Gate,Portland_OR,R_Bush,1-503-297-9145,2400,CM,XA
I know. I've been following your work for some time now: ,3,Oceania_Gate,Portland_OR,R_Bush,1-503-297-9145,2400,CM,XA
that's a cheap easy one. the challenge is finding the two uucp bang paths for me before the internet/fidonet, and my arpanet address. randy
Date: Thu, 27 Sep 2007 11:57:07 -1000 From: Randy Bush <randy@psg.com> Sender: owner-nanog@merit.edu
So run IPv6 natively and your tunneling issues are history.
son, get a clue. i work for the first isp on the bleeping planet to deploy native ipv6
I beg to differ. Add the word "commercial" and I might agree. Sitting under my desk is the first system in the US with a production IP address. (No, it's not still running. It's an old DEC Alphstation.) ESnet has run native IPv6 as a fully supported production service for years. Randy is right that eliminating tunnels does not make all of the IPv6 problems go away. It just eliminates the ones caused by the use of tunnels. The REAL problems are not going anywhere for a long time, it ever. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
So run IPv6 natively and your tunneling issues are history. son, get a clue. i work for the first isp on the bleeping planet to deploy native ipv6 I beg to differ. Add the word "commercial" and I might agree.
whoops! <blush> apologies!
eliminating tunnels does not make all of the IPv6 problems go away. It just eliminates the ones caused by the use of tunnels.
in and of itself, this is a good thing. tunnels suck caterpillar snot.
The REAL problems are not going anywhere for a long time, if ever.
indeed, many will be with us for a long time. but there are a bunch we could knock off in a few years o dual stack backbones (and it's as much the vendors as the isps here) o dual stack consumer cpe o routers that hold 2m routes *with churn* from enterprise to backbone o test equipment to differentiate vendor hot air from actual performance o nat-pt with standardized algs for at least dns, smtp, http, sip, and rtp randy
On 9/27/07 7:59 PM, "Randy Bush" <randy@psg.com> wrote:
o nat-pt with standardized algs for at least dns, smtp, http, sip, and rtp
-->> This is on my top 3 hot topics. And make it works both way, v4 to v6 and v6 to v4. And also don¹t call it NAT-PT. That name is dead. - Alain.
Randy, Alain,
o nat-pt with standardized algs for at least dns, smtp, http, sip, and rtp
-->> This is on my top 3 hot topics. And make it works both way, v4 to v6 and v6 to v4. And also don’t call it NAT-PT. That name is dead.
For what it is worth, this is one of the things that I want to do. I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues; I suspect dual stack is a better answer. But nevertheless, the IETF needs to produce a revised spec for the translation case. Fred and I are organizing an effort to do this. Jari
o nat-pt with standardized algs for at least dns, smtp, http, sip, and rtp -->> This is on my top 3 hot topics. And make it works both way, v4 to v6 and v6 to v4. And also don’t call it NAT-PT. That name is dead. For what it is worth, this is one of the things that I want to do.
i took you at your word the other month, so stopped worrying about motivating it. as far as getting it through the ivtf, well, that ain't my job any more. i gave at the office. thank you for accepting the burden.
I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues
heck no. but it will enable folk to have v6-almost-only (except for one ipv4 address) sites in a dual stack and mostly v4 world. it will allow end site transition. randy
On 28-sep-2007, at 6:25, Jari Arkko wrote:
And make it works both way, v4 to v6 and v6 to v4. And also don’t call it NAT-PT. That name is dead.
For what it is worth, this is one of the things that I want to do. I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues; I suspect dual stack is a better answer. But nevertheless, the IETF needs to produce a revised spec for the translation case. Fred and I are organizing an effort to do this.
The problem with NAT-PT (translating between IPv6 and IPv4 similar to IPv4 NAT) was that it basically introduces all the NAT ugliness that we know in IPv4 into the IPv6 world. Rather than "solving" this issue by trying harder, I would like to take the IETF to adopt the following approach: 1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections 2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on- demand over IPv6 The advantage of 1. is that proxies and applications that can use proxies are already in wide use. The advantage of 2. is that it provides real IPv4 connectivity without compromises. Different hosts (even on the same subnet) can have different IPv4 connectivity (NAT/ no NAT, firewalled/unfirewalled) without having to provision the complete path between the user and the edge of the network specifically for that type of connectivity. And no lost addresses for subnetting etc.
Iljitsch, Tunneling is great, but it requires to allocate an IPv4 address... that I may not have in the first place. - Alain. On 9/28/07 4:39 PM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:
On 28-sep-2007, at 6:25, Jari Arkko wrote:
And make it works both way, v4 to v6 and v6 to v4. And also don¹t call it NAT-PT. That name is dead.
For what it is worth, this is one of the things that I want to do. I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues; I suspect dual stack is a better answer. But nevertheless, the IETF needs to produce a revised spec for the translation case. Fred and I are organizing an effort to do this.
The problem with NAT-PT (translating between IPv6 and IPv4 similar to IPv4 NAT) was that it basically introduces all the NAT ugliness that we know in IPv4 into the IPv6 world. Rather than "solving" this issue by trying harder, I would like to take the IETF to adopt the following approach:
1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections
2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on- demand over IPv6
The advantage of 1. is that proxies and applications that can use proxies are already in wide use. The advantage of 2. is that it provides real IPv4 connectivity without compromises. Different hosts (even on the same subnet) can have different IPv4 connectivity (NAT/ no NAT, firewalled/unfirewalled) without having to provision the complete path between the user and the edge of the network specifically for that type of connectivity. And no lost addresses for subnetting etc.
On 28-sep-2007, at 22:57, Alain Durand wrote:
Tunneling is great, but it requires to allocate an IPv4 address... that I may not have in the first place.
If an IPv6-only box is going to talk to the IPv4 world, at some point, the traffic needs to hit a dual stack system that can do the IPv6/IPv4 translation. I think an approach where you have a regular IPv4 NAT and then tunnel the RFC 1918 addresses over an IPv6-only network would work better than NAT-PT. If the tunnel provisioning system is flexible enough, it could even give unNATed IPv4 addresses to (just) the hosts that need them, possibly only temporarily.
On 10/21/07 5:13 PM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:
I think an approach where you have a regular IPv4 NAT and then tunnel the RFC 1918 addresses over an IPv6-only network would work better than NAT-PT.
The issue here is that the translation would have to occur at the box that is decapsulating the packet, as the mapping private-v4 to v4 would have to be indexed by some kind of tunnel ID that identifies the customer. If you translate v4 to v6 at the home gateway, you have a global v6 address to identify that customer and you can do the reverse translation (back to v4) pretty much anywhere you want in the service provider network. - Alain.
On 28-sep-2007, at 23:38, Alain Durand wrote:
On 10/21/07 5:13 PM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:
(sorry about posting from the future, shouldn't mail while experimenting)
I think an approach where you have a regular IPv4 NAT and then tunnel the RFC 1918 addresses over an IPv6-only network would work better than NAT-PT.
The issue here is that the translation would have to occur at the box that is decapsulating the packet, as the mapping private-v4 to v4 would have to be indexed by some kind of tunnel ID that identifies the customer.
Well, if you do both NAT and tunneling, then you need to keep state for both. That's not free, but is it a big issue?
If you translate v4 to v6 at the home gateway, you have a global v6 address to identify that customer and you can do the reverse translation (back to v4) pretty much anywhere you want in the service provider network.
So what I say is: <v4 world> - <NAT> - <tunnel over v6> - <process NATed v4> And what you say is: <v4 world> - <NAT> - <translate to v6> - <forward over native v6> - <translate to v4> - <process NATed v4> Your model has more steps, and it's also more complicated. If you know you're going to go back to v4 anyway, it makes more sense to keep the IPv4 header around and tunnel rather than translate. This doesn't affect the IPv6 processing, because all IPv6 header fields can be the same regardless.
On 9/30/07 2:59 PM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:
So what I say is:
<v4 world> - <NAT> - <tunnel over v6> - <process NATed v4>
And what you say is:
<v4 world> - <NAT> - <translate to v6> - <forward over native v6> - <translate to v4> - <process NATed v4>
Your model has more steps, and it's also more complicated. If you know you're going to go back to v4 anyway, it makes more sense to keep the IPv4 header around and tunnel rather than translate. This doesn't affect the IPv6 processing, because all IPv6 header fields can be the same regardless.
====> Iljitsch, I¹m afraid you characterization is oversimplified. Would you like to have an off-line conversation (phone or maybe at the next NANOG) to go over the details? - Alain
On 1-okt-2007, at 15:25, Alain Durand wrote:
I’m afraid you characterization is oversimplified. Would you like to have an off-line conversation (phone or maybe at the next NANOG) to go over the details?
Sure, if you think that will help. It's unlikely I'll be at the NANOG meeting, though. Also feel free to recommend reading material.
At 11:13 PM +0200 10/21/07, Iljitsch van Beijnum wrote:
... If an IPv6-only box is going to talk to the IPv4 world, at some point, the traffic needs to hit a dual stack system that can do the IPv6/IPv4 translation.
I think an approach where you have a regular IPv4 NAT and then tunnel the RFC 1918 addresses over an IPv6-only network would work better than NAT-PT.
There are companies which would like to be connecting new customers with IPv6 as we approach IPv4 depletion and then handle translation for IPv4 site connectivity in their network i.e. customers connecting to "The Internet" via only IPv6 with the expectation of reaching all Internet destinations (IPv4 and IPv6) without any hassles. While making the backbone networks dual-stack is going to be serious work, it's at least an understandable goal that operators can makes plans to hit. That's not the case with the requirement to provide transparent connectivity to IPv4 destinations via IPv6 transport. NAT-PT wasn't exactly an elegant solution, but it's now precisely what some providers are looking for (so connecting customers via just IPv6 is at least viable). Without it, every provider is going to come up with ad-hoc customer connection models with various IPv4 tunnelling and translation games once IPv4 address blocks become generally unavailable. The irony is that the I* rationale for moving NAT-PT to historic was "to restore the end-to-end transparency of the Internet" and yet the only real chance we have to restore end-to-end transparency is to first have a transition to the IPv6 (using dual-stack, NAT-PT, and every other tool at our disposal) and then over time let present IPv4 destination sites add IPv6 for end-to-end transparency based on their actual need for it. Instead, central planning may have effectively killed the very tool that's needed to allow providers to provision new Internet customers over a pure IPv6-only model, and create the right motivation for existing Internet sites to go dual-stack and actually gain "end to end transparency" via IPv6. /John
John Curran wrote:
There are companies which would like to be connecting new customers with IPv6 as we approach IPv4 depletion and then handle translation for IPv4 site connectivity in their network i.e. customers connecting to "The Internet" via only IPv6 with the expectation of reaching all Internet destinations (IPv4 and IPv6) without any hassles.
In as much as this is the case there will be companies willing (or attempting) to sell something to those companies. Good or bad has nothing to do with it, as past experience has shown, from both inside and outside the networking world. Eliot
If we agree that dual-stack can be only needed in a small part of the network (and in my opinion in all the LANs, until all the applications are IPv6-enabled), then you could use private addresses and softwires (LT2P) for automatic tunneling of protocols that you can't proxy to avoid any new translation protocol, break less things and make it all much simple. I will just add proxies (v4<->v6) for protocols such as http, in order to avoid unnecessarily tunneling traffic that can just be proxied. We have this in real customers, so I know it works. Regards, Jordi
De: John Curran <jcurran@mail.com> Responder a: <owner-nanog@merit.edu> Fecha: Sat, 29 Sep 2007 23:10:24 -0400 Para: Iljitsch van Beijnum <iljitsch@muada.com> CC: <nanog@nanog.org> Asunto: Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 11:13 PM +0200 10/21/07, Iljitsch van Beijnum wrote:
... If an IPv6-only box is going to talk to the IPv4 world, at some point, the traffic needs to hit a dual stack system that can do the IPv6/IPv4 translation.
I think an approach where you have a regular IPv4 NAT and then tunnel the RFC 1918 addresses over an IPv6-only network would work better than NAT-PT.
There are companies which would like to be connecting new customers with IPv6 as we approach IPv4 depletion and then handle translation for IPv4 site connectivity in their network i.e. customers connecting to "The Internet" via only IPv6 with the expectation of reaching all Internet destinations (IPv4 and IPv6) without any hassles.
While making the backbone networks dual-stack is going to be serious work, it's at least an understandable goal that operators can makes plans to hit. That's not the case with the requirement to provide transparent connectivity to IPv4 destinations via IPv6 transport. NAT-PT wasn't exactly an elegant solution, but it's now precisely what some providers are looking for (so connecting customers via just IPv6 is at least viable). Without it, every provider is going to come up with ad-hoc customer connection models with various IPv4 tunnelling and translation games once IPv4 address blocks become generally unavailable.
The irony is that the I* rationale for moving NAT-PT to historic was "to restore the end-to-end transparency of the Internet" and yet the only real chance we have to restore end-to-end transparency is to first have a transition to the IPv6 (using dual-stack, NAT-PT, and every other tool at our disposal) and then over time let present IPv4 destination sites add IPv6 for end-to-end transparency based on their actual need for it. Instead, central planning may have effectively killed the very tool that's needed to allow providers to provision new Internet customers over a pure IPv6-only model, and create the right motivation for existing Internet sites to go dual-stack and actually gain "end to end transparency" via IPv6.
/John
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On 30-sep-2007, at 5:10, John Curran wrote:
The irony is that the I* rationale for moving NAT-PT to historic was "to restore the end-to-end transparency of the Internet" and yet the only real chance we have to restore end-to-end transparency is to first have a transition to the IPv6 (using dual-stack, NAT-PT, and every other tool at our disposal) and then over time let present IPv4 destination sites add IPv6 for end-to-end transparency based on their actual need for it. Instead, central planning may have effectively killed the very tool that's needed to allow providers to provision new Internet customers over a pure IPv6-only model, and create the right motivation for existing Internet sites to go dual-stack and actually gain "end to end transparency" via IPv6.
In my opinion, the mistake the IETF made was to "deprecate" NAT-PT without coming up with an alternative first. Originally, my thinking was "sure, NAT-PT doesn't work with everything unless you have ALGs for a good number of protocols, but it gives you 80% of what you need so it's a good start". But I've come to see how having IPv6 applications expect end-to-end IPv6 connectivity and then have that rug pulled from under them will inevitably lead to the same lack of end-to-end transparency in IPv6 that we currently have with IPv4. And once that can is open, it's unlikely we can get the worms to crawl back inside later. But proxying can be that 80% solution and tunneling IPv4 over IPv6 can be a 100% solution so we don't have to raise NAT-PT from the dead.
At 9:30 PM +0200 9/30/07, Iljitsch van Beijnum wrote:
On 30-sep-2007, at 5:10, John Curran wrote:
The irony is that the I* rationale for moving NAT-PT to historic was "to restore the end-to-end transparency of the Internet" and yet the only real chance we have to restore end-to-end transparency is to first have a transition to the IPv6 (using dual-stack, NAT-PT, and every other tool at our disposal) and then over time let present IPv4 destination sites add IPv6 for end-to-end transparency based on their actual need for it. Instead, central planning may have effectively killed the very tool that's needed to allow providers to provision new Internet customers over a pure IPv6-only model, and create the right motivation for existing Internet sites to go dual-stack and actually gain "end to end transparency" via IPv6.
In my opinion, the mistake the IETF made was to "deprecate" NAT-PT without coming up with an alternative first.
Agreed. Lucklily, it got spec'd and it's now a question of what ISP's want and what vendors feel like making money.
Originally, my thinking was "sure, NAT-PT doesn't work with everything unless you have ALGs for a good number of protocols, but it gives you 80% of what you need so it's a good start". But I've come to see how having IPv6 applications expect end-to-end IPv6 connectivity and then have that rug pulled from under them will inevitably lead to the same lack of end-to-end transparency in IPv6 that we currently have with IPv4. And once that can is open, it's unlikely we can get the worms to crawl back inside later.
I disagree with that view... There's no reason why NAT-PT for access to legacy IPv4 sites implies anything about the connectivity model for IPv6. As noted above, it's *lack* of NAT-PT that will cause ISP's to avoid a connecting customers with a pure IPv6 model, since that isn't enough for full Internet connectivity in the absence of NAT-PT. /John
On 9/29/07 11:10 PM, "John Curran" <jcurran@mail.com> wrote:
The irony is that the I* rationale for moving NAT-PT to historic was "to restore the end-to-end transparency of the Internet"
===> John,
With all due respect, I will recommend you to read 4966, reasons to move NAT-PT to historical
Abstract
This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status.
- Alain.
At 9:20 AM -0400 10/1/07, Alain Durand wrote:
On 9/29/07 11:10 PM, "John Curran" <jcurran@mail.com> wrote: The irony is that the I* rationale for moving NAT-PT to historic was "to restore the end-to-end transparency of the Internet"
===> John,
With all due respect, I will recommend you to read 4966, reasons to move NAT-PT to historical
Alain - No offense taken. The full quote in context is: "One of the major design goals for IPv6 is to restore the end-to-end transparency of the Internet" It's actually the first line of section 5 of RFC 4966. While quite a bit of the document covers the difficultly in doing NAT-PT correctly, the only reason given why it's actually undesirable is that statements at the start of section 5. The sentence which follows begins as such: "Therefore, because IPv6 may be expected to remove the need for NATs and similar impediments to transparency, ..." The paper argues heavily that NAT-PT is a mistake because it gets in the way of IPv6 developers building applications which require end-to-end transparency. The conclusion, in particular, is quite telling: "The potential constraints on the development of IPv6 applications described in Section 5 are particularly undesirable. " I have a lot of sympathy for those all those IPv6 application developers who are constrained by the potential NAT-PT gateways in their way, but they're likely to be constrained in any case if the other end is IPv4 and not moving to IPv6 anytime soon... Furthermore, if we don't have a semitransparent way of giving IPv6-only new customers a modicum of connectivity to existing web and email addresses, the IPv6 community may find themselves with a much bigger impediment to transparency: the proliferation of IPv4 NATs and no adoption of IPv6. Hence the confusion over the conclusion that the impact of NAT-PT on the end-to-end model is so undesirable that we need to limit deployment of it (despite the fact that it allows a viable method of connecting new customers via pure IPv6 and an eventual return to a model which is a lot closer to the desired end-state of one protocol end-to-end). /John
At 04:39 PM 9/28/2007, Iljitsch van Beijnum wrote:
On 28-sep-2007, at 6:25, Jari Arkko wrote:
And make it works both way, v4 to v6 and v6 to v4. And also don't call it NAT-PT. That name is dead.
For what it is worth, this is one of the things that I want to do. I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues; I suspect dual stack is a better answer. But nevertheless, the IETF needs to produce a revised spec for the translation case. Fred and I are organizing an effort to do this.
The problem with NAT-PT (translating between IPv6 and IPv4 similar to IPv4 NAT) was that it basically introduces all the NAT ugliness that we know in IPv4 into the IPv6 world.
NAT grew out of need. It didn't grow up in the IETF. We did have a NAT WG, to document, define common terminology and guidelines. We took a lot of heat for just documenting what was out there. The marketplace resulted in the success of NAT. Even if there had been limitless address space, it's unlikely NAT would have been avoided.
Rather than "solving" this issue by trying harder, I would like to take the IETF to adopt the following approach:
1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections
So your fobia over all things NAT is so deep that you would insist on the use of a SOCKS-like mechanism, breaking end-to-end connectivity, to avoid implementing NAT of any sort. Pardon me for thinking this is a stretch.
2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on- demand over IPv6
Add more devices in the path, resulting in a tortured "end-2-end" that has lots of points of failure, and lots of state in the network for those tunnel endpoints, timeouts on same, etc. I fail to see how your proposals preserve the end-to-end nature of the Internet in any meaningful way. You've gone a long way to find something, anything, that can take the place of NAT, but in so doing, you've proposed solutions which do not appreciably differ in effect on the function of the Internet.
NAT grew out of need. It didn't grow up in the IETF. We did have a NAT WG, to document, define common terminology and guidelines. We took a lot of heat for just documenting what was out there. The marketplace resulted in the success of NAT. Even if there had been limitless address space, it's unlikely NAT would have been avoided.
nat is not a technology, it is the anti-$deity, at least to some. the ivtf loves to throw out multiple confusing and competing technologies and say "let the market decide." but it somehow has had very deaf ears when the market decided nat in a very big way. this is not to say i would want a nat to marry my brother! but, ome months back, some wiser heads in the ivtf listened and agreed that nat-pt (no, alain, i will not be silly and let people force me to confuse things by calling it something else), is seriously required even though it is disgusting to us all. thank you russ and jari; and i am sure others will climb on the bandwagon and wave flags. the alternatives are more disgusting, and lack of nat-pt is a serious impediment to ipv6 deployment, a critical one in a world of ipv4 address space scarcity. for an example of the problems of public proxies, as Jeffrey Streifling said (in http://www.civil-tongue.net/clusterf/ wiki), o Email/SMTP is a mandatory application o Everyone needs to be able to send email to arbitrary recipients, i.e. everyone else o But, due to SPAM, no one can run an open SMTP relay o So all IPv6 sites need to have the ability to SMTP to arbitrary IPv4 sites o Therefore everyone needs private dual stack relay until the world is all dual stack SMTP randy
On 9/28/07 8:46 PM, "Randy Bush" <randy@psg.com> wrote:
but, ome months back, some wiser heads in the ivtf listened and agreed that nat-pt (no, alain, i will not be silly and let people force me to confuse things by calling it something else), is seriously required even though it is disgusting to us all. thank you russ and jari; and i am sure others will climb on the bandwagon and wave flags.
---> I do not care so much how people want to call this, as long as it is understood that this should not only solve the v6->v4 case but also the other way round for the reasons I mentioned this morning.
As about liking NAT or not, honestly, this is totally beside the point. I have real problems to solve.
- Alain.
On 29-sep-2007, at 2:11, Daniel Senie wrote:
The problem with NAT-PT (translating between IPv6 and IPv4 similar to IPv4 NAT) was that it basically introduces all the NAT ugliness that we know in IPv4 into the IPv6 world.
NAT grew out of need. It didn't grow up in the IETF. We did have a NAT WG, to document, define common terminology and guidelines. We took a lot of heat for just documenting what was out there. The marketplace resulted in the success of NAT. Even if there had been limitless address space, it's unlikely NAT would have been avoided.
And how exactly does that relate to the discussion at hand? For the purpose of this particular discussion, NAT in IPv4 is basically a given: coming up with an IPv4-IPv6 transition mechanism that only works with if no IPv4 NAT is present both defeats the purpose (if we had that kind of address space we wouldn't have a problem in the first place) and it's completely unrealistic. The issue is that introducing NAT in IPv6, even if it's only in the context of translating IPv6 to IPv4, for a number of protocols, requires ALGs in the middle and/or application awareness. These things don't exist in IPv6, but they do exist in IPv4. So it's a better engineering choice to have IPv4 NAT than IPv6 NAT.
1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections
So your fobia over all things NAT is so deep that you would insist on the use of a SOCKS-like mechanism, breaking end-to-end connectivity, to avoid implementing NAT of any sort. Pardon me for thinking this is a stretch.
I don't see the problem with proxying, except that it only works for TCP. Yes, you need a box in the middle, but that's true of any solution where you have an IPv6-only host talk to an IPv4-only host. If both sides use a dual stack proxy, it's even possible to use address-based referrals. E.g., the IPv4 host asks the proxy to set up a session towards 2001:db8:31::1 and voila, the IPv4 host can talk to the IPv6 internet. Not possible with a NAT-PT like solution.
2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on- demand over IPv6
Add more devices in the path, resulting in a tortured "end-2-end" that has lots of points of failure, and lots of state in the network for those tunnel endpoints, timeouts on same, etc.
Apparently these downsides aren't big enough to stop the use of PPPoE. The advantage is that you can have an IPv6-only routed network. This at the very least avoids having to provision both protocols throughout the network, and probably avoids a lot more complexity that is necessary in typical IPv4 networks (NAT hole punching etc).
I fail to see how your proposals preserve the end-to-end nature of the Internet in any meaningful way. You've gone a long way to find something, anything, that can take the place of NAT, but in so doing, you've proposed solutions which do not appreciably differ in effect on the function of the Internet.
Tunneling IPv4 over IPv6 is a lot cleaner than translating between the two. It preserves IPv4 end-to-end. :-) This can indeed be used to avoid NAT if you use public IPv4 addresses, but it's also the solution that incurs the least amount of NAT issues if you don't, because those issues stay in IPv4 where they're well known. PS. someone told me that work on tunneling IPv4 over IPv6 is under way in the IETF under the name "softwires".
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
For the purpose of this particular discussion, NAT in IPv4 is basically a given: coming up with an IPv4-IPv6 transition mechanism that only works with if no IPv4 NAT is present both defeats the purpose (if we had that kind of address space we wouldn't have a problem in the first place) and it's completely unrealistic.
The issue is that introducing NAT in IPv6, even if it's only in the context of translating IPv6 to IPv4, for a number of protocols, requires ALGs in the middle and/or application awareness. These things don't exist in IPv6, but they do exist in IPv4. So it's a better engineering choice to have IPv4 NAT than IPv6 NAT.
Of course ALGs will exist in IPv6: they'll be needed for stateful firewalls, which aren't going away in even the most optimistic ideas of what an IPv6-only network will look like.
I don't see the problem with proxying, except that it only works for TCP. Yes, you need a box in the middle, but that's true of any solution where you have an IPv6-only host talk to an IPv4-only host. If both sides use a dual stack proxy, it's even possible to use address-based referrals. E.g., the IPv4 host asks the proxy to set up a session towards 2001:db8:31::1 and voila, the IPv4 host can talk to the IPv6 internet. Not possible with a NAT-PT like solution.
Only one side needs to proxy/translate; if both sides have a device to do it, one of them will not be used. Better, if both sides support the same version (either v4 or v6), that would be used without any proxying or translating at all.
Tunneling IPv4 over IPv6 is a lot cleaner than translating between the two. It preserves IPv4 end-to-end. :-)
And when we run out of v4 addresses in a few years, what do you propose we do? It makes little sense to tunnel v4 over v6 until v6 packets become the majority on the backbones -- and the only way that'll happen is if everyone dual-stacks or is v6-only. If everyone has v6 connectivity, then why do we need to route v4 anymore, even over tunnels? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
On 28-sep-2007, at 6:25, Jari Arkko wrote:
And make it works both way, v4 to v6 and v6 to v4. And also don’t call it NAT-PT. That name is dead.
For what it is worth, this is one of the things that I want to do. I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues; I suspect dual stack is a better answer. But nevertheless, the IETF needs to produce a revised spec for the translation case. Fred and I are organizing an effort to do this.
The problem with NAT-PT (translating between IPv6 and IPv4 similar to IPv4 NAT) was that it basically introduces all the NAT ugliness that we know in IPv4 into the IPv6 world.
There is no "IPv6 world". I've heard reference over and over to how developers shouldn't add "NAT support" into v6 apps, but the reality is that there are no "v6 apps". There are IPv4 apps and IP apps that are version agnostic. The NAT code is there and waiting to be used whether the socket underneath happens to be v4 or v6 at any given time. Yes, ideally the NAT code wouldn't get used if the socket were v6. The other thing is NAT is only a small fraction of the problem; most of the same code will be required to work around stateful firewalls even in v6.
Rather than "solving" this issue by trying harder, I would like to take the IETF to adopt the following approach:
1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections
2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on-demand over IPv6
Neither solves the problem of v6-only hosts talking to v4-only hosts. The fundamental flaw in the transition plan is that it assumes every host will dual-stack before the first v6-only node appears. At this point, I think we can all agree it's obvious that isn't going to happen. NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost. It allows v6-only hosts to appear even if there still remain hosts that are v4-only, as long as one end or the other has a NAT-PT box. The chicken and egg problem is _solved_. When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally. The alternative is that everyone just deploys multi-layered v4 NAT boxes and v6 dies with a whimper. Tell me, which is the lesser of the two evils? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
At 12:56 PM -0500 10/1/07, Stephen Sprunk wrote:
... The fundamental flaw in the transition plan is that it assumes every host will dual-stack before the first v6-only node appears. At this point, I think we can all agree it's obvious that isn't going to happen.
NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost. It allows v6-only hosts to appear even if there still remain hosts that are v4-only, as long as one end or the other has a NAT-PT box. The chicken and egg problem is _solved_. When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally.
The alternative is that everyone just deploys multi-layered v4 NAT boxes and v6 dies with a whimper. Tell me, which is the lesser of the two evils?
Stephen - Very well said... Now the more interesting question is: Given that we're going to see NAT-PT in a lot of service provider architectures to make deploying IPv6 viable, should it be considered a general enough transition mechanism to be Proposed Standard or just be a very widely deployed Historic protocol? Oh wait, wrong mailing list... ;-) /John
On Mon, 01 Oct 2007 14:39:16 EDT, John Curran said:
Now the more interesting question is: Given that we're going to see NAT-PT in a lot of service provider architectures to make deploying IPv6 viable, should it be considered a general enough transition mechanism to be Proposed Standard or just be a very widely deployed Historic protocol?
"Historic" usually refers to "stuff we've managed to mostly stamp out production use". So it boils down to "Do you think that once that camel has gotten its nose into the tent, he'll ever actually leave?". (Consider that if (for example) enough ISPs deploy that sort of migration tool, then Amazon has no incentive to move to IPv6, and then the ISP is stuck keeping it around because they don't dare turn off Amazon).
At 3:11 PM -0400 10/1/07, Valdis.Kletnieks@vt.edu wrote:
So it boils down to "Do you think that once that camel has gotten its nose into the tent, he'll ever actually leave?".
(Consider that if (for example) enough ISPs deploy that sort of migration tool, then Amazon has no incentive to move to IPv6, and then the ISP is stuck keeping it around because they don't dare turn off Amazon).
If indeed one believes that's there more functionality for having end-to-end IPv6, then presumably their competitors will roll out services which make use of these capabilities, and Amazon will feel some pressure to follow. Operating through NAT-PT is not very exciting and it's not going to take much (e.g. quality video support) to cause major content providers to want to have native end-to-end communication. Amazingly, it creates an actual motivation for existing IPv4 content sites to considering adding IPv6 support, which is something we've lacked to date. /John
Thus spake <Valdis.Kletnieks@vt.edu>
"Historic" usually refers to "stuff we've managed to mostly stamp out production use".
So it boils down to "Do you think that once that camel has gotten its nose into the tent, he'll ever actually leave?".
This particular camel will be here until we manage to get v4 turned off, regardless of what status the IETF dogmatists assign it. Once that happens, though, there will be no need for NAT-PT anymore :-)
(Consider that if (for example) enough ISPs deploy that sort of migration tool, then Amazon has no incentive to move to IPv6, and then the ISP is stuck keeping it around because they don't dare turn off Amazon).
That depends. If Amazon sees absolutely no ill effects from v6 users reaching it via v4, then they obviously have little technical incentive to migrate. OTOH, if that is true, then all the whining about how "evil" NAT-PT is is obviously bunk. We can't have it both ways, folks: either NAT-PT breaks things and people would move to native v6 to get away from it, or NAT-PT doesn't break things and there's no reason not to use it. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Mon, Oct 01, 2007 at 09:18:43PM -0500, Stephen Sprunk wrote:
That depends. If Amazon sees absolutely no ill effects from v6 users reaching it via v4, then they obviously have little technical incentive to migrate. OTOH, if that is true, then all the whining about how "evil" NAT-PT is is obviously bunk. We can't have it both ways, folks: either NAT-PT breaks things and people would move to native v6 to get away from it, or NAT-PT doesn't break things and there's no reason not to use it.
The IPv4 Internet has been awash with dodgy NATs that negatively affect functionality ever since NAT arrived on the scene. What has happened? Well, application protocols have evolved to accommodate NAT weirdness (e.g., SIP NAT discovery), and NATs have undergone incremental improvements, and almost no end-users care about NATs. As long as they can use the Google, BitTorrent and Skype, most moms and dads neither know nor care about any technical impediments NATs erect between them and their enjoyment of the Internet. There's no rational reason to believe that NAT-PT would be any different. If NAT-PT breaks stuff, it'll get improved. It'll keep getting better until we don't need it anymore (or forever, whichever comes first) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
What has happened? Well, application protocols have evolved to accommodate NAT weirdness (e.g., SIP NAT discovery), and NATs have undergone incremental improvements, and almost no end-users care about NATs. As long as they can use the Google, BitTorrent and Skype, most moms and dads neither know nor care about any technical impediments NATs erect between them and their enjoyment of the Internet.
Except every service that used to work using direct TCP connections has either moved to UDP, or moved towards having unNATted boxes that people can relay through. While NAT traversal for TCP is theoretically possible, it relies on rarely used features of TCP (Simultaneous open) and good timing, both of which are likely to cause issues. I've never heard of a successful real world application successfully doing this. (Feel free to educate me if you know of a realworld application in common use that does do TCP NAT traversal and has it work a significant amount of the time). Even p2p apps like bittorrent rely on the fact that there are /some/ people /somewhere/ in the swarm that have either configured their NAT to allow pinholing or don't have any NAT between them and the Internet. Plastered everywhere over anything P2P filetransfer related is "poor performance? Add a pinhole to your NAT box!" suggesting quite strongly that NAT is causing large problems for P2P swarms. NAT is hurting applications today, and applications aren't getting deployed (or even written) because of problems NAT causes.
On Tue, Oct 02, 2007 at 10:35:11PM +1300, Perry Lorier wrote:
What has happened? Well, application protocols have evolved to accommodate NAT weirdness (e.g., SIP NAT discovery), and NATs have undergone incremental improvements, and almost no end-users care about NATs. As long as they can use the Google, BitTorrent and Skype, most moms and dads neither know nor care about any technical impediments NATs erect between them and their enjoyment of the Internet. [ ... ] While NAT traversal for TCP is theoretically possible, it relies on rarely used features of TCP (Simultaneous open) and good timing, both of which are likely to cause issues.
You're talking about inbound (from the Internet to the client) traversal, right? Because outbound is trivial :-)
I've never heard of a successful real world application successfully doing this. (Feel free to educate me if you know of a realworld application in common use that does do TCP NAT traversal and has it work a significant amount of the time).
By focussing on the mechanics of inbound NAT traversal, you're ignoring the fact that applications work regardless. Web, VoIP, P2P utilities, games, IM, Google Earth, you name it, it works. On the ADSL network my employer operates, the number of customers who use NAT (because it's enabled by default on their CPE and they don't know or care enough to turn it off) is somewhere north of 95%. The Internet works. Nobody cares about NAT. Yes, it means that some classes of protocol (which rely on full P2P visibility) don't happen; But they aren't going to happen _anyway_, because NAT or no NAT firewalls remain a reality, and inbound firewall traversal is every bit as problematic as inbound NAT traversal. Like it or not, we don't really have a peer-to-peer Internet anymore. Not like we used to in the good ol' days when everyone had a globally routed IP address and nobody used firewalls.
NAT is hurting applications today, and applications aren't getting deployed (or even written) because of problems NAT causes.
Meanwhile, IPv6 advocates who don't like NAT are hurting IPv6 deployment today by waving their arms in the air and bitching about NAT. That makes life difficult, because their advocacy is removing tools (such as NAT-PT) which we could use to facilitate and hasten an IPv6 rollout. Throughout IPv6's history, and IPng's history before that, lots of disparate problem domains have been bundled together as things that the new protocol _must_ solve. IPv6 solves the 32-bit-address-space-is-too-small problem. That's all it does. So we've been able to run IPv6 for years, except IPv6 is also supposed to solve the bgp-table-is-too-big problem by (until recently) banning PI address space by non-ISPs and focussing attention on vaporware like SHIM6, so non-ISPs have yawned instead of deploying it; and IPv6 is also supposed to solve the security problem, so years were wasted defining mandatory IPSEC which isn't really mandatory; and IPv6 is also supposed to solve the mobility problem, so more years were wasted working out option headers and all measure of other crap needed to support mobile-IPv6; Now IPv6 is supposed to solve the we-want-a-p2p-internet-all-over-again problem by making NAT go away, and anti-NAT purists have spent their energy having NAT proposals for v6 written out of the standards, and oppose various deployment scenarios by saying, "You can't possibly do that beacuse you'll (re)break end-to-end, and that isn't allowed in an IPv6 universe!" While all this dicking around has been happening, the vendors have been cooling their heels waiting for sufficient amounts of consensus to make it worth their while to release the mass-market CPE with v6 support that we'll need to drive mass-market adoption of the new protocol. Protocol purists hold the whole process to ransom with their aesthetic sensibilities, and every year of delay is another year that'll pass before grandma can go down to Frys and buy a DLink ADSL modem with IPv6 support. And until grandma has a native IPv6 IP address, all the table-thumping in the world about end-to-end reachability ain't worth beans. In a _rational_ world, we would have said, "We have a pressing problem, that of v4 exhaustion, so lets build a protocol that solves that, and maybe after we've passed that speed-bump we can fit mobility, security, end-to-end visibility, routing table controls, etc into the new framework." So, a reality check: IPv6 will happen. Eventually. And it'll have deficiencies which some believe are "severe", just like the IPv4 Internet. Such as NAT. Deal with it. Throughout its history, the Internet has advanced by applying less-than-optimal solutions to the most pressing problems of the time, then going back and fixing it later when the heat has died down if the suboptimal solutions create their own new problems. If you believe that v4 exhaustion is a pressing problem, then I'd humbly suggest that 2007 is a good time to shut the hell up about how bad NAT is and get on with fixing the most pressing problem. If we're successful, there'll be plenty of time to go back and re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On 2-okt-2007, at 16:53, Mark Newton wrote:
By focussing on the mechanics of inbound NAT traversal, you're ignoring the fact that applications work regardless. Web, VoIP, P2P utilities, games, IM, Google Earth, you name it, it works.
O really? When was the last time you successfully transferred a file using IM? It only works half the time for me and I don't even use NAT on my main system myself. Some audio/video chat applications work well, others decidedly less so. The only reason most stuff works most of the time is because applications tell NAT devices to open up incoming ports using uPnP or NAT-PMP.
IPv6 will happen. Eventually. And it'll have deficiencies which some believe are "severe", just like the IPv4 Internet. Such as NAT. Deal with it.
If you want NAT, please come up with a standards document that describes how it works and how applications can work around it. Just implementing it and letting the broken applications fall where they may is so 1990s.
If you believe that v4 exhaustion is a pressing problem, then I'd humbly suggest that 2007 is a good time to shut the hell up about how bad NAT is and get on with fixing the most pressing problem.
"NAT is not a problem" and "running out of IPv4 address space is a problem" can't both be true at the same time. With enough NAT lubrication you can basically extend the IPv4 address space by 16 bits so you don't need IPv6.
If we're successful, there'll be plenty of time to go back and re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory.
Right. Building something that can't meet reasonable requirements first and then getting rid of the holes worked so well for the email spam problem.
On Tue, Oct 02, 2007, Iljitsch van Beijnum wrote:
On 2-okt-2007, at 16:53, Mark Newton wrote:
By focussing on the mechanics of inbound NAT traversal, you're ignoring the fact that applications work regardless. Web, VoIP, P2P utilities, games, IM, Google Earth, you name it, it works.
O really? When was the last time you successfully transferred a file using IM? It only works half the time for me and I don't even use NAT on my main system myself. Some audio/video chat applications work well, others decidedly less so. The only reason most stuff works most of the time is because applications tell NAT devices to open up incoming ports using uPnP or NAT-PMP.
"Ah, god damn Microsoft MSN client. Just send it via gmail already." People deal with slightly broken crap all day, every day. If they had a low tolerance for it then we'd be running OSF/1+Motif on multi-core Alphas cause Windows on whiteboxes wouldn't have cut the mustard.
Right. Building something that can't meet reasonable requirements first and then getting rid of the holes worked so well for the email spam problem.
Ah, but: * y'all didn't know what were reasonable requirements when SMTP was built; and * You're not trying to do a forklift upgrade of SMTP protocol (which, arguably, would include reasonable anti-spam methods!) Whereas: * Y'all know the issues involved in migrating from ipv4 to ipv6, as you've got operational experience with both now, and * You're trying to do a forklift upgrade of the IP protocol. Adrian
On Tue, Oct 02, 2007 at 10:07:19PM +0200, Iljitsch van Beijnum wrote:
IPv6 will happen. Eventually. And it'll have deficiencies which some believe are "severe", just like the IPv4 Internet. Such as NAT. Deal with it.
If you want NAT, please come up with a standards document that describes how it works and how applications can work around it. Just implementing it and letting the broken applications fall where they may is so 1990s.
Ah, how obstructive of you. "We can't possibly do this until a multi-volume standards document has been written which encompasses and solves every conceivable problem with absolute perfection. Have it on my desk by 5pm." No, that's not how we do things on the Internet. It _is_ how they do things on those old-school telco networks you keep telling us to avoid emulating, but it's not our way. Never has been, likely never will be (and, indeed, I'd put it to you that the reason we're all talking about IPv6 in 2007 instead of _using_ it is because the IETF tried the old-school way instead of the Internet way to solve the running-out-of-addresses problem)
If you believe that v4 exhaustion is a pressing problem, then I'd humbly suggest that 2007 is a good time to shut the hell up about how bad NAT is and get on with fixing the most pressing problem.
"NAT is not a problem" and "running out of IPv4 address space is a problem" can't both be true at the same time. With enough NAT lubrication you can basically extend the IPv4 address space by 16 bits so you don't need IPv6.
Don't you think that's a bit of an oversimplification? With respect, Iljitsch, if you want a "long and bloody argument" about IPv6 NAT, and you engineer one by constructing straw men to argue against, my guess is that the blood on the walls at the end of the process will be yours.
If we're successful, there'll be plenty of time to go back and re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory.
Right. Building something that can't meet reasonable requirements first and then getting rid of the holes worked so well for the email spam problem.
My email works. How about yours? - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
At 04:07 PM 10/2/2007, Iljitsch van Beijnum wrote:
On 2-okt-2007, at 16:53, Mark Newton wrote:
By focussing on the mechanics of inbound NAT traversal, you're ignoring the fact that applications work regardless. Web, VoIP, P2P utilities, games, IM, Google Earth, you name it, it works.
O really? When was the last time you successfully transferred a file using IM? It only works half the time for me and I don't even use NAT on my main system myself. Some audio/video chat applications work well, others decidedly less so. The only reason most stuff works most of the time is because applications tell NAT devices to open up incoming ports using uPnP or NAT-PMP.
By policy, I generally block file transfer over IM at security boundaries where possible, whether NAT is in use. End users on corporate networks do not need to be using IM as a file transfer mechanism.
IPv6 will happen. Eventually. And it'll have deficiencies which some believe are "severe", just like the IPv4 Internet. Such as NAT. Deal with it.
If you want NAT, please come up with a standards document that describes how it works and how applications can work around it.
Been there, and done that. Please go read RFC 3235, and read the other RFCs that came out of the NAT Working Group in the IETF. This WG documented how things worked, and how to write apps and such. NAT itself had been in widespread use for a long time before, though implementations varied in both function and terminology. Having a common point of reference, and recommendations for living with it seemed to many like a good idea. It appears the documents have not been widely read.
Just implementing it and letting the broken applications fall where they may is so 1990s.
If you believe that v4 exhaustion is a pressing problem, then I'd humbly suggest that 2007 is a good time to shut the hell up about how bad NAT is and get on with fixing the most pressing problem.
"NAT is not a problem" and "running out of IPv4 address space is a problem" can't both be true at the same time. With enough NAT lubrication you can basically extend the IPv4 address space by 16 bits so you don't need IPv6.
Running out of address space may well have been a problem a decade ago without NAT. You and I don't know, largely because none of us really knows how many computers are behind NAT boxes today. But the IETF was not ready to provide a replacement for IPv4 at the time. So NAT bought the IP protocol stack enough time to dominate the marketplace.
If we're successful, there'll be plenty of time to go back and re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory.
Right. Building something that can't meet reasonable requirements first and then getting rid of the holes worked so well for the email spam problem.
This is a rather disingenuous argument. You might look at the history of TCP, which has had several tweaks over the years as more was learned. In trying to have every duck perfectly in a row, IPv6 is quite late to the party. Even NASA launches deep space probes before operational software is finished, and updates it in flight... (OK, so maybe that's a bad example, given math errors and a certain crash on mars).
On 3-okt-2007, at 18:54, Daniel Senie wrote:
it works.
O really? When was the last time you successfully transferred a file using IM?
By policy, I generally block file transfer over IM at security boundaries
What does that have to do with anything? It still doesn't work reliably, or even most of the time. That it's not something you want or need makes this irrelevant for you but it doesn't make NAT work.
If you want NAT, please come up with a standards document that describes how it works and how applications can work around it.
Been there, and done that. Please go read RFC 3235
I was done reading the IPv6 section very quickly... Nice start, but it only provides some obvious guidelines to protocol designers, this isn't good enough to base the architecture of the entire network on.
If we're successful, there'll be plenty of time to go back and re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory.
Right. Building something that can't meet reasonable requirements first and then getting rid of the holes worked so well for the email spam problem.
This is a rather disingenuous argument. You might look at the history of TCP, which has had several tweaks over the years as more was learned. In trying to have every duck perfectly in a row, IPv6 is quite late to the party. Even NASA launches deep space probes before operational software is finished, and updates it in flight...
The crucial difference is that there is an upgrade path. There is no upgrade path from a network with NAT to a network where you don't have to work around NAT. That's why it's so important to keep the NAT in IPv4 and not let it sneak into IPv6.
On Thu, Oct 04, 2007 at 10:37:22AM +0200, Iljitsch van Beijnum wrote:
The crucial difference is that there is an upgrade path. There is no upgrade path from a network with NAT to a network where you don't have to work around NAT. That's why it's so important to keep the NAT in IPv4 and not let it sneak into IPv6.
Most of us debating this with you _don't care_ if NAT happens to exist on the IPv6 Internet. It's on the IPv4 Internet and we still manage to use the network for the things we want to use it for, so we're mounting an empirical case to say that portrayal of NAT that you're presenting is false. Basically, your argument boils down to aesthetics. You don't like NAT. You want it to go away. Fine, I don't like it either and I wouldn't mind if it went away... But funnily enough, I can remember having exactly these same arguments with people about IPv4 NAT. And y'know what? They didn't make a lick of difference, because NAT could be (and was) deployed unilaterally, without any semblance of global coordination. {Your|My} aesthetic sense isn't actually in charge here. Moan about it all you want, but it's _inevitable_ that every tool in the toolbox, including NAT-PT, will be used to smooth-over IPv6 adoption challenges. And if you don't like it, you're just gonna have to cope. Your alternatives are: - NAT-PT with well-understood standards and operational guidelines aimed at maximizing interoperability; and - NAT-PT without well-understood standards and operational guidelines, where interoperability is a flukish crapshoot, where random stuff just fails to work because there are no agreed-upon ways to use application awareness at layer-4 to work around breakage. In that universe, where you have to pick one, which one would you rather see in widespread deployment? And if it's the first alternative, what kind of results do you think you'll get by opposing efforts to develop standards for NAT? - mark [ wondering how long it'll be before I'll be able to buy a CEF- accelerated TCAM-equipped layer-4 switching blade for a 7600 :-) ] -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On Oct 4, 2007, at 4:56 AM, Mark Newton wrote:
On Thu, Oct 04, 2007 at 10:37:22AM +0200, Iljitsch van Beijnum wrote:
The crucial difference is that there is an upgrade path. There is no upgrade path from a network with NAT to a network where you don't have to work around NAT. That's why it's so important to keep the NAT in IPv4 and not let it sneak into IPv6.
Most of us debating this with you _don't care_ if NAT happens to exist on the IPv6 Internet. It's on the IPv4 Internet and we still manage to use the network for the things we want to use it for, so we're mounting an empirical case to say that portrayal of NAT that you're presenting is false.
Plus, it may give you a legal defense ! In this trial http://blog.wired.com/27bstroke6/2007/10/riaa-testimony-.html her defense basically boil down to, because my home network was NATed, who knows who was using that IP address ? Regards (with tongue firmly in cheek) Marshall
Basically, your argument boils down to aesthetics. You don't like NAT. You want it to go away. Fine, I don't like it either and I wouldn't mind if it went away...
But funnily enough, I can remember having exactly these same arguments with people about IPv4 NAT. And y'know what? They didn't make a lick of difference, because NAT could be (and was) deployed unilaterally, without any semblance of global coordination.
{Your|My} aesthetic sense isn't actually in charge here. Moan about it all you want, but it's _inevitable_ that every tool in the toolbox, including NAT-PT, will be used to smooth-over IPv6 adoption challenges. And if you don't like it, you're just gonna have to cope.
Your alternatives are:
- NAT-PT with well-understood standards and operational guidelines aimed at maximizing interoperability; and
- NAT-PT without well-understood standards and operational guidelines, where interoperability is a flukish crapshoot, where random stuff just fails to work because there are no agreed-upon ways to use application awareness at layer-4 to work around breakage.
In that universe, where you have to pick one, which one would you rather see in widespread deployment? And if it's the first alternative, what kind of results do you think you'll get by opposing efforts to develop standards for NAT?
- mark [ wondering how long it'll be before I'll be able to buy a CEF- accelerated TCAM-equipped layer-4 switching blade for a 7600 :-) ]
-- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
Now the more interesting question is: Given that we're going to see NAT-PT in a lot of service provider architectures to make deploying IPv6 viable, should it be considered a general enough transition mechanism to be Proposed Standard or just be a very widely deployed Historic protocol?
to remind you of my original message pushing nat-pt. the nat functionality itself needs standardization, as well as algs for dns, smtp, http, sip, and rtp. these will be sufficiently widely deployed, that we need the interchangability and testability that standardization gives us. what i did not say at that time, but think would be quite useful, is that it would be nice to have a standardized api for new algs. randy
On 1-okt-2007, at 19:56, Stephen Sprunk wrote:
The problem with NAT-PT (translating between IPv6 and IPv4 similar to IPv4 NAT) was that it basically introduces all the NAT ugliness that we know in IPv4 into the IPv6 world.
There is no "IPv6 world". I've heard reference over and over to how developers shouldn't add "NAT support" into v6 apps, but the reality is that there are no "v6 apps". There are IPv4 apps and IP apps that are version agnostic. The NAT code is there and waiting to be used whether the socket underneath happens to be v4 or v6 at any given time.
I could talk about APIs and how IPv6 addresses are embedded in protocols, but let me suffice to say that although your applications may work over both IPv4 and IPv6, this doesn't mean that the two protocols are completely interchangeable. NATs and their ALGs as well as applications WILL have to be changed to make protocols that embed IP addresses work through NAT-PT (or IPv6 NAT).
The other thing is NAT is only a small fraction of the problem; most of the same code will be required to work around stateful firewalls even in v6.
There are different approaches possible for this. Opening up holes in the firewall is probably better than ALGs.
1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections
2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on-demand over IPv6
Neither solves the problem of v6-only hosts talking to v4-only hosts.
Huh? They both do, that's the point. (Although the former doesn't work for everything and the latter removes the "IPv6-only" status from the host if not from the network it connects to.)
The fundamental flaw in the transition plan is that it assumes every host will dual-stack before the first v6-only node appears.
You're right, that doesn't work.
NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost.
Again, you're right. The costs will be ongoing in the form of reduced transparency (both in the technical/architectural sense and in the sense that applications behave unexpectedly) and the continous need to accommodate workarounds in applications. Could you please explain what problems you see with the proxy/tunnel approach and why you think NAT-PT doesn't have these problems?
When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally.
Yeah right. Youtube is going to switch to IPv6 because I have trouble viewing their stuff through NAT-PT. (Well, they use flash/HTTP so I guess I wouldn't.) No, what's going to happen is that users will demand IPv4 connectivity from their service providers if IPv6-only doesn't work well enough. On 1-okt-2007, at 20:15, Stephen Sprunk wrote:
The issue is that introducing NAT in IPv6, even if it's only in the context of translating IPv6 to IPv4, for a number of protocols, requires ALGs in the middle and/or application awareness. These things don't exist in IPv6, but they do exist in IPv4. So it's a better engineering choice to have IPv4 NAT than IPv6 NAT.
Of course ALGs will exist in IPv6: they'll be needed for stateful firewalls, which aren't going away in even the most optimistic ideas of what an IPv6-only network will look like.
That doesn't mean it's a good idea to embrace something that requires them, because every protocol needs an ALG of its own.
If both sides use a dual stack proxy, it's even possible to use address-based referrals. E.g., the IPv4 host asks the proxy to set up a session towards 2001:db8:31::1 and voila, the IPv4 host can talk to the IPv6 internet. Not possible with a NAT-PT like solution.
Only one side needs to proxy/translate; if both sides have a device to do it, one of them will not be used.
Today, it's perfectly reasonable to assume that everything's reachable over IPv4. At some point in the future, everything will be reachable over IPv6. Somewhere in between, there could be a situation where some people are running IPv4-only and others IPv6-only, so access to a dual stack proxy would be beneficial for both types of hosts.
Better, if both sides support the same version (either v4 or v6), that would be used without any proxying or translating at all.
True. It would be nice if applications or OSes could use direct communication if a destination is reachable that way and only use the proxy when there is an IP version mismatch.
Tunneling IPv4 over IPv6 is a lot cleaner than translating between the two. It preserves IPv4 end-to-end. :-)
And when we run out of v4 addresses in a few years, what do you propose we do?
Use NAT for the IPv4 connectivity, I'm afraid.
It makes little sense to tunnel v4 over v6 until v6 packets become the majority on the backbones
No, the way I see it you would have an IPv6-only local network and then have a translation box at the edge of a corporate network or in an ISP network. So you'd be in the IPv4 world before you hit any major backbones.
-- and the only way that'll happen is if everyone dual-stacks or is v6-only.
There is a difference between the networks and the hosts. Upgrading networks to dual stack isn't that hard, because it's built of only a limited number of different devices. For the same reason, running IPv6-only is pretty close to being feasible. (It already is if you don't mind conf t and can skip the fancy management stuff.) On hosts you have the trouble that all applications must run over IPv6 before you can yank the IPv4 address and while everything still has IPv4 anyway, there is little value in adding IPv6.
At 10:43 AM +0200 10/2/07, Iljitsch van Beijnum wrote:
When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally.
Yeah right. Youtube is going to switch to IPv6 because I have trouble viewing their stuff through NAT-PT.
For you? now? Not likely. About the time that a very large number of new Internet sites are being connected via IP6 because there is little choice, that's a different story. Providers would be likely be telling customers to send their complaints to YouTube, and that everyone's in the same situation until Youtube gets a real connection. The proxy&tunnel vs NAT-PT differences of opinion are entirely based on deployment model... proxy has the same drawbacks as NAT-PT, only without the attention to ALG's that NAT-PT will receive, and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. For now, HTTPS proxy or a IPv4 tunnel over IPv6 works fine, but most folks don't really care about IPv6 deployment right now. They're looking for a model which works 3 years from now, when the need to deploy IPv6 is clear and present. At that point, there's high value in having a standard NAT-PT / ALGs approach for providing limited IPv4 backwards compatibility. /John
At 5:36 AM -0400 10/2/07, John Curran wrote:
... tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available.
c/are/are no longer/ (before my morning caffeine fix) /John
On 2-okt-2007, at 11:36, John Curran wrote:
The proxy&tunnel vs NAT-PT differences of opinion are entirely based on deployment model... proxy has the same drawbacks as NAT-PT,
The main issue with a proxy is that it's TCP-only. The main issue with NAT-PT is that the applications don't know what going on. Rather different drawbacks, I'd say.
only without the attention to ALG's that NAT-PT will receive,
ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to.
and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available.
Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4. Also, not unimportant: it allows IPv4-only applications to work trivially. Another advantage is that hosts with different needs can get different classes of tunneled IPv4 connectivity even though they happen to live on the same subnet, something that's hard to do with native IPv4.
At 1:50 PM +0200 10/2/07, Iljitsch van Beijnum wrote:
ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to.
At the point in time that NAT-PR is used for backward compatibility (because we're connecting new sites via IPv6) people should be encouraged to rollout their new apps over IPv6, right? What's the problem?
and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available.
Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4. Also, not unimportant: it allows IPv4-only applications to work trivially. Another advantage is that hosts with different needs can get different classes of tunneled IPv4 connectivity even though they happen to live on the same subnet, something that's hard to do with native IPv4.
That's a wonderful solution, and you should feel free to use it. It's particularly fun from a support perspective, because you get to be involved all the way down the host level. A lot of ISP's don't want to be involved in supporting *anything* all the way down to the local host level, and want a simple method for connecting new customers via IPv6 while offering some form of legacy connectivity to rest of of the (IPv4) Internet. You're asserting that they shouldn't be allowed to use NAT-PT for this purpose, despite the fact that it meets their needs? /John
On 2-okt-2007, at 14:08, John Curran wrote:
That's a wonderful solution, and you should feel free to use it. It's particularly fun from a support perspective, because you get to be involved all the way down the host level.
Tunneling IPv4 over IPv6 and translating IPv4 into IPv6 pretty much do the same thing except that translating means information gets lost. I don't see how there is a "host level" difference between the two.
A lot of ISP's don't want to be involved in supporting *anything* all the way down to the local host level, and want a simple method for connecting new customers via IPv6 while offering some form of legacy connectivity to rest of of the (IPv4) Internet.
Well, then obviously they're not going to tunnel real addresses, so address use is not an issue. This means they can easily give out an address to all hosts connected to their network that wants one. This only costs the amount of state required per address, which should be negligible compared to the amount of state (per session) that's required when users start actually using such a service.
You're asserting that they shouldn't be allowed to use NAT-PT for this purpose, despite the fact that it meets their needs?
"The IETF" is asserting that NAT-PT is not fit for deployment. What I'm saying is that there are better ways to accomplish the same goals. Not sure what I would do if I had the power to make people stop using protocols that I feel they shouldn't use.
On Tue, Oct 02, 2007, Iljitsch van Beijnum wrote:
Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4. Also, not unimportant: it allows IPv4-only applications to work trivially. Another advantage is that hosts with different needs can get different classes of tunneled IPv4 connectivity even though they happen to live on the same subnet, something that's hard to do with native IPv4.
Please explain how you plan on getting rid of those protocol-aware plugins when IPv6 is widely deployed in environments with -stateful firewalls-. Please don't say I'm the only one who thinks this will be a problem. End-to-end-ness is and has been "busted" in the corporate world AFAICT for a number of years. IPv6 "people" seem to think that simply providing globally unique addressing to all endpoints will remove NAT and all associated trouble. Guess what - it probably won't. Plenty of places run a locked down firewall with a tight security policy that requires PERMITs in the firewall policy before access out is needed. These are going to need similar ALGs to NAT, even if they're not "fiddling" with end-points addresses. Could someone explain how I'm wrong so I can worry about other things? Adrian
On 2-okt-2007, at 15:05, Adrian Chadd wrote:
Please explain how you plan on getting rid of those protocol-aware plugins when IPv6 is widely deployed in environments with -stateful firewalls-.
You just open up a hole in the firewall where appropriate. You can have an ALG, the application or the OS do this. As you probably know by now, I don't favor the ALG approach.
End-to-end-ness is and has been "busted" in the corporate world AFAICT for a number of years. IPv6 "people" seem to think that simply providing globally unique addressing to all endpoints will remove NAT and all associated trouble. Guess what - it probably won't.
If you don't want end-to-end, be a man (or woman) and use a proxy. Don't tell the applications they they are connected to the rest of the world and then pull the rug from under them. This works in IPv4 today but don't expect this to carry over to IPv6. At least not without a long, bloody fight.
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
On 2-okt-2007, at 15:05, Adrian Chadd wrote:
Please explain how you plan on getting rid of those protocol- aware plugins when IPv6 is widely deployed in environments with -stateful firewalls-.
You just open up a hole in the firewall where appropriate.
You can have an ALG, the application or the OS do this. As you probably know by now, I don't favor the ALG approach.
You obviously have no experience working in security. You can't trust the OS (Microsoft? hah!), you can't trust the application (malware), and you sure as heck can't trust the user (industrial espionage and/or social engineering). The only way that address-embedding protocols can work through a firewall, whether it's doing NAT or not, is to use an ALG. The defense and healthcare industries will force vendors to write those ALGs (actually, make minor changes to existing ones) if they care about the protocols in question because they have no choice -- security is the law. And, once those ALGs are available, everyone else will use them. Even for home users, most have zero clue how to "open a hole" in their home firewall. Consumer OSes are far, far too insecure to let them sit exposed without a firewall by default (you can't even patch a Windows system before it's hacked), and we can't trust end users not to run malware that will open holes for them.
End-to-end-ness is and has be-en "busted" in the corporate world AFAICT for a number of years. IPv6 "people" seem to think that simply providing globally unique addressing to all endpoints will remove NAT and all associated trouble. Guess what - it probably won't.
If you don't want end-to-end, be a man (or woman) and use a proxy. Don't tell the applications they they are connected to the rest of the world and then pull the rug from under them. This works in IPv4 today but don't expect this to carry over to IPv6. At least not without a long, bloody fight.
If you think anyone will be deploying v6 without a stateful firewall, you're delusional. That battle is long over. The best we can hope for is that those personal firewalls won't do NAT as well. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On 10/2/07, Stephen Sprunk <stephen@sprunk.org> wrote:
If you think anyone will be deploying v6 without a stateful firewall, you're delusional. That battle is long over. The best we can hope for is that those personal firewalls won't do NAT as well.
Vendor C claims to support v6 (without NAT) in their "enterprise class" stateful firewall appliance as of OS version 7.2 (or thereabouts, perhaps 7.0). I've not tried it out yet to see how well it works. But, as far as the home/home office goes -- will my cable/dsl provider be able (willing?) to route a small v6 prefix to my home so that I can use a bitty-box stateful v6 firewall without NAT? What will be the cost to me, the home subscriber, to get said routable prefix? I am sure it increases the operator's expense to route a prefix to most (if not every) broadband subscriber in an area. In the beginning, cable operators were reluctant to support home customers using NAT routers to share their access. Now, renting/selling NAT routers to customers has become a revenue stream for some. How does lack of v6 NAT affect all of this?
Thus spake Duane Waddle
On 10/2/07, Stephen Sprunk <stephen@sprunk.org> wrote:
If you think anyone will be deploying v6 without a stateful firewall, you're delusional. That battle is long over. The best we can hope for is that those personal firewalls won't do NAT as well.
Vendor C claims to support v6 (without NAT) in their "enterprise class" stateful firewall appliance as of OS version 7.2 (or thereabouts, perhaps 7.0). I've not tried it out yet to see how well it works.
Good for them. Perhaps one day their Divison L will wake up and do the same for consumer products.
But, as far as the home/home office goes -- will my cable/dsl provider be able (willing?) to route a small v6 prefix to my home so that I can use a bitty-box stateful v6 firewall without NAT? What will be the cost to me, the home subscriber, to get said routable prefix? I am sure it increases the operator's expense to route a prefix to most (if not every) broadband subscriber in an area.
Pricing is, of course, up to the vendors and operators in question. One possibility is that your CPE box would do a DHCP PD request for a /64 upstream, the /64 would come out of a pool for your POP. As the response came back downstream from whatever box managed the pool, routers would install the /64 in their tables to make it reachable. It wouldn't need to propogate any higher than the POP since the the POP's routers would be advertising a constant aggregate for the pool into the core. Another possibility is that the operator would assign a /48 (or /56) to your cable/DSL modem, which would handle the above functions at the home level instead of the POP level. It would provide a /64 natively on its own interface, and delegate /64s to downstream devices on request. If customer-owned CPE boxes did the same thing, you could chain hundreds of them together and have a network that Just Worked(tm).
In the beginning, cable operators were reluctant to support home customers using NAT routers to share their access.
Of course -- they were used to charging per television. However, they learned over time that they really wanted to charge for usage and the per-computer model didn't work like the per-television model did. Now they don't care about how many computers you have, just how many bits you move. That's a good thing.
Now, renting/selling NAT routers to customers has become a revenue stream for some.
I bet they break even at best on the rentals, given how often the darn things die. One shipment and/or truck roll eliminates a year's profit margin on the equipment, even if the replacement box itself is free.
How does lack of v6 NAT affect all of this?
It prevents them from being characteristically stupid. However, I wouldn't be surprised if one or more of them demanded it from their vendors, though, or if their vendors caved to win a deal. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
At 09:13 AM 10/2/2007, Iljitsch van Beijnum wrote:
On 2-okt-2007, at 15:05, Adrian Chadd wrote:
Please explain how you plan on getting rid of those protocol-aware plugins when IPv6 is widely deployed in environments with -stateful firewalls-.
You just open up a hole in the firewall where appropriate.
It might help if you understood why deep packet inspection firewalls exist. If it were as easy as opening holes and trusting hosts, Cisco would not have a market for its PIX/ASA products, SonicWALL wouldn't exist, Juniper wouldn't have bought NetScreen, and so forth. The reality is end hosts are not sufficiently secure. Network security is built in layers. Sure, you use whatever you can in the hosts, but you don't trust it. Microsoft has had some spectacular holes that impacted even uninfected hosts (by DDoS) such as CodeRed. And this isn't a knock on Microsoft. There've been security issues with most systems at one point or another. Trusting end systems is insufficient. Site security policies are often far more complex than can be addressed by the servers to be protected, and involve VPN access, time-of-day rulesets, attack signature analysis and the like.
You can have an ALG, the application or the OS do this. As you probably know by now, I don't favor the ALG approach.
That's great that you don't favor it, but firewalls with stateful inspection can and do look deep into packets to figure out if the packets are legitimate. These devices sell, because they help. This, like NAT, is something that came about because of need. IPv6 does not remove the need for firewalls. Arguably because of the volume of relatively untested software involved on the hosts, firewalls will be quite important.
End-to-end-ness is and has been "busted" in the corporate world AFAICT for a number of years. IPv6 "people" seem to think that simply providing globally unique addressing to all endpoints will remove NAT and all associated trouble. Guess what - it probably won't.
If you don't want end-to-end, be a man (or woman) and use a proxy. Don't tell the applications they they are connected to the rest of the world and then pull the rug from under them. This works in IPv4 today but don't expect this to carry over to IPv6. At least not without a long, bloody fight.
So I'm sure you've explained to the firewall vendors they should be selling proxy boxes instead, and they've listened to you. Sorry the market has dictated solutions you don't like. Time to move on, and stop fighting a battle that's been lost.
On 2-okt-2007, at 17:35, Daniel Senie wrote:
So I'm sure you've explained to the firewall vendors they should be selling proxy boxes instead, and they've listened to you. Sorry the market has dictated solutions you don't like. Time to move on, and stop fighting a battle that's been lost.
The type of firewalling you talk about only happens in less than 1% of the sites connected to the internet. As a rule, these firewalls break lots of legitimate stuff such as ECN, the window scale option, path MTU discovery, etc, etc. The people who use them are welcome to these problems; it would be ridiculous for the IETF to work around this intentional breakage. As I said before, if you want to meddle in the middle, do it right and say you don't support this stuff rather than play coy during the setup phase and break sessions once they're established and start using the newer features. (Although I wouldn't exactly call RFCs 1191 (1990) or 1323 (1992) "new".)
I'm not sure which world you live in, but if you're doing it based on "number of publicly available IPs behind firewalls" rather than "number of end hosts connected somehow to the internet" I think you'll find the numbers quite different. Bout the only group I can think of that could give true numbers of "connected hosts" versus "routed IPs" in this situation is google. Anyone from google able to contribute some end hosts behind NAT numbers? Finally, I find the idea of "internet engineering" as a formal process with no real inclusion of current real world deployments extraordinarily amusing, and I do hope its not the case in general. Please study why the internet grew how it did versus standards-bodies released networking and application protocols. Adrian On Wed, Oct 03, 2007, Iljitsch van Beijnum wrote:
On 2-okt-2007, at 17:35, Daniel Senie wrote:
So I'm sure you've explained to the firewall vendors they should be selling proxy boxes instead, and they've listened to you. Sorry the market has dictated solutions you don't like. Time to move on, and stop fighting a battle that's been lost.
The type of firewalling you talk about only happens in less than 1% of the sites connected to the internet. As a rule, these firewalls break lots of legitimate stuff such as ECN, the window scale option, path MTU discovery, etc, etc. The people who use them are welcome to these problems; it would be ridiculous for the IETF to work around this intentional breakage.
As I said before, if you want to meddle in the middle, do it right and say you don't support this stuff rather than play coy during the setup phase and break sessions once they're established and start using the newer features. (Although I wouldn't exactly call RFCs 1191 (1990) or 1323 (1992) "new".)
On Tue, Oct 02, 2007 at 01:50:57PM +0200, Iljitsch van Beijnum wrote:
ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to.
No, they turn the Intenret into a network where you only get to deploy new IPv4 applications when the powers that be permit you to. So everyone will deploy IPv6 applications, which require no ALGs, instead. Isn't that a solution that everyone can be happy with? - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On 2-okt-2007, at 16:55, Mark Newton wrote:
ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to.
No, they turn the Intenret into a network where you only get to deploy new IPv4 applications when the powers that be permit you to.
So everyone will deploy IPv6 applications, which require no ALGs, instead.
Isn't that a solution that everyone can be happy with?
Well, I can think of a couple of things that make me unhappy: - IPv4 vs IPv6 is completely invisible to the user. I regularly run netstat or tcpdump to see which I'm using, I doubt many people will do that. So if IPv6 works and IPv4 doesn't, that will look like random breakage to the untrained user rather than something they can do something about. - If we do NAT-PT and the ALGs are implemented and then the application workarounds around the ALGs, it's only a very small step to wide scale IPv6 NAT.
On Tue, Oct 02, 2007 at 09:50:09PM +0200, Iljitsch van Beijnum wrote:
On 2-okt-2007, at 16:55, Mark Newton wrote:
So everyone will deploy IPv6 applications, which require no ALGs, instead. Isn't that a solution that everyone can be happy with?
Well, I can think of a couple of things that make me unhappy:
Doubtless.
- IPv4 vs IPv6 is completely invisible to the user. I regularly run netstat or tcpdump to see which I'm using, I doubt many people will do that. So if IPv6 works and IPv4 doesn't, that will look like random breakage to the untrained user rather than something they can do something about.
With respect, that's why a bunch of us have been suggesting using techniques such as NAT-PT to make sure taht IPv6 works _and_ IPv4 works. If the mechanisms used lack sufficient quantities of perfection, they'll be modified until they're "good enough."
- If we do NAT-PT and the ALGs are implemented and then the application workarounds around the ALGs, it's only a very small step to wide scale IPv6 NAT.
And thus the sky falls. Perhaps it's a perspective issue, but I really don't see a problem with that. If the network works, who cares? Perhaps you'd be happier if, in recognition of the fact that NAT appears to be a dirty word, we called it something else. The IPv6 people have already jumped on this bandwagon, so it shouldn't be a huge gulf to bridge: SHIM6 is basically wide-scale highly automated NAT, in which layer-3 addresses are transparently rewritten for policy purposes (a "SHIM6 middlebox," if it ever existed, would be indistinguishable from a NAT box), so we have a start here: If we rename NAT, it becomes acceptable to IPv6 proponents. So my proposal is this: Instead of saying, "NAT," from now on we should say, "Layer-4 switch." I don't know about you, but I feel comfortable deploying a network which has layer-4 switches in it. I already have layer-2 and layer-3 switches, so I might as well collect the whole set. That solution to this quagmire also solves the other great problem that you seem to have in gaining acceptance: There are legitimate uses for NAT right now, and there will be in the future, so arguing for the elimination of a useful tool before we can move the Internet forward strikes me as a fundamentally regressive argument. Perhaps in years to come we'll look at the people who argue for the elimination of layer-4 switches in the same way that we look at 1980's campus network administrators who thought the whole organization should be one big broadcast domain, with no place for layer-3 switches. "Ah, look at that, he doesn't like NAT. How... quaint." :-) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
- If we do NAT-PT and the ALGs are implemented and then the application workarounds around the ALGs, it's only a very small step to wide scale IPv6 NAT. Perhaps it's a perspective issue, but I really don't see a problem with that. If the network works, who cares?
well, the thing is that nats in the middle really do cause problems. and we do care about those problems. it's just that inability to have a usable transition toward the wonderfully incompatible ipv6 protocol is a far worse problem. so, as this is engineering, not religion, we will make the trade-off and put up with the mostly hackable problems of nat-pt rather than the much more serious problems living with ipv4 only and a jillion nats for ever and ever. some of the older of us may be more used to such lesser of two evil compromises. heck, i voted for hubert the whore. randy
- IPv4 vs IPv6 is completely invisible to the user. I regularly run netstat or tcpdump to see which I'm using, I doubt many people will do that. So if IPv6 works and IPv4 doesn't, that will look like random breakage to the untrained user rather than something they can do something about.
but the reality is ipv4 works and ipv6 doesn't. and unless the ivory tower purists get off their doomed thrones, ipv6 will die stillborn. in fact, that is what is happening now. there are more ipv4 nats within a 1km radius of here than there are v6-enabled networks on the planet. and i am at the nexus of ipv6 deployment in the world, networking central in tokyo.
- If we do NAT-PT and the ALGs are implemented and then the application workarounds around the ALGs, it's only a very small step to wide scale IPv6 NAT.
the reality is you have a choice. nat-pt or ipv4 with massive natting forever. it's not a choice i like, but it's life. get over it. randy
On 3-okt-2007, at 9:42, Randy Bush wrote:
but the reality is ipv4 works and ipv6 doesn't.
It has very little deployment at this point in time, that's something different.
and unless the ivory tower purists get off their doomed thrones, ipv6 will die stillborn.
And unless the purists, whatever their living arrangements, get to keep out at least some of the bad stuff that's in IPv4, the entire effort to move to IPv6 will be a waste of time because we'll all be in the exact same mess only with harder to remember addresses.
there are more ipv4 nats within a 1km radius of here than there are v6-enabled networks on the planet. and i am at the nexus of ipv6 deployment in the world, networking central in tokyo.
So? Still 1157 million IPv4 addresses to burn, can't realistically expect people to upgrade to IPv6 unless they have to.
the reality is you have a choice. nat-pt or ipv4 with massive natting forever. it's not a choice i like, but it's life. get over it.
I'd rather have IPv4 with massive NAT and IPv6 without NAT than both IPv4 and IPv6 with moderate levels of NAT. The tricky part is that we're not going to agree on that as a community, so the status quo will persist until someone cares enough to do something drastic that moves the entire industry in one direction or another.
At 12:02 PM +0200 10/3/07, Iljitsch van Beijnum wrote:
On 3-okt-2007, at 9:42, Randy Bush wrote:
but the reality is ipv4 works and ipv6 doesn't.
It has very little deployment at this point in time, that's something different.
I'm with Randy on this one... While we will have increased IPv6 deployment as we get closer to IPv4 free pool depletion, the size of the IPv4 installed base is very impressive and the task of moving it all to dual-stack may not be achievable w/o NAT-PT and a set of defined ALG's.
the reality is you have a choice. nat-pt or ipv4 with massive natting forever. it's not a choice i like, but it's life. get over it.
I'd rather have IPv4 with massive NAT and IPv6 without NAT than both IPv4 and IPv6 with moderate levels of NAT.
That's great, guys, if "IPv4 with massive levels of NAT" actually resembles today's Internet and is actually a viable choice. Once free pool depletion occurs and address reuse enters the equation, we've got high demand for block fragmentation and a tragedy of the commons situation where everyone's motivations are to inject their longer prefixes and yell at others not to do the same. It's a very different circumstance that we have today with NAT and it only gets worse as utilization increases. /John
It's a very different circumstance that we have today with NAT and it only gets worse as utilization increases.
Does it really get worse? Or do the ISPs with the eyeballs point at their 6to4, Teredo, ALG installations and happy customers with IPv6 access lines? And do the ISPs with the content point at their native IPv6 servers, and 6to4 relays and ALG installations? And do the people making the purchasing decisions cut short the NAT over NAT party before it has barely begun? Let's face it, this is not a technical problem. IPv4 is running out soon. IPv6 does not suffer from this "brick wall" problem and makes future network design/deployment easier to do without contortions. The economic imperative is for companies to go with whatever is simpler in the long run because that is how they recover costs. Spend some capital to build something, rake in recurring fees for a few years, and either profit from it or lose. The capital cost is less important than the operating cost because operating cost eats into margins. Simpler is better when it comes to operating costs. It is true that telcos have, in the past, been able to warp the market economics and get away with very high recurring fees that could cover the high operating costs of complex infrastructure. But does anyone believe this will happen again within the lifetimes of those people who wielded their purchasing power and pushed recurring fees down, down, down? Fact is, that IPv6 is more of a known quantity than IPv4 super NAT with ever longer prefixes and scraping the barrel for reusable IP addresses. And IPv6 is a more constraint-free environment to play in than the IPv4 endgame. If everybody had to play with the same constraints it would be different. But the fact is that some companies have already made the decision to shift their activity to IPv6 along with rising market demand for IPv6. They are hoping to get some of *YOUR* choice customers when contract renewal time comes around because those choice customers are beginning to fear that your company will go bankrupt in 2010/2011 when the demand for IPv6 goes through the roof. Of course it is better for everybody if there are only a few such shortsighted companies because the shift to IPv6 will be enough work without an exponential increase in customers fleeing from other providers. And even an IPv6 network needs peers so it is in everyone's interests that most of us get IPv6 up and running very soon now. --Michael Dillon
On 3-okt-2007, at 14:14, John Curran wrote:
I'd rather have IPv4 with massive NAT and IPv6 without NAT than both IPv4 and IPv6 with moderate levels of NAT.
That's great, guys, if "IPv4 with massive levels of NAT" actually resembles today's Internet and is actually a viable choice.
It doesn't have to be viable. If it isn't, that's good reason for people to move to IPv6.
Once free pool depletion occurs and address reuse enters the equation, we've got high demand for block fragmentation and a tragedy of the commons situation where everyone's motivations are to inject their longer prefixes and yell at others not to do the same.
Good reason to start working on that IPv6 transition plan while there is still time.
On Wed, Oct 03, 2007 at 12:02:31PM +0200, Iljitsch van Beijnum wrote:
The tricky part is that we're not going to agree on that as a community, so the status quo will persist until someone cares enough to do something drastic that moves the entire industry in one direction or another.
That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks. This whole "debate" is a complete waste of time, because everyone, yourself included, knows that regardless of what consensus we end up with, at the end of the day if NAT makes sense NAT will be deployed. End of story, game over. This whole meme that says we need the entire industry to move in the same direction at the same time is yet another delaying fallacy, and yet another example of you proposing that we all behave like old-skool telcos inside the exact same 24 hour period when you decry any suggestion that we act like old-skool telcos. Whatever. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks.
This whole "debate" is a complete waste of time,
Yup. It would be more productive for everyone in the debate to build an IPv6 router based on Linux, add NAT-PT and trial it for their own Internet access for a few weeks. Instructions are here: http://tomicki.net/ipv6.router.php The proof of the pudding is in the tasting. --Michael Dillon
On 3-okt-2007, at 15:52, Mark Newton wrote:
The tricky part is that we're not going to agree on that as a community, so the status quo will persist until someone cares enough to do something drastic that moves the entire industry in one direction or another.
That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks.
And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail.
This whole "debate" is a complete waste of time, because everyone, yourself included, knows that regardless of what consensus we end up with, at the end of the day if NAT makes sense NAT will be deployed. End of story, game over.
Few things in today's internet are universal. I don't think the answer to the question whether NAT makes sense is one of them.
This whole meme that says we need the entire industry to move in the same direction at the same time is yet another delaying fallacy, and yet another example of you proposing that we all behave like old-skool telcos inside the exact same 24 hour period when you decry any suggestion that we act like old-skool telcos.
It takes two to tango. If you deploy something that doesn't work with what everyone else has deployed, in most cases, it's you who has the problem. In that sense, the industry must move fairly coherently. Unfortunately, this is true regardless of any underlying merit. Current path MTU discovery practices are insane but use a smaller- than-1500-byte MTU at your peril.
It's seems we're always confusing NAT with PAT (or NAT overload, or whatever else you want to call it). One to one NAT rarely breaks stuff. NAT-PT would need to follow that model, otherwise, yes, things will break. It seems like an IPv6-only ISP would need to operate the NAT-PT boxes, and dedicate a block of v4 addresses the size of the expected concurrent online users to the NAT-PT box. Keep in mind that a v6 ISP with 1 million customers won't need a million v4 addresses, for obvious reasons. It's going to be considerably less than if each customer got a v4 address. NAT-PT does seem like a viable short term solution. I'm not sure though how to get current v4-only content providers to dual-stack their stuff. Increased domain fees maybe for v4-only domains... Chuck -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Iljitsch van Beijnum And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail.
break. It seems like an IPv6-only ISP would need to operate the NAT-PT boxes, and dedicate a block of v4 addresses the size of the expected concurrent online users to the NAT-PT box. Keep in mind that a v6 ISP with 1 million customers won't need a million v4 addresses, for obvious reasons. It's going to be considerably less than if each customer got a v4 address. NAT-PT does seem like a viable short term solution. I'm
An IPv6-only ISP with enough IPv4 addresses for its concurrent online users seems strange. Why wouldn't that ISP give those v4 addresses to the online users instead of the NAT-PT box? And why do you call it IPv6-only? Andras
An IPv6-only ISP with enough IPv4 addresses for its concurrent online users seems strange. Why wouldn't that ISP give those v4 addresses to
-----Original Message----- From: JAKO Andras [mailto:jako.andras@eik.bme.hu] Sent: Wednesday, October 03, 2007 8:59 PM To: Church, Charles Cc: nanog@merit.edu Subject: RE: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6) the
online users instead of the NAT-PT box? And why do you call it IPv6-only?
Andras
Because not all users are online at the same time. Think back to the days where you had x number of dialup lines for y number of subscribers. It might be a 2:1 ratio. Maybe more, depending on how many time zones an ISP serves. It's not a huge plus, but once IPv4 content providers can see where x% of their web hits are coming from these NAT-PT blocks, they might be more motivated to go dual-stack. Chuck
Iljitsch van Beijnum wrote:
That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks.
And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail.
Somehow we made it work for v4. How did that happen?
On 4-okt-2007, at 13:36, Eliot Lear wrote:
That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks.
And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail.
Somehow we made it work for v4. How did that happen?
(Hm, RTSP fails miserably when I use NAT on my Cisco 826...) Well, if 95% of the people in a position to do this think it's worth repeating this effort for IPv6, my objections aren't going to stop them. But if the majority or even a significant minority don't want to play, then IPv6 NAT is going to work a lot worse than IPv4 NAT. And although it's clear that some people want IPv6 NAT, IPv6 NAT is not nearly as useful as IPv4 NAT, because IPv6 has more than enough addresses for any conceivable use without it. I would be interested to know how many people favor each of the following approaches. Feel free to send me private email and I'll summerize. 1. Keep NAT and ALGs out of IPv6 and use additional protocols between hosts and firewalls to open "pinholes" in firewalls (where appropriate/allowed, such as in consumer installations) to avoid ALGs 2. Keep NAT out of IPv6 but use ALGs to bypass firewalls 3. Come up with a standard way of doing 1-to-1 NAT (no PAT) in IPv6 4. Come up with a standard way of doing NAT/PAT in IPv6 5. Everyone do whatever suits their needs like what happened in IPv4 And: if people start using NAT in IPv6 I will: a. Implement ALGs and application workarounds to accommodate it b. Not do anything, it's their problem if stuff breaks c. Break stuff that goes through IPv6 NAT on purpose to prove a point
Well, if 95% of the people in a position to do this think it's worth repeating this effort for IPv6, my objections aren't going to stop them. But if the majority or even a significant minority don't want to play, then IPv6 NAT is going to work a lot worse than IPv4 NAT.
What if only 5% of the people want to do this, and that 5% represents a couple of thousand people who configure enterprise network infrastructure. What if only 1% of that couple of thousand people are demanding that their router supplier supports NAT-PT. That is 20 enterprise customers that are telling their vendor to support NAT-PT or lose their business. In my experience 20 decision makers with purchasing power is more than enough to make things happen.
5. Everyone do whatever suits their needs like what happened in IPv4
Since this is what is going to happen regardless of your survey, what is the point? Some of us are interested in getting things done now because the time for big architectural changes has long past. We have to work with the resources available to us today.
And: if people start using NAT in IPv6 I will:
a. Implement ALGs and application workarounds to accommodate it
b. Not do anything, it's their problem if stuff breaks
c. Break stuff that goes through IPv6 NAT on purpose to prove a point
d. Do whatever my employer decides is appropriate, i.e. some A, some B and don't even think about C or you'll be on the street before lunchtime! You may know a lot about IPv6 network design but you don't understand survey design very well. --Michael Dillon
On 4-okt-2007, at 14:36, Iljitsch van Beijnum wrote:
I would be interested to know how many people favor each of the following approaches. Feel free to send me private email and I'll summerize.
I only got three replies, which don't really support drawing many conclusions.
1. Keep NAT and ALGs out of IPv6 and use additional protocols between hosts and firewalls to open "pinholes" in firewalls (where appropriate/allowed, such as in consumer installations) to avoid ALGs
+ +
2. Keep NAT out of IPv6 but use ALGs to bypass firewalls
_
3. Come up with a standard way of doing 1-to-1 NAT (no PAT) in IPv6
4. Come up with a standard way of doing NAT/PAT in IPv6
+
5. Everyone do whatever suits their needs like what happened in IPv4
- Interestingly, nobody seems to like option 3.
And: if people start using NAT in IPv6 I will:
a. Implement ALGs and application workarounds to accommodate it
"don't want to but we'll have to if it comes to this" x 2 unqualified x 1
b. Not do anything, it's their problem if stuff breaks
"would prefer this if it were up to me" x 1
c. Break stuff that goes through IPv6 NAT on purpose to prove a point
-
In article <4704D03D.5030702@cisco.com> you write:
Iljitsch van Beijnum wrote:
That isn't actually true. I could move to IPv6 and deploy a NAT-PT box to give my customers access to the v4 Internet regardless of whatever the rest of the community thinks.
And then you'll see your active FTP sessions, SIP calls, RTSP sessions, etc fail.
Somehow we made it work for v4. How did that happen?
The problem is that NAT constrains the solution space available to application developers. I have no problem with PT-NAT to get to IPv4 because the IPv4 space is already constrained by the existing use of NAT. Most/many of the existing applications have been crippled by the existance of NAT. Almost no-one attempts to run the passive side (server) of a connection behind a NAT. With PAT try running more services that use the same port than you have public addresses. It just won't work. Similarly double or tripple NAT further reduce the application space that works. Even hotels realise NAT is bad. Have you notice that you now get asked if you can live behind the NAT or do you need a public address when you register? I work from behind a NAT as I work from home. There have been lots of things that should have been simple, but wern't, as that NAT was there. Something just didn't work because I couldn't find a ALG for that protocol. I have a big problem with pulling those constraints into IPv6. Without NAT I can, if needed, open up a complete address in the firewall to work around lack if a ALG. I don't get that choice with NAT. Mark
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
On 2-okt-2007, at 11:36, John Curran wrote:
The proxy&tunnel vs NAT-PT differences of opinion are entirely based on deployment model... proxy has the same drawbacks as NAT-PT,
The main issue with a proxy is that it's TCP-only. The main issue with NAT-PT is that the applications don't know what going on. Rather different drawbacks, I'd say.
There are several different mechanisms devices can use to discover they're behind a NAT(-PT) if they care. Most do not, and those that do often can't do anything about it even if they know.
only without the attention to ALG's that NAT-PT will receive,
ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to.
That's somewhat true if you rely on a NAT-PT upstream. However, you can run your own NAT-PT box, decide what ALGs to run, and bypass the upstream NAT-PT since you will _appear_ to be a natively dual-stacked site. Of course, you're limited by the vendor writing the ALGs in the first place, but that's just an argument for OSS. Or perhaps it's an argument for deploying real v6 support and getting rid of NAT-PT entirely. The alternative to NAT-PT is multilayered v4 NAT, which has the same problem you describe except there's no way out.
and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available.
Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4.
We'll still need all those ALGs for v6 stateful firewalls. Might as well put them to use in NAT-PT during the transition between the ALG'd starting phase (all v4) and the ALG'd ending phase (all v6).
Also, not unimportant: it allows IPv4-only applications to work trivially.
Any applications that work "trivially" through v4 NAT will also work "trivially" through NAT-PT and v6 stateful firewalls. The interesting apps are the ones that don't work through NAT or firewalls without ALGs. If you're making some silly argument about non-NAT v4 access, well, you're over a decade out of touch with reality. The number of v4 hosts that are _not_ behind a NAT is negligible today. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
On 1-okt-2007, at 19:56, Stephen Sprunk wrote:
There is no "IPv6 world". I've heard reference over and over to how developers shouldn't add "NAT support" into v6 apps, but the reality is that there are no "v6 apps". There are IPv4 apps and IP apps that are version agnostic. The NAT code is there and waiting to be used whether the socket underneath happens to be v4 or v6 at any given time.
I could talk about APIs and how IPv6 addresses are embedded in protocols, but let me suffice to say that although your applications may work over both IPv4 and IPv6, this doesn't mean that the two protocols are completely interchangeable. NATs and their ALGs as well as applications WILL have to be changed to make protocols that embed IP addresses work through NAT-PT (or IPv6 NAT).
First, there really aren't that many apps today that embed IP addresses or don't follow the traditional client-server model. We don't have more of them because of v4 NAT. Second, the ALGs will have to be (re)written anyways to deal with IPv6 stateful firewalls, whether or not NAT-PT happens.
The other thing is NAT is only a small fraction of the problem; most of the same code will be required to work around stateful firewalls even in v6.
There are different approaches possible for this. Opening up holes in the firewall is probably better than ALGs.
That's the purpose of an ALG. Requiring users to modify their home router config or put in a change request with their IT department for a firewall exception is a non-starter if you want your app to be accepted. Whether the pinhole is needed because of a NAT or a stateful firewall is irrelevant; what matters is having an ALG create the pinhole _automatically_.
1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections
2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on-demand over IPv6
Neither solves the problem of v6-only hosts talking to v4-only hosts.
Huh? They both do, that's the point. (Although the former doesn't work for everything and the latter removes the "IPv6-only" status from the host if not from the network it connects to.)
The former only handles outbound TCP traffic, which works through pure NAT boxes as it is. The latter "solution" ignores the problem space by telling people to not be v4-only anymore.
NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost.
Again, you're right. The costs will be ongoing in the form of reduced transparency (both in the technical/architectural sense and in the sense that applications behave unexpectedly) and the continous need to accommodate workarounds in applications.
Agreed. People have shown they're willing to accept those costs in a v4-only network. Extending that to the transition phase adds zero _new_ costs. Providing a way out for people if they deploy v6 is a new _benefit_.
Could you please explain what problems you see with the proxy/tunnel approach and why you think NAT-PT doesn't have these problems?
NAT-PT works for more apps/protocols. It definitely has its own problems, though. That's why I view it as a transition technology, not a desirable end state. If it's successful, it will drive itself out of existence.
When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally.
Yeah right. Youtube is going to switch to IPv6 because I have trouble viewing their stuff through NAT-PT. (Well, they use flash/HTTP so I guess I wouldn't.)
Either YouTube won't care, in which case NAT-PT obviously isn't as evil as people claim, or they will care and they'll deploy v6. I don't claim to know which scenario is correct, but I assert that it's one of the two.
No, what's going to happen is that users will demand IPv4 connectivity from their service providers if IPv6-only doesn't work well enough.
This is one place where the duopoly will work in our favor -- most people (at least in the US) only have two choices, and if neither of them has new IPv4 addresses available due to exhaustion, people simply can't buy non-NATed v4 access. The choices will be native v6, NAT-PT to v4, or multilayered v4 NAT. If that doesn't work "well enough", the people at the other end will be motivated to deploy native v6 on their end to make their service work better than their competitors' -- and all the evil NAT(-PT) stuff is bypassed.
On 1-okt-2007, at 20:15, Stephen Sprunk wrote:
The issue is that introducing NAT in IPv6, even if it's only in the context of translating IPv6 to IPv4, for a number of protocols, requires ALGs in the middle and/or application awareness. These things don't exist in IPv6, but they do exist in IPv4. So it's a better engineering choice to have IPv4 NAT than IPv6 NAT.
Of course ALGs will exist in IPv6: they'll be needed for stateful firewalls, which aren't going away in even the most optimistic ideas of what an IPv6-only network will look like.
That doesn't mean it's a good idea to embrace something that requires them, because every protocol needs an ALG of its own.
No, the vast majority of protocols will use the default TCP or UDP ALGs because they don't embed IP addresses. Those that do will either get an ALG if they're popular or force people to v6 if they're not.
Today, it's perfectly reasonable to assume that everything's reachable over IPv4. At some point in the future, everything will be reachable over IPv6. Somewhere in between, there could be a situation where some people are running IPv4-only and others IPv6-only, so access to a dual stack proxy would be beneficial for both types of hosts.
s/dual stack proxy/NAT-PT/ and I'll agree with you. One of the problems with a proxy is that you have to configure hosts to use it, and all traffic flows through it whether it's needed or not. Obviously we could make the clients smarter, but then you're back to the decade problem. It's too late for that.
Tunneling IPv4 over IPv6 is a lot cleaner than translating between the two. It preserves IPv4 end-to-end. :-)
And when we run out of v4 addresses in a few years, what do you propose we do?
Use NAT for the IPv4 connectivity, I'm afraid.
We're _already_ using NAT. ITYM "multilayered NAT" here. And how, exactly, is that a better world than NAT-PT, which anyone can drop overnight by deploying native v6?
It makes little sense to tunnel v4 over v6 until v6 packets become the majority on the backbones
No, the way I see it you would have an IPv6-only local network and then have a translation box at the edge of a corporate network or in an ISP network. So you'd be in the IPv4 world before you hit any major backbones.
Or vice versa. The key is that we eliminate the need to synchronize the activity of all sites, which is obviously impossible at this stage of the Internet's development.
-- and the only way that'll happen is if everyone dual-stacks or is v6-only.
There is a difference between the networks and the hosts. Upgrading networks to dual stack isn't that hard, because it's built of only a limited number of different devices.
*giggle* You mean like the 90% of hosts that will be running Vista (which has v6 enabled by default) within a couple years? Or the other 10% of hosts that have had v6 enabled for years? The problem isn't the hosts. It isn't even really the core network. It's all the middleboxes between the two that are v4-only and come from dozens of different clue-impaired vendors. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On 2-okt-2007, at 15:56, Stephen Sprunk wrote:
Second, the ALGs will have to be (re)written anyways to deal with IPv6 stateful firewalls, whether or not NAT-PT happens.
That's one solution. I like the hole punching better because it's more general purpose and better adheres to the principle of least astonishment.
That's the purpose of an ALG. Requiring users to modify their home router config or put in a change request with their IT department for a firewall exception is a non-starter if you want your app to be accepted.
Hence uPnP and NAT-PMP plus about half a dozen protocols the IETF is working on.
Huh? They both do, that's the point. (Although the former doesn't work for everything and the latter removes the "IPv6-only" status from the host if not from the network it connects to.)
The former only handles outbound TCP traffic, which works through pure NAT boxes as it is.
BitTorrent is TCP, but it sure doesn't like NAT because it gets in the way of incoming sessions.
The latter "solution" ignores the problem space by telling people to not be v4-only anymore.
Decoding IPv4 packets on a host is trivial, they already have all the necessary code on board. It's building an IPv4 network that's a burden.
Could you please explain what problems you see with the proxy/tunnel approach and why you think NAT-PT doesn't have these problems?
NAT-PT works for more apps/protocols.
Disagree. Tunneling gives you actual IPv4 so obviously that will always be better than translation.
One of the problems with a proxy is that you have to configure hosts to use it, and all traffic flows through it whether it's needed or not. Obviously we could make the clients smarter, but then you're back to the decade problem. It's too late for that.
Automatic proxy configuration already exists. I agree that having IPv6 traffic go through a proxy is unnecessary but that can be fixed. And there's no such thing as "too late" (if there were, the IETF would have been out of business long ago): problems stick around until you fix them.
There is a difference between the networks and the hosts. Upgrading networks to dual stack isn't that hard, because it's built of only a limited number of different devices.
*giggle* You mean like the 90% of hosts that will be running Vista (which has v6 enabled by default) within a couple years? Or the other 10% of hosts that have had v6 enabled for years?
The problem isn't the hosts. It isn't even really the core network. It's all the middleboxes between the two that are v4-only and come from dozens of different clue-impaired vendors.
You forget that the majority of applications need to be changed to work over IPv6. If I turn off IPv4 on my Mac and use some magic to go from v6 to v4, I can get to the web and do stuff like ssh and ftp, but most other applications don't work because they don't support IPv6 yet. On 2-okt-2007, at 16:10, Stephen Sprunk wrote:
You just open up a hole in the firewall where appropriate.
You obviously have no experience working in security.
Who wants those headaches?
You can't trust the OS (Microsoft? hah!), you can't trust the application (malware), and you sure as heck can't trust the user (industrial espionage and/or social engineering). The only way that address-embedding protocols can work through a firewall, whether it's doing NAT or not, is to use an ALG.
You assume a model where some trusted party is in charge of a firewall that separates an untrustworthy outside and an untrustworthy inside. This isn't exactly the trust model for most consumer networks. Also, why would you be able to trust what's inside the control protocol that the ALG looks at any better than anything else?
The defense and healthcare industries will force vendors to write those ALGs (actually, make minor changes to existing ones) if they care about the protocols in question because they have no choice -- security is the law.
Seems to work well, that law. But these people don't complain when their video streaming/chatting doesn't work out of the box. These are highly specialized setups that are really beyond what general purpose hard- and software can be expected to cope with.
Even for home users, most have zero clue how to "open a hole" in their home firewall.
Repeat after me: uPnP, NAT-PMP.
On Tue, Oct 02, 2007 at 10:33:43PM +0200, Iljitsch van Beijnum wrote:
On 2-okt-2007, at 16:10, Stephen Sprunk wrote:
You can't trust the OS (Microsoft? hah!), you can't trust the application (malware), and you sure as heck can't trust the user (industrial espionage and/or social engineering). The only way that address-embedding protocols can work through a firewall, whether it's doing NAT or not, is to use an ALG.
You assume a model where some trusted party is in charge of a firewall that separates an untrustworthy outside and an untrustworthy inside. This isn't exactly the trust model for most consumer networks.
Err, it is. Really, it is. Residential-grade customers employ trusted parties like "DLink", "Alloy", "Alcatel", "Linksys", and various others to be in charge of the firewall that separates the untrustworthy internet from their inside network. Corporate-grade customers employ trusted parties as staff. SMEs are somewhere in between, often substituting their ISP as a proxy for "staff." Ether way you cut it, the model you've just dismissed is _exactly_ the way the real world works.
Also, why would you be able to trust what's inside the control protocol that the ALG looks at any better than anything else?
You can't. So if the control protocol can possibly do anything bad, the firewall administrator says, "Well, can't let this take control of my network, I'll just block it." ... which breaks end-to-end reachability every bit as effectively as a NAT box does, regardless of whether or not the firewall employs NAT. Which is why various correspondents in this thread have repeatedly pointed out that any assertion that an IPv6 Internet is going to be any more end-to-end than an IPv4 Internet is delusional.
The defense and healthcare industries will force vendors to write those ALGs (actually, make minor changes to existing ones) if they care about the protocols in question because they have no choice -- security is the law.
Seems to work well, that law.
But these people don't complain when their video streaming/chatting doesn't work out of the box.
<splutter> Oh yes they do. You better believe it. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
On 2-okt-2007, at 15:56, Stephen Sprunk wrote:
Second, the ALGs will have to be (re)written anyways to deal with IPv6 stateful firewalls, whether or not NAT-PT happens.
That's one solution. I like the hole punching better because it's more general purpose and better adheres to the principle of least astonishment.
ALGs are just automated hole-punching.
That's the purpose of an ALG. Requiring users to modify their home router config or put in a change request with their IT department for a firewall exception is a non-starter if you want your app to be accepted.
Hence uPnP and NAT-PMP plus about half a dozen protocols the IETF is working on.
uPNP is moderately successful in the consumer space; it still doesn't work very well today, and it won't work at all in a few years when ISPs are forced to put consumers behind their own NAT boxes because they can't get any more v4 addresses. None of those protocols are being seriously considered by business folks. ALGs are here to stay. If the NAT/FW box can recognize a SIP call, or an active FTP transfer, or whatever and open the pinhole on its own, why is that a bad thing? Since it's the NAT/FW box that's breaking things, it's the NAT/FW box's responsibility to minimize that breakage -- not rely on hosts to tell it when a pinhole needs to be opened.
Huh? They both do, that's the point. (Although the former doesn't work for everything and the latter removes the "IPv6-only" status from the host if not from the network it connects to.)
The former only handles outbound TCP traffic, which works through pure NAT boxes as it is.
BitTorrent is TCP, but it sure doesn't like NAT because it gets in the way of incoming sessions.
Of course. It doesn't help that many ISPs are filtering inbound SYN packets specifically to block (or at least severely degrade the performance of) P2P apps.
The latter "solution" ignores the problem space by telling people to not be v4-only anymore.
Decoding IPv4 packets on a host is trivial, they already have all the necessary code on board. It's building an IPv4 network that's a burden.
Today, at least, it's less of a burden to build a NATed v4 network than it is to try to get v6 working end-to-end (with or without NAT).
There is a difference between the networks and the hosts. Upgrading networks to dual stack isn't that hard, because it's built of only a limited number of different devices.
*giggle* You mean like the 90% of hosts that will be running Vista (which has v6 enabled by default) within a couple years? Or the other 10% of hosts that have had v6 enabled for years?
The problem isn't the hosts. It isn't even really the core network. It's all the middleboxes between the two that are v4-only and come from dozens of different clue-impaired vendors.
You forget that the majority of applications need to be changed to work over IPv6.
The majority of bits moved are via apps that support v6. One of the benefits of NAT-PT is all those legacy v4-only apps can stay exactly how they are (at least until the next regular upgrade, if any) and talk to v6 servers, or to other v4 servers across a v6-only network.
On 2-okt-2007, at 16:10, Stephen Sprunk wrote:
You just open up a hole in the firewall where appropriate.
You obviously have no experience working in security.
Who wants those headaches?
You can't trust the OS (Microsoft? hah!), you can't trust the application (malware), and you sure as heck can't trust the user (industrial espionage and/or social engineering). The only way that address-embedding protocols can work through a firewall, whether it's doing NAT or not, is to use an ALG.
You assume a model where some trusted party is in charge of a firewall that separates an untrustworthy outside and an untrustworthy inside. This isn't exactly the trust model for most consumer networks.
Yes, it is. Or at least it should be. There is no "trusted" side of a firewall these days. Even a decade ago it was recognized that the majority of attacks were from the "inside". With the advent of worms and viruses (spread by insecure host software), "outside" attackers are almost irrelevant compared to "inside" attackers. Also, consumer networks are not the only relevant networks. There are arguably just as many hosts on enterprise networks, and the attitudes and practices of their admins (regardless of technical correctness) need to be considered.
Also, why would you be able to trust what's inside the control protocol that the ALG looks at any better than anything else?
You can't completely, and obviously ALGs would fail completely if IPsec ever took off (in fact, that may be one reason it hasn't), but in practice it's the best option we have today. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On 4-okt-2007, at 17:50, Stephen Sprunk wrote:
Hence uPnP and NAT-PMP plus about half a dozen protocols the IETF is working on.
uPNP is moderately successful in the consumer space; it still doesn't work very well today, and it won't work at all in a few years when ISPs are forced to put consumers behind their own NAT boxes because they can't get any more v4 addresses.
Please don't take my statement to be an endorsement of uPnP: it's a huge hack and has proven to be a security hole big enough to drive a truck full of NAT boxes through. My point is that in the consumer market, there has been a move to explicit hole punching rather than full reliance on ALGs.
None of those protocols are being seriously considered by business folks.
Business folks once ruled the internet but those days are over. The consumer is king.
If the NAT/FW box can recognize a SIP call, or an active FTP transfer, or whatever and open the pinhole on its own, why is that a bad thing?
The bad thing is when it doesn't work. For instance, when I let my Apple Extreme base station do NAT, RTSP (QuickTime streaming, although I think this defaults to HTTP these days, which sucks in its own way) works. But when I let my Cisco 826 do it, there is no RTSP ALG and it doesn't work. Since it's practically impossible for an end-user to add ALGs, this means that relying on them is russian roulette. You can get lucky at first, but nobody survives the sixth round.
Decoding IPv4 packets on a host is trivial, they already have all the necessary code on board. It's building an IPv4 network that's a burden.
Today, at least, it's less of a burden to build a NATed v4 network than it is to try to get v6 working end-to-end (with or without NAT).
On the contrary. It's extremely simple: get IPv6-enabled ISPs on both ends, configure IPv6 on all routers on both sides, sprinkle with AAAA records and you're in business. Then ALL applications that work over IPv6 will work. No exceptions. With NAT you're forever chasing after the exceptions. Now of course getting those IPv6 ISPs may be hard/expensive/ impossible and running v6 on the routers may require replacing them, but those are simple practical issues that are irrelevant in the long term.
One of the benefits of NAT-PT is all those legacy v4-only apps can stay exactly how they are (at least until the next regular upgrade, if any) and talk to v6 servers, or to other v4 servers across a v6- only network.
No they can't. When I fire up pretty much any IM client when I'm running IPv6-only, it doesn't work, despite the presence of the necessary translation gear. Those apps simply cannot communicate over IPv6 sockets.
You assume a model where some trusted party is in charge of a firewall that separates an untrustworthy outside and an untrustworthy inside. This isn't exactly the trust model for most consumer networks.
Yes, it is. Or at least it should be. There is no "trusted" side of a firewall these days.
Exactly: not the inside, not the outside, and also not the middle. As I said, in consumer installations, apps get to open up holes in NAT boxes so there is no protection from rogue applications running on internal hosts.
Also, consumer networks are not the only relevant networks. There are arguably just as many hosts on enterprise networks, and the attitudes and practices of their admins (regardless of technical correctness) need to be considered.
In such networks, it would be reasonable to expect that what happens on the hosts and what happens on the middleboxes is sufficiently coordinated that it presents something unified to the outside. This is different from the consumer space where random apps need to communicate across random home gateways.
On Thu, 04 Oct 2007 22:35:33 +0200, Iljitsch van Beijnum said:
Business folks once ruled the internet but those days are over. The consumer is king.
Given yesterday's RIAA victory in their lawsuit in Minnesota, I expect the RIAA will start lobbying for more ways to easily identify the individual users/computers - the easiest way to do *that*, of course, is to give each computer a truly unique address rather than allow some unknown number of authorized and freeloading computers to all hide behind one NAT on a wireless cable/DSL modem. I predict this will finally be the Killer App that IPv6 has been waiting for. :)
1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections
2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on-demand over IPv6
The advantage of 1. is that proxies and applications that can use proxies are already in wide use. The advantage of 2. is that it provides real IPv4 connectivity without compromises. Different hosts (even on the same subnet) can have different IPv4 connectivity (NAT/no NAT, firewalled/unfirewalled) without having to provision the complete path between the user and the edge of the network specifically for that type of connectivity. And no lost addresses for subnetting etc.
However, Number 2 does not solve the need for an IPv6 only host to talk to an IPv4 only host for some purpose other than TCP things that can be fed through an HTTPS proxy. Owen
On Thu, 27 Sep 2007 13:59:53 -1000 Randy Bush <randy@psg.com> wrote:
The REAL problems are not going anywhere for a long time, if ever.
indeed, many will be with us for a long time. but there are a bunch we could knock off in a few years o dual stack backbones (and it's as much the vendors as the isps here) o dual stack consumer cpe o routers that hold 2m routes *with churn* from enterprise to backbone o test equipment to differentiate vendor hot air from actual performance o nat-pt with standardized algs for at least dns, smtp, http, sip, and rtp
I once complained to Bjarne Stroustrup about some aspect of C++. He replied that it was not the best possible language, but rather the best language possible. He was dealing with programmers who were recent converts to C; indeed, many of them had only recently been weaned from lower-level assembler languages. (Doug McIlroy once told me that C was the best assembler language he'd ever used. I agree with him.) I feel much the same about IPv6. IPv6 isn't what I wanted it to be. During the IPng directorate, several of us (including me and at least one of the chairs) pushed very hard for id/locator split. We lost. That was 1994; it's over and done with. But it took 13 years from then to a (mostly) complete set of specs and universal implementation, at least in all systems shipping today. Even if there was universal agreement that the design was wrong and that we should start over, I can't see it taking less than 10 years to get back to the current level of maturity. We don't have that long. We don't even have any guarantees that we'd get everything right if we tried again; while we could avoid today's known pitfalls, I'm sure there are \aleph_0 more waiting for us. To me, then, the question is "now what?" We have to get off of v4. We're dying the death of a thousand NATs. What we have to do is push the responsible parties -- CPE vendors, ISPs, router vendors, and yes, the IETF -- to fill in the holes. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Steven M. Bellovin wrote: [..]
IPv6 isn't what I wanted it to be. During the IPng directorate, several of us (including me and at least one of the chairs) pushed very hard for id/locator split. We lost. That was 1994; it's over and done with. But it took 13 years from then to a (mostly) complete set of specs and universal implementation, at least in all systems shipping today. [..]
The good thing about the current state of IPv6 is though that applications have the following: - 128bits source address - 128bits destination address and in many cases they are now also AF independent due to getaddrinfo(), though there will always be some dependent code in their unfortunately. Why is the above good? Well, the application doesn't further really care about how the packets are sent from source to destination. As such those bits are now identifiers already. The OS can change them and do whatever it wants with them, eg it could change them to something which is available only on the link, tell the other end to do the same when it receives them to make them identical when sent from the source application. This should provide for a pretty good outcome in a couple of years where next the second biggest "problem" of the current Internet will be solved (the first being 32bits not being enough to address all hosts): too many DFZ routes. That will require a id/locator split, or IMHO better mentioned using those 128bits as both ID's and locators. It will need a signaling protocol for mentioning when something is an ID and when something is a locator and how to get back to an ID, but that magic should not be too hard to do and can be done both in the endhost and in middle boxes. As such, IPv6 has already solved the currently biggest problem: there is enough address space. Applications are mostly ready for this and so are Operating Systems. Now the web should follow, and while the IPv6 DFZ grows (it is still <900 routes) we will have enough time to create the ID/LOC system that ISP operators and Enterprise operators will accept. Especially that 'acceptance' is a big problem it seems and that is mosly a political issue, not a technical one. Btw, ram@iab.org if you want to join in on those discussions. Greets, Jeroen
Kevin Oberman wrote:
Randy is right that eliminating tunnels does not make all of the IPv6 problems go away. It just eliminates the ones caused by the use of tunnels. The REAL problems are not going anywhere for a long time, it ever.
It would be nice to see some evidence of some forward motion but I don't see any. The vendors seem to point at a lack of demand and the ISPs claim a lack of support from the vendors and/or not customer demand. If the ISPs tried to deploy it for themselves then perhaps this current impasse could be broken and the current shortcomings would then have some visibility with the vendors and that might encourage the IETF to address the real issues. A quick look at some of the usual suspects shows not much consumption of their own dog food. <http://www.mrp.net/ISP.html> although the R&E community isn't much better <http://www.mrp.net/Internet2.html>. Mark.
At 7:56 PM +0930 9/30/07, Mark Prior wrote:
It would be nice to see some evidence of some forward motion but I don't see any. The vendors seem to point at a lack of demand and the ISPs claim a lack of support from the vendors and/or not customer demand.
It's going to get real interesting, since (in general): 1) Customers aren't going to ask for IPv6 (it's not their problem) 2) ISP's may plan a few years out, but don't make capital commitments until they're absolutely required. 3) It takes most vendors 3 to 6 months to move requirements through marketing and 1 year plus for engineering and chip design. Alas, this particular feature set (functional IPv6 and transition tools) is not just one new protocol feature or option; it's an order of magnitude more complex and will take ISP's months (or even years) to deploy. It's amazing that got the need for the new protocol right more than a decade ago, but seemed to have left all the details to the last minute.
If the ISPs tried to deploy it for themselves then perhaps this current impasse could be broken and the current shortcomings would then have some visibility with the vendors and that might encourage the IETF to address the real issues.
Agreed.
A quick look at some of the usual suspects shows not much consumption of their own dog food. ... <http://www.mrp.net/ISP.html>
Very nice chart! /John
John Curran wrote:
At 7:56 PM +0930 9/30/07, Mark Prior wrote:
It would be nice to see some evidence of some forward motion but I don't see any. The vendors seem to point at a lack of demand and the ISPs claim a lack of support from the vendors and/or not customer demand.
It's going to get real interesting, since (in general):
1) Customers aren't going to ask for IPv6 (it's not their problem)
Well some do :) but in general it's just the plumbing that no one cares about.
2) ISP's may plan a few years out, but don't make capital commitments until they're absolutely required.
Yes but many ISPs would be using hardware that the vendors claim is compliant so why not test their claims and start submitting bug reports? Of more concern would be the operations and management software, which probably doesn't exist. This probably means that right now any deployment would need to focus on the ISP itself rather than their customers. Although some customers are happy to beta test just about anything :)
Alas, this particular feature set (functional IPv6 and transition tools) is not just one new protocol feature or option; it's an order of magnitude more complex and will take ISP's months (or even years) to deploy.
These are the same ISPs and vendors that seem to have managed to deploy MPLS in a more rapid fashion.
It's amazing that got the need for the new protocol right more than a decade ago, but seemed to have left all the details to the last minute.
I hope we're not waiting to see what happens at the end of that minute. Mark.
At 11:35 PM +0930 9/30/07, Mark Prior wrote:
Alas, this particular feature set (functional IPv6 and transition tools) is not just one new protocol feature or option; it's an order of magnitude more complex and will take ISP's months (or even years) to deploy.
These are the same ISPs and vendors that seem to have managed to deploy MPLS in a more rapid fashion.
That's was very different circumstance: "See, if we light up our nationwide and metro wavelengths with MPLS, we can not only run the cool Internet stuff over it, but we can move all the intermarket/interswitch voice trunks over it, and save $$ and will make any investment back real pronto. Yep, I've got the numbers right here. Great, thanks for your help with this!" IPv6 is: "Well, umm, there's this IP assignment team, and ah.. no, I mean Internet Protocol, not the legal department. Yes, those two guys, right across from the abuse desk. Yep, the spam guys. Anyway, they say there's a real issue coming up soon, but we're not really sure when, and what?? Yes, it's likely to be past your tenure here, but still, we need to spend $$ now to be ready for this thing, and we're not really sure what the new architecture is yet. Huh? No, I don't really know what our competitors are doing, but I'm sure that... Okay, yep, I understand. I'll send it all in an email. Who else should I send it to? Hello? Hello? Can you hear me now?" ;-) /John p.s. Apologies in advance to anyone I've worked with, IP registration folks in every ISP, and for anyone who's ad tag line I may have borrowed...
On 27.09 23:51, Iljitsch van Beijnum wrote:
... The simple truth is that IPv6 will be widely deployed as soon as it reduces cost / increases income / enables features that can't be had otherwise.
And that is that ! Since there are no features that cannot be had with IPv4 this only happens when cost of deployment of IPv6 for a given network (part) is less than that of doing the same thing with IPv4. Since the only real feature of IPv6 is more addresses this only happens if it is too expensive to obtain the IPv4 address space that is required by the deployment. *) So far this has not happened often, but it already has happened in the judgement of some, like Comcast, and they deployed IPv6. It will happen more frequently and those who are not anticipating and planning ahead will pay the price for that. And they will complain that they have not been warned ..... But that is life. Daniel *) Note that features required by some deployments require more address space that can be easily obtained in IPv4. Currently these are rare but they exist.
Since there are no features that cannot be had with IPv4 this only
Scalable interdomain multicast? Think of the MSDP-mess in IPv4 vs embedded RP in IPv6. I know, I know, this won't drive IPv6 deployment, but just for the record, this is something solved with v6 and missing with v4. Maybe it'll be interesting sometime. Andras
So the governments should tax all new IPv4 only equipment and tax IPv4 Internet connectivity so that it does cost more to use v4 and then people will start using v6. Just as in the UK, increasing fuel tax makes more people use busses. NOT -- Leigh Porter UK Broadband Daniel Karrenberg wrote:
On 27.09 23:51, Iljitsch van Beijnum wrote:
... The simple truth is that IPv6 will be widely deployed as soon as it reduces cost / increases income / enables features that can't be had otherwise.
And that is that !
Since there are no features that cannot be had with IPv4 this only happens when cost of deployment of IPv6 for a given network (part) is less than that of doing the same thing with IPv4. Since the only real feature of IPv6 is more addresses this only happens if it is too expensive to obtain the IPv4 address space that is required by the deployment. *)
So far this has not happened often, but it already has happened in the judgement of some, like Comcast, and they deployed IPv6.
It will happen more frequently and those who are not anticipating and planning ahead will pay the price for that. And they will complain that they have not been warned ..... But that is life.
Daniel
*) Note that features required by some deployments require more address space that can be easily obtained in IPv4. Currently these are rare but they exist.
Leigh Porter (leigh.porter) writes:
So the governments should tax all new IPv4 only equipment and tax IPv4 Internet connectivity so that it does cost more to use v4 and then people will start using v6.
I don't think you need government taxing for that. I think that the IPv4 trading market we're about to see appear will resolve that issue very quickly. Either you can afford it, or you can't.
At 3:55 PM +0200 10/1/07, Phil Regnauld wrote:
I don't think you need government taxing for that. I think that the IPv4 trading market we're about to see appear will resolve that issue very quickly. Either you can afford it, or you can't.
What happens if folks can somehow obtain IPv4 address blocks but the cumulative route load from all of these non-hierarchical blocks prevents ISP's from routing them? /John
John, On Oct 1, 2007, at 9:15 AM, John Curran wrote:
At 3:55 PM +0200 10/1/07, Phil Regnauld wrote:
I don't think you need government taxing for that. I think that the IPv4 trading market we're about to see appear will resolve that issue very quickly. Either you can afford it, or you can't.
What happens if folks can somehow obtain IPv4 address blocks but the cumulative route load from all of these non-hierarchical blocks prevents ISP's from routing them?
Presumably, the folks with the non-hierarchical address space that might get filtered would have potentially limited connectivity (as opposed to no connectivity if they didn't have IPv4 addresses). Regards, -drc
At 5:39 AM -0700 10/2/07, David Conrad wrote:
What happens if folks can somehow obtain IPv4 address blocks but the cumulative route load from all of these non-hierarchical blocks prevents ISP's from routing them?
Presumably, the folks with the non-hierarchical address space that might get filtered would have potentially limited connectivity (as opposed to no connectivity if they didn't have IPv4 addresses).
Sure, right along ISP boundaries. If we really foul things up, you'll see some companies buying multiple "Carrier Internet" connections, one from each major carrier to get to firms which are only reachable via "the AT&T Internet", the "Verizon Internet", etc. Won't that be fun? /John
John, On Oct 2, 2007, at 6:32 AM, John Curran wrote:
At 5:39 AM -0700 10/2/07, David Conrad wrote:
What happens if folks can somehow obtain IPv4 address blocks but the cumulative route load from all of these non-hierarchical blocks prevents ISP's from routing them?
Presumably, the folks with the non-hierarchical address space that might get filtered would have potentially limited connectivity (as opposed to no connectivity if they didn't have IPv4 addresses).
Sure, right along ISP boundaries. If we really foul things up, you'll see some companies buying multiple "Carrier Internet" connections, one from each major carrier to get to firms which are only reachable via "the AT&T Internet", the "Verizon Internet", etc. Won't that be fun?
"Internet doomed, MPEG (not) at 11:00". I'll admit getting a bit weary of the FUD. It would be a bit more interesting if we hadn't been here before. I'm sure we can all come up with nightmare scenarios. The one you describe seems a bit on the edge of likelihood to me given the limited desirability of the limited networks you describe. It would seem to me that if AT&T and Verizon were to attempt a path as you describe, Comcast or NTT or BT or Reliance or ... would likely encourage them down that path. Realistically, I suspect there are less than 100 /8s that fall into the category of address space whose terms of use are sufficiently ambiguous that they are likely to be traded. Rounding up, assuming those /8s are all shattered down to /24s (won't happen of course since ISPs will want to get the largest aggregates they can, but for sake of argument...), that would mean an additional O(1M) routes dumped into the routing system over the remaining lifetime of IPv4. Older routers will indeed fall over, as they are going to fall over when we go over 240K routes, so folks will upgrade. The cost of the upgrade will be passed onto customers. ISPs not able to upgrade have the choice of (a) prefix filtering (making their service less attractive to their customers), (b) pointing default to their upstream (s), or (c) going out of business. Everything will get incrementally more expensive but I remain somewhat skeptical that there will be a fundamental change in the way the Internet works. Regards, -drc
At 3:15 PM -0700 10/2/07, David Conrad wrote:
I'll admit getting a bit weary of the FUD. It would be a bit more interesting if we hadn't been here before.
Fear, uncertainty, and doubt? Much to the contrary, the more consideration the community gives to the potential outcomes, the better prepared we'll be. "Just have faith that'll all work out" is perfectly reasonable when comes to calling a hand in a poker game, but it's an irresponsible approach for us to take on maintaining one global Internet.
Realistically, I suspect there are less than 100 /8s that fall into the category of address space whose terms of use are sufficiently ambiguous that they are likely to be traded. Rounding up, assuming those /8s are all shattered down to /24s (won't happen of course since ISPs will want to get the largest aggregates they can, but for sake of argument...),
Hold on here... uniqueness is the desired property for the vast majority of potential holders of those address blocks, and they have no particular reason to respect your imaginary /24 boundary. It all depends on the rules of the "market". Lots of folks have been saying "don't worry, the market will figure it all out." Well, unfortunately I agree, but that means that an open market will behave to maximize value. If the community wants to set one up, then there *will* be sites that chop up their existing /24 into 4 pieces, NAT behind one /26, and sell the other 3 just for $$. Let's just hope that the value of 16 /28's isn't more compelling. FYI - there isn't an ISP out there who won't go along with that, allow the customer to "bring-your-own IPv4" block and attempt to route it when it means the difference between adding a new customer or turning them away.
that would mean an additional O(1M) routes dumped into the routing system over the remaining lifetime of IPv4.
Nope... one gets to go much much higher as the pressure increases (unless you've got some interesting assumptions about how this all plays out that differ from the above...) Does your market model prevent fragmentation? Or is their an global routing table entry fee that is somehow established to provide back pressure? If you want to say "the market will figure it out", that's okay too... (but *that* is the path with the highest uncertainty and doubt of all, so don't be surprised if a folks ask for a little more certainty before they bet their livelihood on faith) /John
John, On Oct 2, 2007, at 3:57 PM, John Curran wrote:
At 3:15 PM -0700 10/2/07, David Conrad wrote: "Just have faith that'll all work out" is perfectly reasonable when comes to calling a hand in a poker game, but it's an irresponsible approach for us to take on maintaining one global Internet.
To paraphrase Bill Manning, can you point me at the "one global Internet"? a) We've already broken that (see IPv6 and/or NAT). b) Last I looked, the Internet was an interconnection of private networks generally based on IP, each with their own policy regarding what is accepted or not accepted for routing. But you know this. I am somewhat surprised that you believe a multi- billion (if not multi-trillion) dollar industry is simply going to throw up its hands at the first signs of a market, but perhaps you have information I do not.
Realistically, I suspect there are less than 100 /8s that fall into the category of address space whose terms of use are sufficiently ambiguous that they are likely to be traded. Rounding up, assuming those /8s are all shattered down to /24s (won't happen of course since ISPs will want to get the largest aggregates they can, but for sake of argument...),
Hold on here... uniqueness is the desired property for the vast majority of potential holders of those address blocks,
Actually, I suspect the vast majority of potential holders of addresses don't care all that much about uniqueness. They care about being able to reach the content and services they're interested in. As such, NAT (and hence non-uniqueness) is a perfectly workable solution for them. For the tiny subset that actually want to provide services, uniqueness is generally a pre-requisite, but what percentage of the IPv4 address space is used to provide services?
and they have no particular reason to respect your imaginary /24 boundary.
My imaginary boundary? Interesting. You are asserting that ISPs are going to start accepting prefixes longer than /24, particularly in the face of the FUD spread about how everybody's routers are going to turn to slag? Why would they do this?
FYI - there isn't an ISP out there who won't go along with that, allow the customer to "bring-your-own IPv4" block and attempt to route it when it means the difference between adding a new customer or turning them away.
Of course. However, the fact that someone announces a prefix does NOT mean every ISP on the planet, particularly those with old, memory limited routers must accept that prefix. Again, we've been here before. You and I both have the t-shirts. What happened when routers started falling over circa 1996? Why do you believe things will be different this time? Presumably you have a reason.
Does your market model prevent fragmentation?
Nope. Fragmentation will occur. The question is to what level. Why should an ISP go in and modify its existing prefix length filters in order to gain routability to somebody else's new customer? If an ISP does not have prefix length filters and it begins to see resource constraints in its routers, why should an ISP not deploy prefix length filters corresponding to what has been traditionally assumed about reasonable maximal prefix length? If you were actually worried about an explosion of routing information, I'd think you'd be campaigning for greater implementation of prefix length filters on the legacy /8s that are likely to be the first entrants into a free for all. I find it a bit strange that instead, you're going around proclaiming the sky is going to fall in various odd ways.
If you want to say "the market will figure it out", that's okay too... (but *that* is the path with the highest uncertainty and doubt of all, so don't be surprised if a folks ask for a little more certainty before they bet their livelihood on faith)
Certainty? Didn't know routability rated up there with death and taxes. I've asked several times, but have yet to see a concrete answer: What is your proposed alternative to a market in IPv4 addresses and, more importantly, how are you going to enforce it? Regards, -drc
At 7:01 PM -0700 10/2/07, David Conrad wrote:
Actually, I suspect the vast majority of potential holders of addresses don't care all that much about uniqueness. They care about being able to reach the content and services they're interested in. As such, NAT (and hence non-uniqueness) is a perfectly workable solution for them. For the tiny subset that actually want to provide services, uniqueness is generally a pre-requisite, but what percentage of the IPv4 address space is used to provide services?
Most organizations connecting to the Internet want at least a few static unique addresses for web and mail servers. It may not be 100% of the organizations connecting, but it's very close.
My imaginary boundary? Interesting. You are asserting that ISPs are going to start accepting prefixes longer than /24, particularly in the face of the FUD spread about how everybody's routers are going to turn to slag? Why would they do this?
A lot of ISP's will have no choice but to announce such or lose the asking customer to someone who will... The largest ISP's are very likely to accept longer routes from each other in order to facilitate their own continued growth, and pay the cost of the router upgrades (presuming they can actually upgrade fast enough to keep up with the tragedy of the commons run on "free" address table entries...) Whether they accept longer prefixes from smaller ISP's is is a different question...
Again, we've been here before. You and I both have the t-shirts. What happened when routers started falling over circa 1996? Why do you believe things will be different this time? Presumably you have a reason.
How does AT&T refuse numerous additional prefixes from BT, if they in turn need to announce numerous additions in order to grow? Sales and marketing never take kindly to being told "stop selling, we're full", and doubly so when competitors are busy connecting new customers without adhering to all this route filtering stuff in the way the quarterly numbers.
Nope. Fragmentation will occur. The question is to what level. Why should an ISP go in and modify its existing prefix length filters in order to gain routability to somebody else's new customer?
See above. They'll change it the day they're asked and find themselves needing to announce longer prefixes as well. Really, the ability of filtering to survive in the face of competitive pressure was already well-tested, and the result are: they don't. Reference Randy's earlier post on same.
If you were actually worried about an explosion of routing information, I'd think you'd be campaigning for greater implementation of prefix length filters on the legacy /8s that are likely to be the first entrants into a free for all.
Sounds like wonderful idea... run with it. One could even imagine a circumstance where such available /8's were reclaimed by the IANA and issued per RFC2050 & ASO-001-2.
What is your proposed alternative to a market in IPv4 addresses and, more importantly, how are you going to enforce it?
IPv6, and publicly arguing against betting the Internet in the absence of a solid plan. May not actually work, but ihe task comes with the job description... We're likely going to have to agree to disagree on the impacts of a "market", as you see an "additional O(1M) routes" being the total impact (over the remaining lifetime of IPv4!), whereas I see no such limit on additional routes with balkanization as the inevitable result. /John
On Tue, Oct 02, 2007, John Curran wrote:
We're likely going to have to agree to disagree on the impacts of a "market", as you see an "additional O(1M) routes" being the total impact (over the remaining lifetime of IPv4!), whereas I see no such limit on additional routes with balkanization as the inevitable result.
Has anyone modelled the behaviour of current equipment in a world with 1 million ipv6 table entries? Heck, what about a world with 500,000 ipv6 entries and a BGP announcement churn rate along GIH's prediction curve? Adrian
John, On Oct 2, 2007, at 8:25 PM, John Curran wrote:
At 7:01 PM -0700 10/2/07, David Conrad wrote: Most organizations connecting to the Internet want at least a few static unique addresses for web and mail servers.
Do they? I suppose it depends on your definition of 'organization'. Presumably, your definition excludes nearly all home users and most SOHOs who outsource their web pages and mail services. It would be interesting to see actual data from ISPs describing where their address space is going today, but I imagine they consider this confidential. However, you seem to be assuming there will be no change in end user or ISP behavior as the IPv4 free pool runs out and after. This seems stunningly counter-intuitive to me, but presumably you have a reason for making this assumption. Care to share?
My imaginary boundary? Interesting. You are asserting that ISPs are going to start accepting prefixes longer than /24, particularly in the face of the FUD spread about how everybody's routers are going to turn to slag? Why would they do this? A lot of ISP's will have no choice but to announce such or lose the asking customer to someone who will...
"announce" != "accept".
The largest ISP's are very likely to accept longer routes from each other in order to facilitate their own continued growth, and pay the cost of the router upgrades (presuming they can actually upgrade fast enough to keep up with the tragedy of the commons run on "free" address table entries...)
You are asserting that the largest ISPs will simply accept everything thrown at them up to and after their routers start falling over. Again, this seems stunningly counter-intuitive to me. This hasn't been ISP behavior in the past nor present. Not sure why you think it will be their behavior in the future.
Again, we've been here before. You and I both have the t-shirts. What happened when routers started falling over circa 1996? Why do you believe things will be different this time? Presumably you have a reason. How does AT&T refuse numerous additional prefixes from BT, if they in turn need to announce numerous additions in order to grow?
The fact that a peer refuses to accept your customer's very long prefixes would be unfortunate, but presumably no ISP guarantees network behavior in networks they have no control over.
Sales and marketing never take kindly to being told "stop selling, we're full", and doubly so when competitors are busy connecting new customers without adhering to all this route filtering stuff in the way the quarterly numbers.
Sales and marketing can continue to sell IPv4 /32s if they so desire and they might even be useful on the network they represent. However, one would hope sales and marketing folk are not making assertions about how other networks operate, what those networks will accept and route, etc. Even if the sales and marketing folk are making such silly assertions, presumably standard ISP T&Cs limit the responsibility of the ISP to the network they have direct control over.
Nope. Fragmentation will occur. The question is to what level. Why should an ISP go in and modify its existing prefix length filters in order to gain routability to somebody else's new customer? See above. They'll change it the day they're asked and find themselves needing to announce longer prefixes as well. Really, the ability of filtering to survive in the face of competitive pressure was already well-tested, and the result are: they don't.
They didn't because technology had advanced to the point where they were no longer necessary. Routers on the network imposing the filters weren't falling over, thus the network engineering arguments that they couldn't remove the filters because routers would fall over would no longer fly.
If you were actually worried about an explosion of routing information, I'd think you'd be campaigning for greater implementation of prefix length filters on the legacy /8s that are likely to be the first entrants into a free for all. Sounds like wonderful idea... run with it.
"You" != "me". You are the one who is asserting that the routing sky will fall if the current monopolistic command economy alters. I believe ISPs will look out for themselves and do what is necessary to protect their own infrastructure such that they can continue to operate. You appear to see the ISPs as victims without any control over their own fate. Maybe they are and I should sell their stock short.
What is your proposed alternative to a market in IPv4 addresses and, more importantly, how are you going to enforce it? IPv6, and publicly arguing against betting the Internet in the absence of a solid plan.
So you are saying that other than everyone magically transitioning to IPv6 before IPv4 free pool exhaustion, you have no alternative and no way to enforce the status quo. Strangely enough, that is what I am suggesting. I guess where we differ is in the assumption that the lack of a solid plan implies the law of supply and demand is rescinded. Regards, -drc
At 7:01 PM -0700 10/2/07, David Conrad wrote:
For the tiny subset that actually want to provide services, uniqueness is generally a pre-requisite, but what percentage of the IPv4 address space is used to provide services?
You mean like the p2p "services" which are such a large percentage of bulk traffic? Or the udp media stream "service" I provide for video chats with Gabriel's nana and uncles? I personally think of them as applications, but if you want to see them as service, fine by me. Uniqueness is a mighty handy property, as anyone trying to implement ICE to get SIP working across NATs will gladly tell you. Ted
Ted, On Oct 2, 2007, at 9:14 PM, Ted Hardie wrote:
At 7:01 PM -0700 10/2/07, David Conrad wrote:
For the tiny subset that actually want to provide services, uniqueness is generally a pre-requisite, but what percentage of the IPv4 address space is used to provide services? Uniqueness is a mighty handy property, as anyone trying to implement ICE to get SIP working across NATs will gladly tell you.
Yep, sure is. Maybe the lack of uniqueness in IPv4 will be sufficient to drive IPv6. But "might handy" isn't "absolute, fundamental requirement". I think you're missing my point. There are entire continents of people behind single or double NATv4 and they are able to function and communicate. It may not be optimal, but it is workable, particularly for a limited set of applications and services. If we want people to invest in IPv6, we need to explain to them why it will benefit them in terms they understand. There is a billion people's worth of inertia here, so I'm somewhat skeptical that "because you get unique addresses" has sufficient energy to get significant forward motion. Regards, -drc
On 2 Oct 2007, at 23:15, David Conrad wrote:
Older routers will indeed fall over, as they are going to fall over when we go over 240K routes, so folks will upgrade.
Some people wont (want to or be able to). I am trying to do some quick exercises in my head to work out which networks will be most affected when prefixes get more aggressive, or bgp updates get dropped. My thoughts are that the networks which deagg most, will have the largest problem being reached in this event. I think we informally call this Rough Justice on the right hand side of the pond. When we give someone advice about why they're not reachable, it's going to start to be much more valuable an exercise to check closely the size of their announcements. Andy
On Oct 1, 2007, at 9:15 AM, John Curran wrote:
What happens if folks can somehow obtain IPv4 address blocks but the cumulative route load from all of these non-hierarchical blocks prevents ISP's from routing them?
drc@virtualized.org (David Conrad) writes:
Presumably, the folks with the non-hierarchical address space that might get filtered would have potentially limited connectivity (as opposed to no connectivity if they didn't have IPv4 addresses).
i had a totally different picture in my head, which was of a rolling outage of routers unable to cope with "full routing" in the face of this kind of unaggregated/nonhierarchical table, followed by a surge of bankruptcies and mergers and buyouts as those without access to sufficient new-router capital gave way to those with such access, followed by another surge of bankruptcies and mergers as those who thought they had access to such capital couldn't make their payments. call me a glass-half-full kind of guy, but the picture in my head in response to john's question is of a whole lot of network churn as the community jointly answers the question "who can still play in this world?" rather than "how useful will those new routes really be?" internet economics don't admit the possibility of not-full-routes, and so david's view that nonhierarchical routes won't be as useful as hierarchical makes me wonder, what isp anywhere will stay in business while not routing "everything" if other isp's can route "everything"? we're all in this stew pot together. -- Paul Vixie
On Tue, Oct 02, 2007 at 01:57:15PM +0000, Paul Vixie wrote:
On Oct 1, 2007, at 9:15 AM, John Curran wrote:
What happens if folks can somehow obtain IPv4 address blocks but the cumulative route load from all of these non-hierarchical blocks prevents ISP's from routing them?
drc@virtualized.org (David Conrad) writes:
Presumably, the folks with the non-hierarchical address space that might get filtered would have potentially limited connectivity (as opposed to no connectivity if they didn't have IPv4 addresses).
i had a totally different picture in my head, which was of a rolling outage of routers unable to cope with "full routing" in the face of this kind of unaggregated/nonhierarchical table, followed by a surge of bankruptcies and mergers and buyouts as those without access to sufficient new-router capital gave way to those with such access, followed by another surge of bankruptcies and mergers as those who thought they had access to such capital couldn't make their payments.
call me a glass-half-full kind of guy, but the picture in my head in response to john's question is of a whole lot of network churn as the community jointly answers the question "who can still play in this world?" rather than "how useful will those new routes really be?" internet economics don't admit the possibility of not-full-routes, and so david's view that nonhierarchical routes won't be as useful as hierarchical makes me wonder, what isp anywhere will stay in business while not routing "everything" if other isp's can route "everything"?
we're all in this stew pot together. -- Paul Vixie
stewing melds flavors, i hope we have a good chef. that said, i'm kind of leaning toward what i think of as DRC's view... but to clarify, can you tell me the economic incentive to carry route prefixes that you will only ever use to accept SPAM? --bill
i had a totally different picture in my head, which was of a rolling outage of routers unable to cope with "full routing" in the face of this kind of unaggregated/nonhierarchical table
been there done that
followed by a surge of bankruptcies and mergers and buyouts
and that is not what happened last time, so why should it happen this time? randy
Randy,
with all due respect, jari; maybe the number of groups is neither the problem nor the solution
too much energy has been and is still being wasted dealing with overly cute/complex ideas these wgs invent to fancy up ipv6 so it will be deployed; from tla/nla/... to ula to sham6. this has prevented focusing on the real problems of deployment so they can be solved.
I know this very well. But I'm listening. We are already trying to do something about nat-pt. What else would you see as a priority? Jari
I know this very well. But I'm listening. We are already trying to do something about nat-pt. What else would you see as a priority?
give v6 a break and stop complicating it further while we figure out how the heck to deploy it. though maybe the old benchmark/testing stuff could be revived to do forwarding and control plane performance testing so we can get some honesty into the vendor game. randy
participants (33)
-
Adrian Chadd
-
Alain Durand
-
Andy Davidson
-
bmanning@vacation.karoshi.com
-
Church, Charles
-
Daniel Karrenberg
-
Daniel Senie
-
David Conrad
-
Duane Waddle
-
Eliot Lear
-
Fred Baker
-
Iljitsch van Beijnum
-
JAKO Andras
-
Jari Arkko
-
Jeroen Massar
-
John Curran
-
JORDI PALET MARTINEZ
-
Kevin Oberman
-
Leigh Porter
-
Mark Andrews
-
Mark Newton
-
Mark Prior
-
Marshall Eubanks
-
michael.dillon@bt.com
-
Owen DeLong
-
Paul Vixie
-
Perry Lorier
-
Phil Regnauld
-
Randy Bush
-
Stephen Sprunk
-
Steven M. Bellovin
-
Ted Hardie
-
Valdis.Kletnieks@vt.edu