Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/15/10 11:04 AM, ned+i...@mauve.mrochek.com wrote: And since I'm not in the best of moods I'll also answer in kind by saying us application engineers might also be waiting for someone with half a clue as to how to design a proper standard API to come along and do that. Ned, Agreed, better progress should have been made. What impact do you see a new suite of network APIs making? That depends on what API you're talking about, and what you're hoping to accomplish. At this point work on the core C API, with the intent of helping along IPv6 deployment by getting application developers on board is IMO a complete waste of time. Consider: Given how these things go and what needs to be done, we'd be lucky to have anything in 18 months, and 2-3 years is not beyond possibility. And that's just the start. Even if you assume implementations are done in line as the standard is developed, think how long it will be before there will be enough deployment that application developers will be able to count on the new routines enoough to take advantage of them. An aside. We got a new, corporate-standard Windows laptop for our office the other day. (Needed because everyone in the office is on Mac but a bunch of Oracle internal appls only work on Windows.) Both the box and the laptop itself were covered with Windows 7 stickers. BUt when we booted the thing, XP came up. The original Windows 7 install had been erased and replaced with the corporate standard configuration, which is currently XP despite the fact that XP is now almost 9 years old. And I doubt if Oracle is alone in doing this sort of thing. This, like it or not, is the world application developers live in. A new API may sound really keen, but it's useless until you can count on it being present on the overwhelming majority of the platforms people actually use. And the lead time there seems to best be measured in decades, not years. Now, if the goal is simply to make the world a better place for application development, then sure, coming up with a standard connectbyname interface makes all sorts of sense. But maybe this time someone might want to talk with the folks who actually make the most use of the API when designing it. Just sayin'. Another alternative would be to try and improve the routines available in various higher level programming languages, which while in general far superior to the socket level stuff are nevertheless lackiing in various ways. It is much easier to deploy a new version of Java, PHP, Perl etc. than it is to deploy stuff at the operating system level. But once again, since most of the popular languages were updated to support IPv6 some time ago, meaning most applications written in those languages just work with IPv6 with no changes, this isn't going to help IPv6 deployment much if at all. Broader support for SRV records, OTOH, is a need that might be met to some extent this way. It is not hard to understand a view that one should avoid making NATP translations, where IPv6 should easily be able to avoid this issue. THe operative word here is should, Sure, the glut of addresses IPv6 provides theoretically solves this problem. But in practice, the lack of IPv6 connectivity for the overwhelming majority of users means that anyone counting on IPv6 to eliminate the need for either mutlple IPv4 addresses or NATPT is being extraordinarily foolish. When dealing with older code that should have been changed, dual stack transitional schemes, such as ds-lite or 6to4, depend less on existing code working directly with IPv6. You're significantly overestimating the issues with existing code, and significantly underestimating the other problematic aspects of IPv6 deployment. Most expect port mapping agility, or manual intervention will retain functionality by moving this function to the realm of newer equipment. Access to maintenance interfaces is another area where proprietary schemes are working well. Even Debian distributions such as Ubuntu, offer pre-installed services which make remote configuration easier and safer. Having fewer maintenance interfaces exposed directly to the Internet is a good thing, since few older interfaces have adequate protection. Here is a document that explains how the aiport router supports an API for managing port mappings: http://tools.ietf.org/html/draft-cheshire-nat-pmp-03 I'm sure this solves a problems for someone somewhere, but it doesn't address any of the issues I've raised in any meaningful way. This approach avoids complex service and device specific structures, and dependence upon insecure, complex, and proprietary assignment protocols that ultimately depend upon users being updated and knowing when to click okay. No doubt it does, but since none of these things you're railing against are at issue here, it's entirely irrelevant. Ned ___ Ietf mailing list Ietf@ietf.org
Re: The point is to change it: Was: IPv4 depletion makes CNN
Hi, On 6/1/10 7:19 PM, ned+i...@mauve.mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned recently, RIPE Labs have published the results of a consumer panel testing of the CPE's (what you refer to as SOHO grade router) : http://labs.ripe.net/content/ipv6-cpe-survey Please see the comments, or contribute your results, to the FOrum: http://labs.ripe.net/node/264/ Also, there is some information on the ARIN's wiki: http://www.getipv6.info/index.php/Broadband_CPE Regards, Vesna Manojlovic RIPE NCC trainer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
getaddrinfo() works for clients. It does not work for servers, in particular it does not work for peer-to-peer services that may be hidden behind layers of NAT44, NAT46 and NAT64. Port forwarding requests have to be a part of the model. That in turn means that there has to be a security model. And the well known port approach for discovery really does not work for Web Services where we already have more services than ports. The API has to hide all the complexity, not just some of it. And it has to be compatible with coding in scripting languages like Perl or Ruby, not just something that can be done from C++ with a Mb plus of networking stack. These are not difficult problems. In fact the remaining issues are difficult because they are easy, not because they are hard. Anyone can have an opinion on how to label SRV prefixes for services. And many people do. Net result is that what should have been done ten years ago is still incomplete. Ever wondered why Henry Ford only made cars in black? He observed that the more choices a customer was faced with, the longer it took them to come to a buying decision. Even more so when multiple people were making the decision. Decisions that had practical consequences were easy to solve as either there was a need or was not. Decisions such as color that had no practical consequence took forever. One of the reasons X.500 directory deployment was a nightmare was that the design of the directory tree and DIT had no technical consequence, only political consequences. On Tue, Jun 15, 2010 at 1:30 PM, Fred Baker f...@cisco.com wrote: On Jun 15, 2010, at 5:57 AM, Phillip Hallam-Baker wrote: But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. So, things like implementing getaddrinfo() to replace gethostbyname() and as a result making the applications network layer agnostic. The kind of thing that not only helps with IPv6 deployment, but makes multi-homing work well for the IPv4-only application as well, makes solutions like pnat irrelevant, and all that. http://www.ietf.org/rfc/rfc2553.txt 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc3493.txt 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL) Supported in Windows, Mac/BSD, Linux, you name it. Been there a long time. Yes, all we need is application engineers with a network clue. They seem to be hard to come by. I have a solution. Let's go through those OS's and rename gethostbyname to GetHostByName. Put in huge comments everywhere that the character string is found (man pages, which btw already have this, and in the code itself) if you use this, you're an idiot. Make folks use their heads momentarily. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
The mistake there being to insist on implementation of the IPv6 specification rather than what is necessary to enable the transition to IPv6. You can't build a building without scaffolding. In the middle ages the design of the scaffold was often as great an engineering feat as the building (c.f. Brunelleschi and the dome of Florence cathedral). We have had a lot of people focused on the desired end state and not enough consideration given to what it takes to get to that end state. The idea of developing technology whose sole purpose is to enable a transition is not always appreciated. I am just writing a proposal in another field which argues for a considerable sum to be invested for the sole purpose of reducing the number of indispensable parties by one. I have no particular reason to expect that party not to co-operate. In fact I have designed the political drivers so that their participation is eventually inevitable. But I need to convince other parties to move before this has become generally apparent. On Tue, Jun 15, 2010 at 1:45 PM, Melinda Shore melinda.sh...@gmail.com wrote: Fred Baker wrote: I have a solution. Let's go through those OS's and rename gethostbyname to GetHostByName. Put in huge comments everywhere that the character string is found (man pages, which btw already have this, and in the code itself) if you use this, you're an idiot. Make folks use their heads momentarily. That's actually how a number of problems were fixed in the BSD libraries. gcc came along and it flagged some things - as errors - that weren't really incorrect but were bad practice (writing into constant strings, for example). Can't imagine anything like that happening today. We've gotten a vendor or two to implement v6 in their products by explaining that we've got a non-negotiable requirement for it and that we'd be unable to continue to license their stuff without it. Melinda -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
Anyone can design a system for use by highly motivated geniuses. It takes a lot more skill to build something that can be used by people whose primary motivation is not to make 'your stuff' work. The issue Ned raises is very typical of what most engineers spend 80% of their time on - fixing stupid issues that need never have existed if someone else had done their job a little better or described what they are doing more accurately. The only people who are going to have labs set up to test the full range of IPv6 interop issues are people whose primary focus is IPv6 interop. Ergo anyone who wants the typical application engineer to develop IPv6 compatible code had better work out how to completely encapsulate all those issues at the platform level. On Tue, Jun 15, 2010 at 3:42 PM, Dave CROCKER d...@dcrocker.net wrote: On 6/15/2010 7:30 PM, Fred Baker wrote: Yes, all we need is application engineers with a network clue. They seem to be hard to come by. Every layer is clue-challenged, when it comes to staffing. Possibly at other times, too. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/15/10 11:04 AM, ned+i...@mauve.mrochek.com wrote: And since I'm not in the best of moods I'll also answer in kind by saying us application engineers might also be waiting for someone with half a clue as to how to design a proper standard API to come along and do that. Ned, Agreed, better progress should have been made. What impact do you see a new suite of network APIs making? It is not hard to understand a view that one should avoid making NATP translations, where IPv6 should easily be able to avoid this issue. When dealing with older code that should have been changed, dual stack transitional schemes, such as ds-lite or 6to4, depend less on existing code working directly with IPv6. Most expect port mapping agility, or manual intervention will retain functionality by moving this function to the realm of newer equipment. Access to maintenance interfaces is another area where proprietary schemes are working well. Even Debian distributions such as Ubuntu, offer pre-installed services which make remote configuration easier and safer. Having fewer maintenance interfaces exposed directly to the Internet is a good thing, since few older interfaces have adequate protection. Here is a document that explains how the aiport router supports an API for managing port mappings: http://tools.ietf.org/html/draft-cheshire-nat-pmp-03 This approach avoids complex service and device specific structures, and dependence upon insecure, complex, and proprietary assignment protocols that ultimately depend upon users being updated and knowing when to click okay. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Dear all, I follow this amusing debate - I'm not reacting to this post specifically. I would like to point out that there are people out there specifying communication architectures for new uses of the Internet, e.g. Cooperative Systems for communications involving vehicles. The system running between all entities composing their network will be living in an IPv6-only world. They will only deploy transition mechanisms to keep communication going on with other parts of the Internet not running IPv6, if that proportion is still significant by the time these new systems get deployed (hopefully, they won't have to do so, and for sure they won't deploy dual stack). It seems to me that these new uses are always ignored when one is debatting transition from IPv4 to IPv6. In some many cases, it is simply transition from something not IP to IPv6. So, there will be IPv6-only systems deployed out there (the sad news is that there are also sectors transitioning from non IP (e.g. X25) to IPv4 - just because they are not aware about IPv6 or are still thinking IPv6 is for the next decade). Regards, Thierry. On 15/06/10 02:10, Mark Andrews wrote: In messageaanlktimoqnpmkcbitki07kag9xtroyiv84rqsmo0d...@mail.gmail.com, Phil lip Hallam-Baker writes: On Thu, Jun 10, 2010 at 11:04 PM, Mark Andrewsma...@isc.org wrote: I'm thinking 10, 15+ years out when there are lots of IPv6 only served zones. Much the same way we no longer worry about MTA's that don't know about MX records and no longer add A records to accomodate them. Why would there be any IPv6 only served zones? Because it going to get harder and harder to get stable IPv4 addresses. ISP's are looking at moving their entire client base from having unshared public addresses to shared public addresses. What John and I have been trying to get across here is that there is no incentive to create an IPv6 only zone now and never will be in the future. You present an induction without a base case. Except IPv6 only zones already exist so there must be some incentive to have them. Back in the days when Internet on phones meant WAP, there was a possibility of them being supported on IPv6. But now the iPhone has changed the model and the Web on a phone will look just like the rest of the net and so they have to run IPv4. That is the big flaw in the IPv6 ready program. It assumes that the incentive for transition is that IPv6 is a good in itself. It is not, in fact IPv6 will be slower (more header baggage) than IPv4 and if you are IPv6 only you will have to go through gateways. And IPv4 will have multiple header re-writting. DPI to fix up the fact that headers have been re-written multiple times along with checksum re-calculations etc. I actually expect IPv6 to be faster in the end if only marginally. Most measurements to day say that IPv4 and IPv6 are roughly the same. We do seem to be making some progress. I have been banging on about this problem for six years. When I started NAT was universally considered to be the problem. People are now seeing the NAT-PT approach as being a possible framework for a solution rather than something to be deprecated as 'historic' because they (wrongly) imagine true Internet is NAT-free. The more I look at NAT-PT (NAT64/DNS64) the less I like it. Way too many kludges especially when there is an alternative, DS-lite, which doesn't have nearly as many problems that need to be kludged around. Mark attachment: thierry_ernst.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
At Fri, 11 Jun 2010 23:30:03 -0400, Phillip Hallam-Baker
wrote, in response to a message from Masataka Ohta:
The URI syntax you specify is only used for some protocols and most of
the elements are defaulted. In fact we have got to the point where for
Web browsing everything is defaulted except for the domain name.
I think we need to break the idea that a Web service should have a URL
that starts HTTP.
Sounds reasonable, but below you obviously want to arrive at just
such a HTTP URI!
Rather, if we are connecting to the Google mapping Web Service we
would type in either
google.com - if the type of service needed was obvious from the context
ws:google.com:maps - for the fully qualified version
Under the covers this would of course expand via SRV to a http URL,
probably something of the form
http://services1.google.com/ws/maps/1/0
http://services2.google.com/ws/maps/1/0
Since the SRV record is expanding to a domain name that we presume to
be reserved for hosting of Web services we can take over the
specification of the URI stem in the protocol.
I'm getting confused very much.
DNS SRV RRs map a triple
{domain name, transport protocol, service name}
to a target FQDN and a service port number (where the application
server is listening) -- setting aside the priority information,
which esentially allows to add redundancy and fallback, but no
additional kind of information.
So you already need to know the service name and the transport protocol.
That might be reasonable in your context.
But how do you envision to obtain the URIs (like those you show above)
from the RDATA in a SRV RR?
Did you have in mind a (yet unspecified) DDDS (RFC 3401-3404)
application, which would employ the use of DNS NAPTR RRs
(and then most likely SRV RRs as a 'backend') ?
NAPTR RRs can (with particular flag settings) produce an URI
out of a domain name and a service tag. But please note that
NAPTR RRs contain the service tag as an embedded selector and
therefore need particular thoughts -- cf. the IAB deliberations
in RFC 5507.
Kind regards,
Alfred Hönes.
--
+++
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: a...@tr-sys.de |
+++
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On Mon, Jun 14, 2010 at 1:18 PM, Alfred HÎnes a...@tr-sys.de wrote:
At Fri, 11 Jun 2010 23:30:03 -0400, Phillip Hallam-Baker
wrote, in response to a message from Masataka Ohta:
The URI syntax you specify is only used for some protocols and most of
the elements are defaulted. In fact we have got to the point where for
Web browsing everything is defaulted except for the domain name.
I think we need to break the idea that a Web service should have a URL
that starts HTTP.
Sounds reasonable, but below you obviously want to arrive at just
such a HTTP URI!
Of course we would use HTTP under the covers for quite some time,
possibly indefinitely. But the advantage of abstracting it away from
the URI is that we are not obliged to.
Rather, if we are connecting to the Google mapping Web Service we
would type in either
google.com - if the type of service needed was obvious from the context
ws:google.com:maps - for the fully qualified version
Under the covers this would of course expand via SRV to a http URL,
probably something of the form
http://services1.google.com/ws/maps/1/0
http://services2.google.com/ws/maps/1/0
Since the SRV record is expanding to a domain name that we presume to
be reserved for hosting of Web services we can take over the
specification of the URI stem in the protocol.
I'm getting confused very much.
DNS SRV RRs map a triple
{domain name, transport protocol, service name}
to a target FQDN and a service port number (where the application
server is listening) -- setting aside the priority information,
which esentially allows to add redundancy and fallback, but no
additional kind of information.
So you already need to know the service name and the transport protocol.
That might be reasonable in your context.
But how do you envision to obtain the URIs (like those you show above)
from the RDATA in a SRV RR?
Let us imagine that we have a client that implements version 1.0 - 2.3
of the _maps._ws Web service.
The host that is supporting that Web service is probably going to be
running multiple web services and quite likely different versions of
that Web Service. In some cases it may be desirable to run different
executables to support different Web Service versions.
It is one thing to require a host to have a different domain name for
use to bind Web services. Requiring a new DNS name to be registered
for every Web Service instance on the host would violate the single
point of administration principle.
So as a practical matter the host services1.example.com would probably
have a services layout something like
http://services1.example.com/_ws/_maps/1/0 [maps1.exe]
http://services1.example.com/_ws/_maps/2/0 [maps_new.exe]
http://services1.example.com/_ws/_xkms/*[xkms.cgi.exe]
http://services1.example.com/_ws/_keyprov/*[keyprov.exe]
... etc
The URI stem being formed from the SRV protocol prefix and the
protocol version number
First lets look through what the client has to do if there is no
negotiation information in the DNS besides the SRV record.
The client pulls the SRV record _maps._ws.example.com and chooses a
host according to the weighting. It now has to choose a protocol
version to attempt. If version 2.0 is incompatible with version 1.0
the client is going to have to guess which one to attempt first.
Better is to have a mechanism that allows the site to tell the client
which Web Service versions are supported so that the correct one can
be chosen. In some cases this may mean selecting a different host
because the legacy Web service version is only supported on an older
host.
Did you have in mind a (yet unspecified) DDDS (RFC 3401-3404)
application, which would employ the use of DNS NAPTR RRs
(and then most likely SRV RRs as a 'backend') ?
NAPTR RRs can (with particular flag settings) produce an URI
out of a domain name and a service tag. But please note that
NAPTR RRs contain the service tag as an embedded selector and
therefore need particular thoughts -- cf. the IAB deliberations
in RFC 5507.
I am not a fan of NAPTR. Regular expressions have a great deal of
power and really should not be resorted to lightly in my view.
In this case I want to get to a world where the SRV records can be
managed automatically by the service applications themselves. To make
that practical I need to squeeze out all the flexibility and site
specific options from the configuration as is possible.
While machines can write their own NAPTR records they are not able to
make sense of records written by humans.
The idea here is that to place the Web service on IIS or Apache, the
code module simply requests access to the relevant Web Service prefix
port and the Web server then makes the (authenticated) dynamic DNS
request to register the SRV record. When the Web service shuts down
the SRV record can be automatically deleted.
--
Website: http://hallambaker.com/
___
Ietf mailing list
Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
Yes, I am aware that some applications are IPv6 only. But I don't think that they have enough momentum to carry the IPv4 world forward into IPv6. The applications that are following that route are self-selecting for requiring little or no IPv4 connectivity. There are two models of technology adoption that might be applicable here. The paradigm that I think most IETF transition planning was based on was vinyl being replaced by CD. The advantages of CD were obvious to anyone who wasn't an audiophile bore who had spent $5000 on a turntable and some clever marketing. So the transition occurred even though it required people to repurchase their vinyl records on CD. But IPv6 does not deliver a clear technical advantage to the purchaser over IPv4. So the model that is more appropriate is Betamax vs. VHS and the question is whether the technical factors that the designers think people should care about (picture quality, ability to freeze frame) win over the ones that they actually care about (ability to record feature length movie on one tape, open standards, availability of content). If we were in a vinyl/CD type race then the previous IETF strategy of attempting to maximize the differences between the technologies would make sense. In that circumstance you would want to kill off NAT64 and so on. But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. [Oh and I am aware of the ridiculous claims by Lieberwitz and Margolis concerning the history of Betamax/VHS. As with their work on QWERTY, it was performed for a DC thunk tank being paid to deliver an argument that network effects do not exist. As such it is paid advocacy, not scholarship and their claims do not merit consideration.] On Tue, Jun 15, 2010 at 4:31 AM, Thierry Ernst thierry.er...@inria.fr wrote: Dear all, I follow this amusing debate - I'm not reacting to this post specifically. I would like to point out that there are people out there specifying communication architectures for new uses of the Internet, e.g. Cooperative Systems for communications involving vehicles. The system running between all entities composing their network will be living in an IPv6-only world. They will only deploy transition mechanisms to keep communication going on with other parts of the Internet not running IPv6, if that proportion is still significant by the time these new systems get deployed (hopefully, they won't have to do so, and for sure they won't deploy dual stack). It seems to me that these new uses are always ignored when one is debatting transition from IPv4 to IPv6. In some many cases, it is simply transition from something not IP to IPv6. So, there will be IPv6-only systems deployed out there (the sad news is that there are also sectors transitioning from non IP (e.g. X25) to IPv4 - just because they are not aware about IPv6 or are still thinking IPv6 is for the next decade). Regards, Thierry. On 15/06/10 02:10, Mark Andrews wrote: In messageaanlktimoqnpmkcbitki07kag9xtroyiv84rqsmo0d...@mail.gmail.com, Phil lip Hallam-Baker writes: On Thu, Jun 10, 2010 at 11:04 PM, Mark Andrewsma...@isc.org wrote: I'm thinking 10, 15+ years out when there are lots of IPv6 only served zones. Much the same way we no longer worry about MTA's that don't know about MX records and no longer add A records to accomodate them. Why would there be any IPv6 only served zones? Because it going to get harder and harder to get stable IPv4 addresses. ISP's are looking at moving their entire client base from having unshared public addresses to shared public addresses. What John and I have been trying to get across here is that there is no incentive to create an IPv6 only zone now and never will be in the future. You present an induction without a base case. Except IPv6 only zones already exist so there must be some incentive to have them. Back in the days when Internet on phones meant WAP, there was a possibility of them being supported on IPv6. But now the iPhone has changed the model and the Web on a phone will look just like the rest of the net and so they have to run IPv4. That is the big flaw in the IPv6 ready program. It assumes that the incentive for transition is that IPv6 is a good in itself. It is not, in fact IPv6 will be slower (more header baggage) than IPv4 and if you are IPv6 only you will have to go through gateways. And IPv4 will have multiple header re-writting. DPI to fix up the fact that headers have been re-written multiple times along with checksum re-calculations etc. I actually expect IPv6 to be faster in the end if only marginally. Most measurements to day say that IPv4 and IPv6 are roughly the same. We do seem to be making some progress. I have been banging on about this
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On Jun 15, 2010, at 5:57 AM, Phillip Hallam-Baker wrote: But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. So, things like implementing getaddrinfo() to replace gethostbyname() and as a result making the applications network layer agnostic. The kind of thing that not only helps with IPv6 deployment, but makes multi-homing work well for the IPv4-only application as well, makes solutions like pnat irrelevant, and all that. http://www.ietf.org/rfc/rfc2553.txt 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc3493.txt 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL) Supported in Windows, Mac/BSD, Linux, you name it. Been there a long time. Yes, all we need is application engineers with a network clue. They seem to be hard to come by. I have a solution. Let's go through those OS's and rename gethostbyname to GetHostByName. Put in huge comments everywhere that the character string is found (man pages, which btw already have this, and in the code itself) if you use this, you're an idiot. Make folks use their heads momentarily. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
Fred Baker wrote: I have a solution. Let's go through those OS's and rename gethostbyname to GetHostByName. Put in huge comments everywhere that the character string is found (man pages, which btw already have this, and in the code itself) if you use this, you're an idiot. Make folks use their heads momentarily. That's actually how a number of problems were fixed in the BSD libraries. gcc came along and it flagged some things - as errors - that weren't really incorrect but were bad practice (writing into constant strings, for example). Can't imagine anything like that happening today. We've gotten a vendor or two to implement v6 in their products by explaining that we've got a non-negotiable requirement for it and that we'd be unable to continue to license their stuff without it. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On Jun 15, 2010, at 5:57 AM, Phillip Hallam-Baker wrote: But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. So, things like implementing getaddrinfo() to replace gethostbyname() and as a result making the applications network layer agnostic. The kind of thing that not only helps with IPv6 deployment, but makes multi-homing work well for the IPv4-only application as well, makes solutions like pnat irrelevant, and all that. Right general idea, but wrong in the details. The API applications should be using is one of the connectbyname variants that avoids having to do any handling of raw addresses of any sort. PHB's suggestions are spot on here. Among other things, using a connectbyname API provides the abiltiy to easily implement support for SRV records. http://www.ietf.org/rfc/rfc2553.txt 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc3493.txt 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL) Supported in Windows, Mac/BSD, Linux, you name it. Been there a long time. But still too low level. And the fact that the addrinfo APIs are supported on a lot of platforms doesn't mean code written on top of them interoperates. Case in point. A few months back I was testing some code that uses the addrinfo interfaces on a new platform. getaddrinfo worked fine, but getnameinfo, not so much. After contacting the vendor, I was informed that the length field in the structure had to match the length field supplied in the parameter list exactly or the call would fail. The suggested fix was to put a switch statement in front of the call to fill in the lengths appropriately depending on the address family in use. That's not exactly futureproofing, is it? Yes, all we need is application engineers with a network clue. They seem to be hard to come by. And tHat's frankly insulting - the main problem isn't new code, which by and large is being written in languages that support proper connectbyname and getconnectinfo APIs that hide all this stuff completely. No, the problem is the vast amounts of old code written long before the addrinfo APIs existed. Switching all of this stuff over is NOT trivial. An especially pernicious problem is library code where the source is either unavailable or is available but you're not allowed to modify it for one reason or another. And since I'm not in the best of moods I'll also answer in kind by saying us application engineers might also be waiting for someone with half a clue as to how to design a proper standard API to come along and do that. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Models of change Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/15/2010 7:30 PM, Fred Baker wrote: Yes, all we need is application engineers with a network clue. They seem to be hard to come by. Every layer is clue-challenged, when it comes to staffing. Possibly at other times, too. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
The URI syntax you specify is only used for some protocols and most of the elements are defaulted. In fact we have got to the point where for Web browsing everything is defaulted except for the domain name. I think we need to break the idea that a Web service should have a URL that starts HTTP. Rather, if we are connecting to the Google mapping Web Service we would type in either google.com - if the type of service needed was obvious from the context ws:google.com:maps - for the fully qualified version Under the covers this would of course expand via SRV to a http URL, probably something of the form http://services1.google.com/ws/maps/1/0 http://services2.google.com/ws/maps/1/0 Since the SRV record is expanding to a domain name that we presume to be reserved for hosting of Web services we can take over the specification of the URI stem in the protocol. The real advantage of this approach is of course that we then have a layer that we can later use to lift ourselves off of using HTTP as a Web Services transport. If the web service offers SSL we can put a record in the DNS that says 'use SSL for this connection'. If there is a binary version we can have a hint to say that the binary version is available. And within this framework we can slip in a hint to the effect 'works best with IPv6' On Fri, Jun 11, 2010 at 4:09 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: I note in passing that this might have played out differently had we gotten SRV record support in place for all protocols a lot sooner. But without it for HTTP in particular you're faced with the need for multiple port 80s in a lot of cases. What I would like to see the IETF do is to produce a new architecture document that tells application and Web Service designers how they should be using the Internet. In my view DNS+SRV should become the only way that Web services are located (I do not think the extra capabilities of NAPTR are necessary or even useful for service discovery). Interesting. The problem of SRV is that it is *NOT* URL friendly that web people should have no idea on how to use it. While SRV is designed following the syntax of IP as: _Service._Proto.Name TTL Class SRV Priority Weight Port Target most applications know Service and Proto by number from the beginning that there is no room to convert them to ASCII strings. The only notable exception, of course, is when URLs are used. However, as the syntax of Internet URLs is: scheme://user:password@host:port/url-path applications have no information on the ASCII representation of Proto. So, SRV should be used as: _Scheme.Name TTL Class SRV Priority Weight Proto Port Target where Weight and Proto are 8 bit quantities to make the RR format compatible to todays. Then, if we recommend web people try SRV when Name is not resolved to addresses, they should be happy to use it. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
You completely missed the point of my post. HTTPS is just as bad as HTTP as a URL for a Web Service. HTTP is a low level protocol, the layering of the Web service on HTTP or SOAP over HTTP or whatever should be abstracted away in the Web Service URI. Just like we abstract away the fact we are using TCP/IP. Removing the clutter allows us to reclaim the URI for use by the Web Service. At the moment the URI that is submitted to the Web Server has a mixture of information relevant to the protocol and irrelevant details that have to do with the administration of the Web Service. Specifying irrelevant details in the URI makes operation of the service dependent on them being filled out. Which in turn means that they are difficult to change. We are creating an unnecessary management trap for ourselves. Not specifying those details and allowing them to be filled in using information from the DNS (SRV records, hints, etc) or defaults means that THOSE DEFAULTS CAN NOW BE CHANGED WITHOUT IMPACTING SERVICE. Take your example of using HTTPS. The notion of changing the URI stem to turn on security is a really bad design. It has left us with a Web where SSL is the Sunday best you put on for special occasions, not regular wear. (SSL upgrade could help but is vulnerable to downgrade attack). What you really want to have as the 'open socket' API is something like: OpenWebService (In String dns_name, In String service_prefix, In Enum minimum_trust, Out Socket socket) Where minimum_trust is NONE, DomainValidated, OrganizationValidated, ExtendedValidated) Just as the standard open call does a number of procedures under the covers, this API would be doing the SRV failover processing, working out if upgrade was possible, required, doing path math etc.) Now APIs are not part of IETF purview. But what is and should be is creating the conditions that make a highly generic API possible. The API above only works if the Web Service we want to use conforms to a particular standard calling mechanism. And that standard should come from either the IETF or W3C. The reason that an API is necessary and important is that while it is easy to implement that in C or C#, it is a heck of a lot of hassle to do the same in Perl or any of the scripting languages people want to use - relative to the rest of the code they are writing. On Sat, Jun 12, 2010 at 12:24 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: The URI syntax you specify is only used for some protocols and most of the elements are defaulted. In fact we have got to the point where for Web browsing everything is defaulted except for the domain name. The point was to change the default of 80. I think we need to break the idea that a Web service should have a URL that starts HTTP. Try https. Under the covers this would of course expand via SRV to a http URL, SRV answer gives port numbers and addresses, not a URL. Masataka Ohta -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
In message ikG3jf9YmyaauWK/lh7bqg@lochnagar.gulbrandsen.priv.no, Arnt Gul brandsen writes: Mark Andrews writes: Seriously, I do think it is time that the root and TLD's had IPv6 only name servers. Why (and do you mean all 6-only or one 6-only)? Because there are IPv6 only nameservers out there today. Not everyone can get a stable IPv4 address to run a nameserver on. I can't. I've got IPv6 only masters which have dual stack slaves. My IPv6 addresses are stable. My IPv4 addresses are not. And stable IPv4 address will become less available as ISP's introduce carrier grade NATs (NAT444 or DS-lite). While TLD's and the root are in positions where they are unlikely to ever *need* to run IPv6 only, having them run IPv6 only is a good thing as it show the world that this is a normal and expected situation. There is no negative side to running a IPv6 only nameserver. IPv4 only clients will ignore them. For IPv6 only and dual stack clients they are no better or worse than a dual stack server. Mark Arnt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
In message aanlktimoqnpmkcbitki07kag9xtroyiv84rqsmo0d...@mail.gmail.com, Phil lip Hallam-Baker writes: On Thu, Jun 10, 2010 at 11:04 PM, Mark Andrews ma...@isc.org wrote: I'm thinking 10, 15+ years out when there are lots of IPv6 only served zones. Much the same way we no longer worry about MTA's that don't know about MX records and no longer add A records to accomodate them. Why would there be any IPv6 only served zones? Because it going to get harder and harder to get stable IPv4 addresses. ISP's are looking at moving their entire client base from having unshared public addresses to shared public addresses. What John and I have been trying to get across here is that there is no incentive to create an IPv6 only zone now and never will be in the future. You present an induction without a base case. Except IPv6 only zones already exist so there must be some incentive to have them. Back in the days when Internet on phones meant WAP, there was a possibility of them being supported on IPv6. But now the iPhone has changed the model and the Web on a phone will look just like the rest of the net and so they have to run IPv4. That is the big flaw in the IPv6 ready program. It assumes that the incentive for transition is that IPv6 is a good in itself. It is not, in fact IPv6 will be slower (more header baggage) than IPv4 and if you are IPv6 only you will have to go through gateways. And IPv4 will have multiple header re-writting. DPI to fix up the fact that headers have been re-written multiple times along with checksum re-calculations etc. I actually expect IPv6 to be faster in the end if only marginally. Most measurements to day say that IPv4 and IPv6 are roughly the same. We do seem to be making some progress. I have been banging on about this problem for six years. When I started NAT was universally considered to be the problem. People are now seeing the NAT-PT approach as being a possible framework for a solution rather than something to be deprecated as 'historic' because they (wrongly) imagine true Internet is NAT-free. The more I look at NAT-PT (NAT64/DNS64) the less I like it. Way too many kludges especially when there is an alternative, DS-lite, which doesn't have nearly as many problems that need to be kludged around. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Mark Andrews writes: Seriously, I do think it is time that the root and TLD's had IPv6 only name servers. Why (and do you mean all 6-only or one 6-only)? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On Thu, Jun 10, 2010 at 8:17 PM, Mark Andrews ma...@isc.org wrote: In message 01no5qt3qgkc000...@mauve.mrochek.com, ned+i...@mauve.mrochek.com w rites: If this is accurate, I think you need to go back and reread John Klensin's recent messages for why this scenario really isn't all that likely to unfold the way you think. Ned Turn off the root servers IPv4 address and see how fast people adapt. :-) That is a great idea. I bet 90% of the net would have stopped using the IANA root servers within a week. Instead of 13 root server operators we would have maybe a hundred. People would certainly adapt, but not in the way you imagine they would adapt. You see the first law of the Internet is 'you are so not in charge (for all values of you). The control that IETF and ICANN impose is illusory. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On Thu, Jun 10, 2010 at 11:04 PM, Mark Andrews ma...@isc.org wrote: I'm thinking 10, 15+ years out when there are lots of IPv6 only served zones. Much the same way we no longer worry about MTA's that don't know about MX records and no longer add A records to accomodate them. Why would there be any IPv6 only served zones? What John and I have been trying to get across here is that there is no incentive to create an IPv6 only zone now and never will be in the future. You present an induction without a base case. Back in the days when Internet on phones meant WAP, there was a possibility of them being supported on IPv6. But now the iPhone has changed the model and the Web on a phone will look just like the rest of the net and so they have to run IPv4. That is the big flaw in the IPv6 ready program. It assumes that the incentive for transition is that IPv6 is a good in itself. It is not, in fact IPv6 will be slower (more header baggage) than IPv4 and if you are IPv6 only you will have to go through gateways. We do seem to be making some progress. I have been banging on about this problem for six years. When I started NAT was universally considered to be the problem. People are now seeing the NAT-PT approach as being a possible framework for a solution rather than something to be deprecated as 'historic' because they (wrongly) imagine true Internet is NAT-free. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Phillip Hallam-Baker wrote: I note in passing that this might have played out differently had we gotten SRV record support in place for all protocols a lot sooner. But without it for HTTP in particular you're faced with the need for multiple port 80s in a lot of cases. What I would like to see the IETF do is to produce a new architecture document that tells application and Web Service designers how they should be using the Internet. In my view DNS+SRV should become the only way that Web services are located (I do not think the extra capabilities of NAPTR are necessary or even useful for service discovery). Interesting. The problem of SRV is that it is *NOT* URL friendly that web people should have no idea on how to use it. While SRV is designed following the syntax of IP as: _Service._Proto.Name TTL Class SRV Priority Weight Port Target most applications know Service and Proto by number from the beginning that there is no room to convert them to ASCII strings. The only notable exception, of course, is when URLs are used. However, as the syntax of Internet URLs is: scheme://user:password@host:port/url-path applications have no information on the ASCII representation of Proto. So, SRV should be used as: _Scheme.Name TTL Class SRV Priority Weight Proto Port Target where Weight and Proto are 8 bit quantities to make the RR format compatible to todays. Then, if we recommend web people try SRV when Name is not resolved to addresses, they should be happy to use it. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Phillip Hallam-Baker wrote: The URI syntax you specify is only used for some protocols and most of the elements are defaulted. In fact we have got to the point where for Web browsing everything is defaulted except for the domain name. The point was to change the default of 80. I think we need to break the idea that a Web service should have a URL that starts HTTP. Try https. Under the covers this would of course expand via SRV to a http URL, SRV answer gives port numbers and addresses, not a URL. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
to check and see if this device supports multiple IPv4 addresses and 1:1 NAT. Unless I'm missing something, it does not. It does have NATPT, but that's not sufficient. I always cringe when I see such discussions hinging around what an Internet gateway box supports. The word supports is such a weasel word which makes minor imperfections that are easily fixed seem like major problems. What is supported is usually just the set of the features that the manufacturer wants to document and publish. Devices often have unsupported features that work fine so the question of whether or not a feature is supported has more to do with whether technically incompetent people will feel comfortable using it. Instead, I think it is better to look at what features *EXIST* for the platform and what subset of those features are IMPLEMENTED. Many Internet gateway boxes are based on an embedded Linux platform, so just about any IPv6 feature that you can imagine EXISTS and whether or not it is implemented is primarily down to the will of the manufacturer. There was a time when RAM capacity was also a limiting issue but I think that time has passed. Nowadays, if an Internet gateway lacks some feature that is widely implemented on Linux, then it is a minor imperfection that should be easy to fix if only people will COMMUNICATE DIRECTLY WITH THE MANUFACTURER, not through the press and Internet mailing lists. Yes, I am aware that not all Internet gateway boxes are based on Linux, but if that creates a barrier to implementing features like IPv6, then the marketplace can sort out that issue. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On Wed, Jun 9, 2010 at 8:57 PM, ned+i...@mauve.mrochek.com wrote: Sorry, this was in reference to an approach based on passed assumptions. The inflection point for when multiple IPv4 addresses at an access point becomes anachronistic will occur with an IPv6 connectivity imperative driven by the lack of IPv4 addresses. But things have to get to that point first. I for one am not especially sanguine about IPv4 address scarcity forcing sensible behavior soon enough. Especially given the major holes in IPv6 device support we've been discussing. Try 'desirable'. Sticking to IPv4 till the last minute and letting everyone else make the necessary investment to support the transition is the 'sensible' approach for most parties. The Internet has a billion users and it is now impossible to change it without putting a great deal of thought into the incentives for co-operation. I note in passing that this might have played out differently had we gotten SRV record support in place for all protocols a lot sooner. But without it for HTTP in particular you're faced with the need for multiple port 80s in a lot of cases. And the number of protocols is exploding due to Web Services. We now have far more than 64K protocols in use. The only reason we have not exhausted the ports is that in the modern Internet everything has to be layered on port 80 or 443. What I would like to see the IETF do is to produce a new architecture document that tells application and Web Service designers how they should be using the Internet. In my view DNS+SRV should become the only way that Web services are located (I do not think the extra capabilities of NAPTR are necessary or even useful for service discovery). At the moment we have the OpenID people who currently have five service discovery mechanisms, none of which use the DNS properly. And they are not the only group that is merrily creating entropy that is going to have to be serviced. We also have a similar issue with the use of XML, there the problem is that there are four different ways to achieve a certain aim and we spend a year arguing about which one to pick each time we start a working group. What I like about RFC822 style headers is not that they are the best way to move metadata but that they are used in the same way in every protocol. The inflection point for when multiple IPv4 addresses at an access point become anachronistic occurs with an IPv6 connectivity imperative. Yes, but the trick is getting things to that point. Perhaps the US will delay acceptance of this imperative, long after the rest of the world has embraced IPv6. After all, US, Liberia, and Burma have yet to adopt metric measures. :^) That may indeed be the case, but I must say Hardly a fair comparison for a lot of venues. It's always easier to deploy new infrastructure when there's relatively little old infrastructure that has to coexist or be replaced. Calling small business use of a small number of IPv4 addresses anachronistic doesn't change the fact that this is a widespread practice fully supported by an ample number of reasonable quality router products. And you're not going to get IPv6 deployed in such cases without a drop-in replacement that adds IPv6 support to what's already there. Clearly, with skill and non-commodity equipment, a configuration supporting multiple IPv4 addresses at an access point can be implemented in conjunction with IPv6. Of couse it can. But that's precisely the point - neither the skill nor the non-commodity equipment are available in most cases. And even when they are, a lot of people, like myself, run the costs versus benefits and IPv6 ends up losing. This could be practical when many within an organization are affected, but would not involve commodity low-end routers. Such configurations will remain rare due to IPv4 resource consumption, and greater support complexity. Fortunately, it remains easy to adopt the resource conservative IPv4 configurations supported by commodity routers when obtaining IPv6 connectivity. Why should the IETF advocate an increased IPv4 use that lacks benefit once a network has been configured? More strawmen. We're not talking about increased IPv4 use, but rather decent support for existing, long-deployed IPv4 use. If you seriously think you can get people to dump their existing setups in favor of somethign that is a major PITA to deal with and offers no immediate benefit, well, I have a couple of bridges available at fire sale prices. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/9/10 5:57 PM, Ned Freed wrote: I note in passing that this might have played out differently had we gotten SRV record support in place for all protocols a lot sooner. But without it for HTTP in particular you're faced with the need for multiple port 80s in a lot of cases. Disagree. HTTP is a bad example, since it allows canonical names to be replaced with a name offered by clients for supporting name based virtual hosts. In other words, a single port supports thousands of websites. :^) Clearly, with skill and non-commodity equipment, a configuration supporting multiple IPv4 addresses at an access point can be implemented in conjunction with IPv6. Of couse it can. But that's precisely the point - neither the skill nor the non-commodity equipment are available in most cases. And even when they are, a lot of people, like myself, run the costs versus benefits and IPv6 ends up losing. Agreed, but that changes once IPv6 becomes an imperative for these services, such as websites. At that point, its easier to scale a transitional solution when using fewer IPv4 addresses. As such, those few wishing to retain multiple IPv4 addresses lacking IPv6 connectivity are likely the last to adopt IPv6. Fortunately, it remains easy to adopt the resource conservative IPv4 configurations supported by commodity routers when obtaining IPv6 connectivity. Why should the IETF advocate an increased IPv4 use that lacks benefit once a network has been configured? More strawmen. We're not talking about increased IPv4 use, but rather decent support for existing, long-deployed IPv4 use. If you seriously think you can get people to dump their existing setups in favor of something that is a major PITA to deal with and offers no immediate benefit, well, I have a couple of bridges available at fire sale prices. I still have my English standard spanners, but they are seldom used. The impetus to change occurs after IPv6 becomes an imperative, such as doing business with a region dependent upon IPv6. After that, complaints related to NATs will fade, and support for IPv4 will be seen as the PITA. The inflection point for this may move faster than imagined. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/9/10 5:57 PM, Ned Freed wrote: I note in passing that this might have played out differently had we gotten SRV record support in place for all protocols a lot sooner. But without it for HTTP in particular you're faced with the need for multiple port 80s in a lot of cases. Disagree. HTTP is a bad example, since it allows canonical names to be replaced with a name offered by clients for supporting name based virtual hosts. In other words, a single port supports thousands of websites. :^) True but irrelevant. The issue isn't support for multiple web sites, it's support for multiple servers. Virtual hosts are fine as long as everything you've got runs under the same web server and on the same hardware. But in many cases things don't work this way. Let's see. I'm running at least seven different pieces of software right now that include a web server component. Now, not all of them provide public services, and for those it doesn't matter that they're not on port 80. But three of them do provide public services. Of course redirects and proxies provide a means of getting around these limitations. But now you're talking about a substantial increase in application and configuration complexity. Multiple IPs are a lot simpler and easier to manage. Clearly, with skill and non-commodity equipment, a configuration supporting multiple IPv4 addresses at an access point can be implemented in conjunction with IPv6. Of couse it can. But that's precisely the point - neither the skill nor the non-commodity equipment are available in most cases. And even when they are, a lot of people, like myself, run the costs versus benefits and IPv6 ends up losing. Agreed, but that changes once IPv6 becomes an imperative for these services, such as websites. At that point, its easier to scale a transitional solution when using fewer IPv4 addresses. As such, those few wishing to retain multiple IPv4 addresses lacking IPv6 connectivity are likely the last to adopt IPv6. With all due respect, I think you need to go read up on pareto optimality and it's implications for the transitions you claim are inevitable as IPv4 addresses become more scarce. Fortunately, it remains easy to adopt the resource conservative IPv4 configurations supported by commodity routers when obtaining IPv6 connectivity. Why should the IETF advocate an increased IPv4 use that lacks benefit once a network has been configured? More strawmen. We're not talking about increased IPv4 use, but rather decent support for existing, long-deployed IPv4 use. If you seriously think you can get people to dump their existing setups in favor of something that is a major PITA to deal with and offers no immediate benefit, well, I have a couple of bridges available at fire sale prices. I still have my English standard spanners, but they are seldom used. Major analogy fail. Again, your assertion was that what I'm after involves increased IPv4 use. This is simply false. The impetus to change occurs after IPv6 becomes an imperative, such as doing business with a region dependent upon IPv6. After that, complaints related to NATs will fade, and support for IPv4 will be seen as the PITA. The inflection point for this may move faster than imagined. In other words, the way you see this unfolding is that once there's a significant IPv6-connected base somewhere, probably in some emerging market, somebody will view it as practical to deploy services that can only be reached by IPv6. As more and more of this happens, it will create a need for everyone to have IPv6 connectivity, which will then lead to more IPv6-only services, and so on. If this is accurate, I think you need to go back and reread John Klensin's recent messages for why this scenario really isn't all that likely to unfold the way you think. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
In message 01no5qt3qgkc000...@mauve.mrochek.com, ned+i...@mauve.mrochek.com w rites: If this is accurate, I think you need to go back and reread John Klensin's recent messages for why this scenario really isn't all that likely to unfold the way you think. Ned Turn off the root servers IPv4 address and see how fast people adapt. :-) Seriously, I do think it is time that the root and TLD's had IPv6 only name servers. I'm not advocating IPv4 be turned off on them yet. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
--On Friday, June 11, 2010 10:17 +1000 Mark Andrews ma...@isc.org wrote: In message 01no5qt3qgkc000...@mauve.mrochek.com, ned+i...@mauve.mrochek.com w rites: If this is accurate, I think you need to go back and reread John Klensin's recent messages for why this scenario really isn't all that likely to unfold the way you think. Ned Turn off the root servers IPv4 address and see how fast people adapt. :-) Mark, I hate to say this, but that is silly, smiley or not. Because this may be an example of some of the force a transition ideas that are going around, let's examine what would happen if it were done. This analysis more or less applies to any cut off some service to force folks onto IPv6 strategy and is hence worth examining even if we understand that cutting off the IPv4 root servers is not realistic. The typical users of the Internet don't use the root servers directly at all. They use, exclusively, some full-service forwarder(s) that might interact with the root servers. Those forwarders belong to ISPs, enterprises, etc., and the lusers think they have contracts for services with those entities. So, now, some major piece of infrastructure that, from the user's perspective is a critical resource covered by the service is converted to IPv6-only or otherwise made unavailable. What happens next is pretty obvious: the provider copes or sees happy paying customers swap themselves out and their lawyers in. Using the root servers as an example, provider copes would most naturally take one of two forms: (1) Provider sets up an IPv6 server that is capable of serving out the root zone (from a cache and and queries as needed) to the forwarders who keep serving the users with IPv4 DNS. Net effect on IPv6 deployment: just about zero. Net effect on the DNS: very low or zero. (2) Provider adjusts the local configuration file for the location of the root zone to point to someone who will serve out a root zone in IPv4. Note a root zone rather than the root zone. I hope I don't have to explain the difference to anyone reading this list, but I'm sure I don't have to explain it to you. Net effect on IPv6 deployment: zero or worse because even more credibility will have been lost (for IPv6 and the intelligence of various institutions). Net effect on the DNS: significant and really bad... multiple roots or dubious (or at least variable) authority. DNSSec basically has to be turned off to make that work. In addition for both scenarios, we have some experience with such things for other reasons and in an earlier era. If the infrastructure that supports those alternate roots or shadow roots isn't as good as the infrastructure which they have come to expect from the normal root servers, the ISPs and other operators of major forwarders have tremendous incentives to refresh at lower frequency than called for in SOA records and to disable or reinterpret TTL timeouts of data. For the root zone, that was pretty much ok around 1995 because data volatility was very low. But, in a world in which ICANN is contemplating thousands of separate delegations from the root zone, volatility goes up and basing responses on slow-update alternate roots or non-authoritative and potentially very stale data... well, you don't cause a lot more IPv6 deployment, but you certainly damage the quality of DNS-based identifiers. Again, I saw the smiley so assume that you know the above. But the point is that there are similar scenarios, with similar outcomes, for almost every model for creating a forcing function for IPv6 based on artificially shutting down IPv4 services. Seriously, I do think it is time that the root and TLD's had IPv6 only name servers. I'm not advocating IPv4 be turned off on them yet. If yet points to any time prior to the point at which IPv6 is universally deployed, then the above comments apply to the DNS and root servers. It may be useful to remind ourselves again that getting TCP/IPv4 universally deployed in an NCP-based network required a flag day and a credible threat to disconnect any host that was still running NCP at the point. Neither the flag day nor the threat has plausible analogies in today's Internet. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/10/10 3:12 PM, Ned Freed wrote: On 6/10/10 2:48 PM Douglas Otis wrote: Disagree. HTTP is a bad example, since it allows canonical names to be replaced with a name offered by clients for supporting name based virtual hosts. In other words, a single port supports thousands of websites. :^) True but irrelevant. The issue isn't support for multiple web sites, it's support for multiple servers. Virtual hosts are fine as long as everything you've got runs under the same web server and on the same hardware. But in many cases things don't work this way. Let's see. I'm running at least seven different pieces of software right now that include a web server component. Now, not all of them provide public services, and for those it doesn't matter that they're not on port 80. But three of them do provide public services. Of course redirects and proxies provide a means of getting around these limitations. But now you're talking about a substantial increase in application and configuration complexity. Multiple IPs are a lot simpler and easier to manage. A Pareto complaint scenario does not require every possible configuration be accommodated, when it also accommodates existing configurations. Only a small percentage of customers receive multiple IPv4 addresses from their provider. Of those, only a few run incompatible services on different systems. While those who participate within the IETF likely represent an exceptional population, it seems unlikely special accommodations for minor portions of a market is necessary before progress is possible. Those who wish to retain their current configurations can do so, forgoing IPv6 connectivity. For them, this becomes a question of what overcomes their current equilibrium (their PITA factor). Indirectly this is being answered when large providers internally route Internet services using IPv6 when lacking adequate IPv4 address space. From a security standpoint, direct routing to a device reduces complexity and operational issues. Whether a device is an LP tank sensor in the backyard, a power meter on the side of the house, or a heat pump in the basement, direct routing offers enhanced functionality and security for those who opt-in. Currently, low-end routers are commonly 0wned and are untrustworthy, and often lack adequate logs, assuming these logs could be trusted. Direct routes allow packets to arrive unaltered, where only its source is being trusted. The impetus to change occurs after IPv6 becomes an imperative, such as doing business with a region dependent upon IPv6. After that, complaints related to NATs will fade, and support for IPv4 will be seen as the PITA. The inflection point for this may move faster than imagined. In other words, the way you see this unfolding is that once there's a significant IPv6-connected base somewhere, probably in some emerging market, somebody will view it as practical to deploy services that can only be reached by IPv6. As more and more of this happens, it will create a need for everyone to have IPv6 connectivity, which will then lead to more IPv6-only services, and so on. If this is accurate, I think you need to go back and reread John Klensin's recent messages for why this scenario really isn't all that likely to unfold the way you think. Region might mean a market segment or a geographic area, whether the impetus results from a lack of IPv4 address space, a lack of IP security, or a lack of functionality. Do you have a reference to one of John's messages? Over the years, this economic reference has been raised. Adding complexity to commodity devices for a minor portion of a market makes little sense. Higher-end routers offer a solution, but this means considering available alternatives when price does not seem justified. I don't see any strategy being proposed to force those not wishing to participate. For years I have had access to multiple static IP addresses, but never used more than one, nor would the services you seem to describe meet most residential AUPs. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
In message 55562cf3cfc08c5c6da3d...@pst.jck.com, John C Klensin writes: --On Friday, June 11, 2010 10:17 +1000 Mark Andrews ma...@isc.org wrote: In message 01no5qt3qgkc000...@mauve.mrochek.com, ned+i...@mauve.mrochek.com w rites: If this is accurate, I think you need to go back and reread John Klensin's recent messages for why this scenario really isn't all that likely to unfold the way you think. Ned Turn off the root servers IPv4 address and see how fast people adapt. :-) Mark, I hate to say this, but that is silly, smiley or not. Because this may be an example of some of the force a transition ideas that are going around, let's examine what would happen if it were done. This analysis more or less applies to any cut off some service to force folks onto IPv6 strategy and is hence worth examining even if we understand that cutting off the IPv4 root servers is not realistic. The typical users of the Internet don't use the root servers directly at all. They use, exclusively, some full-service forwarder(s) that might interact with the root servers. Those forwarders belong to ISPs, enterprises, etc., and the lusers think they have contracts for services with those entities. So, now, some major piece of infrastructure that, from the user's perspective is a critical resource covered by the service is converted to IPv6-only or otherwise made unavailable. What happens next is pretty obvious: the provider copes or sees happy paying customers swap themselves out and their lawyers in. Using the root servers as an example, provider copes would most naturally take one of two forms: (1) Provider sets up an IPv6 server that is capable of serving out the root zone (from a cache and and queries as needed) to the forwarders who keep serving the users with IPv4 DNS. Net effect on IPv6 deployment: just about zero. Net effect on the DNS: very low or zero. (2) Provider adjusts the local configuration file for the location of the root zone to point to someone who will serve out a root zone in IPv4. Note a root zone rather than the root zone. I hope I don't have to explain the difference to anyone reading this list, but I'm sure I don't have to explain it to you. Net effect on IPv6 deployment: zero or worse because even more credibility will have been lost (for IPv6 and the intelligence of various institutions). Net effect on the DNS: significant and really bad... multiple roots or dubious (or at least variable) authority. DNSSec basically has to be turned off to make that work. The provider only needs access to a dual stack name server. I don't know about other vendors but named can run IPv4 only or IPv6 only and still access zones served only by servers using the the other flavour of IP and has been able to do so for nearly a decade provided it has access to a dual stack server somewhere on the internet which will answer its queries. In addition for both scenarios, we have some experience with such things for other reasons and in an earlier era. If the infrastructure that supports those alternate roots or shadow roots isn't as good as the infrastructure which they have come to expect from the normal root servers, the ISPs and other operators of major forwarders have tremendous incentives to refresh at lower frequency than called for in SOA records and to disable or reinterpret TTL timeouts of data. For the root zone, that was pretty much ok around 1995 because data volatility was very low. But, in a world in which ICANN is contemplating thousands of separate delegations from the root zone, volatility goes up and basing responses on slow-update alternate roots or non-authoritative and potentially very stale data... well, you don't cause a lot more IPv6 deployment, but you certainly damage the quality of DNS-based identifiers. I said adapt, I didn't necessarially mean adapt well or the way we would want them to adapt. Again, I saw the smiley so assume that you know the above. But the point is that there are similar scenarios, with similar outcomes, for almost every model for creating a forcing function for IPv6 based on artificially shutting down IPv4 services. Seriously, I do think it is time that the root and TLD's had IPv6 only name servers. I'm not advocating IPv4 be turned off on them yet. If yet points to any time prior to the point at which IPv6 is universally deployed, then the above comments apply to the DNS and root servers. I'm thinking 10, 15+ years out when there are lots of IPv6 only served zones. Much the same way we no longer worry about MTA's that don't know about MX records and no longer add A records to accomodate them. It may be useful to remind ourselves again that getting TCP/IPv4 universally deployed in an NCP-based network required a flag day and a credible threat to disconnect any host that
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/7/10 12:49 PM, John C Klensin wrote: My belief is that we have a serious IPv6 marketing and transition problem until and unless we can get a level of functionality for IPv6 (and, really, for IPv4/IPv6 mixtures of the sorts that Ned's notes imply) at a level of investment roughly equivalent to the costs we are now paying for IPv4 alone. I want to stress that level of investment and terms like expensive are measured in requirements for knowledge, maintenance, configuration fussing, etc., not just hardware. They also include some important issues about support costs on the vendor/ISP side: if an ISP sells a business IPv6 service with certain properties and customers get into trouble, that ISP is itself in trouble if the support requests require third-level or engineering/design staff involvement to understand or resolve. When the hardware costs we are talking about are in the same range as one month's connectivity bills (and all the numbers you and Ned mentioned are, at least for me), they just wash out and disappear compared to aggravation, fussing, and other sysadmin costs. IMHO, it would be a mistake to expect low end routers targeting home and small office environments to eventually include features for handling multiple IPv4 addresses in conjunction with an IPv4 to IPv6 transition strategy, largely for the reasons you give. When multiple providers are involved, some choices are available for multiple IPv4 addresses where devices terminating a provider's network are connected through a vlan switch with trunking. Or terminated with a selection of mid-range routers ~$400/$50 new/used price range, such as cisco 871 or 2600. Instead of expecting a company's support to deal with with involved configurations, solutions are increasingly met by co-location services, or VPS where the providers offer network/power redundancy, dual stack rout-ability, and support expertise. An automatic 6to4 tunnel for an isolated IPv6 network, routes on a per-packet basis to a border router in another IPv6 network over IPv4 infrastructure. Tunnel destinations are determined by the IPv4 address of the border router extracted from the IPv6 address starting with the prefix 2002::/16 having the format 2002:/border-router-IPv4-address/::/48, which likely makes this a function of the ISP. When IPv6 is available, each device becomes accessible with unique IP addresses. A conservative approach for scarce IPv4 addresses is to associate dedicated servers/services with specific ports of a single global address, a feature supported by nearly all commodity routers. Whenever accessing IPv6 networks over the Internet becomes imperative, ISPs will suggest boilerplate solutions. However, it seems unlikely these will include anachronistic use of IPv4 addresses. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/7/10 12:49 PM, John C Klensin wrote: My belief is that we have a serious IPv6 marketing and transition problem until and unless we can get a level of functionality for IPv6 (and, really, for IPv4/IPv6 mixtures of the sorts that Ned's notes imply) at a level of investment roughly equivalent to the costs we are now paying for IPv4 alone. I want to stress that level of investment and terms like expensive are measured in requirements for knowledge, maintenance, configuration fussing, etc., not just hardware. They also include some important issues about support costs on the vendor/ISP side: if an ISP sells a business IPv6 service with certain properties and customers get into trouble, that ISP is itself in trouble if the support requests require third-level or engineering/design staff involvement to understand or resolve. When the hardware costs we are talking about are in the same range as one month's connectivity bills (and all the numbers you and Ned mentioned are, at least for me), they just wash out and disappear compared to aggravation, fussing, and other sysadmin costs. IMHO, it would be a mistake to expect low end routers targeting home and small office environments to eventually include features for handling multiple IPv4 addresses Except that there is no eventually here. This class of device already supports multiple IPv4 addresses and 1:1 NAT, for the simple reason that a lot of such setups depend on having such support. This has been true for many years. The problem with this class of device isn't the lack of support for multiple IPv4 addresses, it's the lack of support for IPv6. in conjunction with an IPv4 to IPv6 transition strategy, largely for the reasons you give. When multiple providers are involved, Again with the multiple providers strawman. Nobody is talking about multiple providers and failover and so on here. This truly is a different level of service. some choices are available for multiple IPv4 addresses where devices terminating a provider's network are connected through a vlan switch with trunking. Or terminated with a selection of mid-range routers ~$400/$50 new/used price range, such as cisco 871 or 2600. Instead of expecting a company's support to deal with with involved configurations, solutions are increasingly met by co-location services, or VPS where the providers offer network/power redundancy, dual stack rout-ability, and support expertise. All of which fals FAR outside the range of service this discussion is about. An automatic 6to4 tunnel for an isolated IPv6 network, routes on a per-packet basis to a border router in another IPv6 network over IPv4 infrastructure. Tunnel destinations are determined by the IPv4 address of the border router extracted from the IPv6 address starting with the prefix 2002::/16 having the format 2002:/border-router-IPv4-address/::/48, which likely makes this a function of the ISP. When IPv6 is available, each device becomes accessible with unique IP addresses. A conservative approach for scarce IPv4 addresses is to associate dedicated servers/services with specific ports of a single global address, a feature supported by nearly all commodity routers. Whenever accessing IPv6 networks over the Internet becomes imperative, ISPs will suggest boilerplate solutions. However, it seems unlikely these will include anachronistic use of IPv4 addresses. And so, having no other argument to make, we resort to pejoratives? Calling small business use of a small number of IPv4 addresses anachronistic doesn't change the fact that this is a widespread practice fully supported by an ample number of reasonable quality router products. And you're not going to get IPv6 deployed in such cases without a drop-in replacement that adds IPv6 support to what's already there. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 06/09/2010 01:19 PM, ned+i...@mauve.mrochek.com wrote: And so, having no other argument to make, we resort to pejoratives? Calling small business use of a small number of IPv4 addresses anachronistic doesn't change the fact that this is a widespread practice fully supported by an ample number of reasonable quality router products. And you're not going to get IPv6 deployed in such cases without a drop-in replacement that adds IPv6 support to what's already there. this is cute ned but your assertion that this device can't route for a interior public prefix was just plain wrong. perhaps you should actually get one and try it? Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/9/10 1:19 PM, Ned Freed wrote: When IPv6 is available, each device becomes accessible with unique IP addresses. A conservative approach for scarce IPv4 addresses is to associate dedicated servers/services with specific ports of a single global address, a feature supported by nearly all commodity routers. Whenever accessing IPv6 networks over the Internet becomes imperative, ISPs will suggest boilerplate solutions. However, it seems unlikely these will include anachronistic use of IPv4 addresses. And so, having no other argument to make, we resort to pejoratives? Sorry, this was in reference to an approach based on passed assumptions. The inflection point for when multiple IPv4 addresses at an access point becomes anachronistic will occur with an IPv6 connectivity imperative driven by the lack of IPv4 addresses. In most small office/home office (SOHO) cases, a single IPv4 address is both sufficient and well supported for use with IPv4 and IPv6 remote networks. Additional IPv4 global addresses for an access point will likely involve recurring costs due to complexity and dependence upon this scarce resource. The inflection point for when multiple IPv4 addresses at an access point become anachronistic occurs with an IPv6 connectivity imperative. Perhaps the US will delay acceptance of this imperative, long after the rest of the world has embraced IPv6. After all, US, Liberia, and Burma have yet to adopt metric measures. :^) Calling small business use of a small number of IPv4 addresses anachronistic doesn't change the fact that this is a widespread practice fully supported by an ample number of reasonable quality router products. And you're not going to get IPv6 deployed in such cases without a drop-in replacement that adds IPv6 support to what's already there. Clearly, with skill and non-commodity equipment, a configuration supporting multiple IPv4 addresses at an access point can be implemented in conjunction with IPv6. This could be practical when many within an organization are affected, but would not involve commodity low-end routers. Such configurations will remain rare due to IPv4 resource consumption, and greater support complexity. Fortunately, it remains easy to adopt the resource conservative IPv4 configurations supported by commodity routers when obtaining IPv6 connectivity. Why should the IETF advocate an increased IPv4 use that lacks benefit once a network has been configured? -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 06/09/2010 01:19 PM, ned+i...@mauve.mrochek.com wrote: And so, having no other argument to make, we resort to pejoratives? Calling small business use of a small number of IPv4 addresses anachronistic doesn't change the fact that this is a widespread practice fully supported by an ample number of reasonable quality router products. And you're not going to get IPv6 deployed in such cases without a drop-in replacement that adds IPv6 support to what's already there. this is cute ned but your assertion that this device can't route for a interior public prefix was just plain wrong. That statement may be wrong, but since (a) I never said any such thing and (b) AFAICT this is completely disjoint from the issue of supportt for multiple IPv4 addresses and similar IPv4 facilities, I fail to see the relevance. perhaps you should actually get one and try it? I don't have to. D-Link has this cute web-based emulator that lets you try out their stuff without having to buy it. I used this emulator, available at http://www.support.dlink.com/emulators/dir825_revB/202NA/login.html to check and see if this device supports multiple IPv4 addresses and 1:1 NAT. Unless I'm missing something, it does not. It does have NATPT, but that's not sufficient. Feel free to prove me wrong by pointing me at the pages where the support for multiple IPv4 addresses lives and related firewall capabilities lives. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/9/10 1:19 PM, Ned Freed wrote: When IPv6 is available, each device becomes accessible with unique IP addresses. A conservative approach for scarce IPv4 addresses is to associate dedicated servers/services with specific ports of a single global address, a feature supported by nearly all commodity routers. Whenever accessing IPv6 networks over the Internet becomes imperative, ISPs will suggest boilerplate solutions. However, it seems unlikely these will include anachronistic use of IPv4 addresses. And so, having no other argument to make, we resort to pejoratives? Sorry, this was in reference to an approach based on passed assumptions. The inflection point for when multiple IPv4 addresses at an access point becomes anachronistic will occur with an IPv6 connectivity imperative driven by the lack of IPv4 addresses. But things have to get to that point first. I for one am not especially sanguine about IPv4 address scarcity forcing sensible behavior soon enough. Especially given the major holes in IPv6 device support we've been discussing. In most small office/home office (SOHO) cases, a single IPv4 address is both sufficient and well supported for use with IPv4 and IPv6 remote networks. First of all, I disagree with this assessment, and cite as evidence the widespread availability of support for mutiple addresses in SOHO-class firewalls and related equipment. Again, why is this feature present in so many SOHO-class router/firewalls and has been present for the past 10 years at least if nobody out there uses it? Additional IPv4 global addresses for an access point will likely involve recurring costs due to complexity and dependence upon this scarce resource. True. But the current recurring costs are far less than the effective costs of all the gyrations you have to go through with proxies and whatnot when you try and make it all work with NATPT. I note in passing that this might have played out differently had we gotten SRV record support in place for all protocols a lot sooner. But without it for HTTP in particular you're faced with the need for multiple port 80s in a lot of cases. The inflection point for when multiple IPv4 addresses at an access point become anachronistic occurs with an IPv6 connectivity imperative. Yes, but the trick is getting things to that point. Perhaps the US will delay acceptance of this imperative, long after the rest of the world has embraced IPv6. After all, US, Liberia, and Burma have yet to adopt metric measures. :^) That may indeed be the case, but I must say Hardly a fair comparison for a lot of venues. It's always easier to deploy new infrastructure when there's relatively little old infrastructure that has to coexist or be replaced. Calling small business use of a small number of IPv4 addresses anachronistic doesn't change the fact that this is a widespread practice fully supported by an ample number of reasonable quality router products. And you're not going to get IPv6 deployed in such cases without a drop-in replacement that adds IPv6 support to what's already there. Clearly, with skill and non-commodity equipment, a configuration supporting multiple IPv4 addresses at an access point can be implemented in conjunction with IPv6. Of couse it can. But that's precisely the point - neither the skill nor the non-commodity equipment are available in most cases. And even when they are, a lot of people, like myself, run the costs versus benefits and IPv6 ends up losing. This could be practical when many within an organization are affected, but would not involve commodity low-end routers. Such configurations will remain rare due to IPv4 resource consumption, and greater support complexity. Fortunately, it remains easy to adopt the resource conservative IPv4 configurations supported by commodity routers when obtaining IPv6 connectivity. Why should the IETF advocate an increased IPv4 use that lacks benefit once a network has been configured? More strawmen. We're not talking about increased IPv4 use, but rather decent support for existing, long-deployed IPv4 use. If you seriously think you can get people to dump their existing setups in favor of somethign that is a major PITA to deal with and offers no immediate benefit, well, I have a couple of bridges available at fire sale prices. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Sounds like you'll need to be looking up market, you're not really looking for a soho router at the point where you've got multiple external providers. This device and it's ilk represted the ipv6 functionality availble in a circa mid to late 2009 home router with a retail price of $100-$150. They are pretty good devices. If you're comparing them to a sonic wall tz you're not really comparing the same class of device. by your own admission the later is inadequate so I'm not sure why you'd even bring it up. joel On 06/06/2010 11:39 AM, Ned Freed wrote: Alternate email client usage fail. My apologies. Ned (offlist) On 2010-06-02 07:36, Phillip Hallam-Baker wrote: On Tue, Jun 1, 2010 at 1:19 PM, Ned Freedned.fr...@mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned That is my conclusion as well. D-link Dir 825 http://www.dlink.com/products/?pid=DIR-825 real firewall knobs, ipv6 in the gui etc... It think all their high-end home router small business devices are getting features as they get replaced. I have one deployed, screenshot is here: http://www.flickr.com/photos/joelja/4663980030/ This box may have adequate IPv6 support. (Or it may not - several people have raised issues with it's capabilities. Personally, I lack sufficient operational experience with IPv6 to know one way or the other.) But it's severely deficient in terms of IPv4/NAT/firewall capabilities. In particular, while it has decent NATPT support, there is no indication it cannot handle multiple WAN-side IPv4 addresses and/or 1:1 NAT. The firewall is, according to several reviews I've seen, inadequate on the IPV6 side. This puts it in the same category as the Apple Airport line and the Linksys RVS4000 - probably adequate for personal home use. But in no way, shape or form adequate for SOHO use. I was very clear I was talking about the latter, not the former. now would people please stop on this subject, the manufacturers know how to build this stuff. I'm waiting for an existence proof of the truth of this statement. So far I haven't seen one. The closest I've seen so far is the Sonicwall TZ line, but while it's very capable on the IPv4/NAT/firewall side of things, it's IPv6 support appears inadequate - no 6to4, no IPv6 firewall capabilities, etc. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Alternate email client usage fail. My apologies. Ned (offlist) On 2010-06-02 07:36, Phillip Hallam-Baker wrote: On Tue, Jun 1, 2010 at 1:19 PM, Ned Freedned.fr...@mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned That is my conclusion as well. D-link Dir 825 http://www.dlink.com/products/?pid=DIR-825 real firewall knobs, ipv6 in the gui etc... It think all their high-end home router small business devices are getting features as they get replaced. I have one deployed, screenshot is here: http://www.flickr.com/photos/joelja/4663980030/ This box may have adequate IPv6 support. (Or it may not - several people have raised issues with it's capabilities. Personally, I lack sufficient operational experience with IPv6 to know one way or the other.) But it's severely deficient in terms of IPv4/NAT/firewall capabilities. In particular, while it has decent NATPT support, there is no indication it cannot handle multiple WAN-side IPv4 addresses and/or 1:1 NAT. The firewall is, according to several reviews I've seen, inadequate on the IPV6 side. This puts it in the same category as the Apple Airport line and the Linksys RVS4000 - probably adequate for personal home use. But in no way, shape or form adequate for SOHO use. I was very clear I was talking about the latter, not the former. now would people please stop on this subject, the manufacturers know how to build this stuff. I'm waiting for an existence proof of the truth of this statement. So far I haven't seen one. The closest I've seen so far is the Sonicwall TZ line, but while it's very capable on the IPv4/NAT/firewall side of things, it's IPv6 support appears inadequate - no 6to4, no IPv6 firewall capabilities, etc. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
(offlist) On 2010-06-02 07:36, Phillip Hallam-Baker wrote: On Tue, Jun 1, 2010 at 1:19 PM, Ned Freedned.fr...@mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned That is my conclusion as well. D-link Dir 825 http://www.dlink.com/products/?pid=DIR-825 real firewall knobs, ipv6 in the gui etc... It think all their high-end home router small business devices are getting features as they get replaced. I have one deployed, screenshot is here: http://www.flickr.com/photos/joelja/4663980030/ This box may have adequate IPv6 support. (Or it may not - several people have raised issues with it's capabilities. Personally, I lack sufficient operational experience with IPv6 to know one way or the other.) But it's severely deficient in terms of IPv4/NAT/firewall capabilities. In particular, while it has decent NATPT support, there is no indication it cannot handle multiple WAN-side IPv4 addresses and/or 1:1 NAT. The firewall is, according to several reviews I've seen, inadequate on the IPV6 side. This puts it in the same category as the Apple Airport line and the Linksys RVS4000 - probably adequate for personal home use. But in no way, shape or form adequate for SOHO use. I was very clear I was talking about the latter, not the former. now would people please stop on this subject, the manufacturers know how to build this stuff. I'm waiting for an existence proof of the truth of this statement. So far I haven't seen one. The closest I've seen so far is the Sonicwall TZ line, but while it's very capable on the IPv4/NAT/firewall side of things, it's IPv6 support appears inadequate - no 6to4, no IPv6 firewall capabilities, etc. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Sounds like you'll need to be looking up market, you're not really looking for a soho router at the point where you've got multiple external providers. Who said anything about multiple external providers? All I'm talking about is support for a small number of static IPs on a single network interface. Like you'd need to run, say, a couple of small scale servers. This is NOT high end in any way, shape, or form. This device and it's ilk represted the ipv6 functionality availble in a circa mid to late 2009 home router with a retail price of $100-$150. They are pretty good devices. In your opinion, perhaps. But 10 years ago I bought a Sonicwall SOHO router with all of the capabilities - except IPv6 support - I'm talking about here. I think it cost around $250. Is it really too much to ask that, 10 years later, for a comparable device with decent IPv6 support added? If you're comparing them to a sonic wall tz you're not really comparing the same class of device. by your own admission the later is inadequate so I'm not sure why you'd even bring it up. The Sonicwall TZ 100 is available for $289. The D-link unit you are fond of lists for around $160, the Airport Extreme for around $179, the Linksys RVS4000 is the cheapie in the group at around $110. Nevertheless, these are hardly in vastly different price classes. But let's assume, for the moment, that they are - that the extra $100-$200 is a really big deal. So what? My point stands - you have yet to identify anything - even an upscale box - that meets my stated criteria where must be dirt cheap was conspicuous by its absence. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
--On Sunday, June 06, 2010 14:39 -0700 Joel Jaeggli joe...@bogus.com wrote: Sounds like you'll need to be looking up market, you're not really looking for a soho router at the point where you've got multiple external providers. This device and it's ilk represted the ipv6 functionality availble in a circa mid to late 2009 home router with a retail price of $100-$150. They are pretty good devices. If you're comparing them to a sonic wall tz you're not really comparing the same class of device. by your own admission the later is inadequate so I'm not sure why you'd even bring it up. Joel, Ned has already responded to part of this and I won't repeat, but let me respond to your last comment from my perspective (I assume a similar network with a few servers... but I do have two external providers). Because of the servers, both Ned and I are clearly in the SOHO world, not the client only residential one, as my ISPs remind me by having me write checks every month for business service and multiple static addresses that total around an order of magnitude more than my neighbors are paying for equivalent bandwidth. But, while limited in size and scope, they are (or at least mine) are real networks, not a VPN parasite on an enterprise network somewhere that does the _real_ routing, etc. Devices like the Linksys RV082 and, with a feature set that is a little larger in some areas and smaller in others, the SonicWall TZ and its predecessors, _do_ provide adequate support for networks of that type when they are running IPv4-only. Foe example, the RV082, perhaps because the designers couldn't figure out how to do better in a box of that size and complexity, provides for multiple public external addresses pnly via 1:1 NAT and the SonicWall (at least the earlier one I have) actually understands about public addresses. FWIW, I've got some fairly serious (enterprise class or above, not SOHO class), if old, router iron lying around here. But, even if the vendor were providing good quality IPv6 software and support for it (they aren't), the amount of effort needed to set it up for this type of network would probably be too expensive (which is most of why it got retired years ago). My belief is that we have a serious IPv6 marketing and transition problem until and unless we can get a level of functionality for IPv6 (and, really, for IPv4/IPv6 mixtures of the sorts that Ned's notes imply) at a level of investment roughly equivalent to the costs we are now paying for IPv4 alone. I want to stress that level of investment and terms like expensive are measured in requirements for knowledge, maintenance, configuration fussing, etc., not just hardware. They also include some important issues about support costs on the vendor/ISP side: if an ISP sells a business IPv6 service with certain properties and customers get into trouble, that ISP is itself in trouble if the support requests require third-level or engineering/design staff involvement to understand or resolve. When the hardware costs we are talking about are in the same range as one month's connectivity bills (and all the numbers you and Ned mentioned are, at least for me), they just wash out and disappear compared to aggravation, fussing, and other sysadmin costs. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 2010-05-30 18:49, Phillip Hallam-Baker wrote: So we need to extend the UPNP protocol so that when the local NAT box receives a request to open up an external port, it relays the request to the carrier NAT. That's like msdp multicast state, who is going to allow you to instantiate it in their box? Automated port binding requests depend on the availbility of ports and port numbers are a fairly scarce resource in huge nat boxes. IGD in the context normal upnp device had at least two of not more properties that simply don't fly in the move from a residential gateway to a many gig per second cg nat box. enumeration of exsting port bindings (that would be comical to consider) and an assumption that the device requesting the port is well behaved when the device for example requests 500 other ports you give it those too... Or we could do what we did last time and pretend that nobody will deploy carrier grade NAT if we don't specify a way that it can work without pain. On Sun, May 30, 2010 at 11:02 AM, Arnt Gulbrandsen a...@gulbrandsen.priv.no wrote: On 05/30/2010 04:44 PM, Sabahattin Gucukoglu wrote: BitTorrent is popular, yes. People at home *are* behind NAT boxes, with all the usual pain that implies *. It's just that BitTorrent, being a straightforward TCP protocol with no embedded payload addresses **, can operate behind NATs, and those NATs can be configured either manually or automatically by users or their client software ***. If the NAT should move to the ISP, it seems possible that this is no longer true. Not quite. 1. Bittorrent clients connect to each other via TCP. Each connection is incoming at one end. Torrent clients mostly use UPNP to accept incoming connections. 2. UPNP is an ethernet-level protocol (it uses UDP/IP broadcasts), so it works only if the USER is on the public internet. Hence, NAT within the user's network is now very different from NAT within the ISP's network. That's why I said the wide popularity of bittorrent shows that USERS are on the public internet. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Martin, What about the IPv6 capabilities and configurability of devices that are much more difficult to configure or update and much more expensive to replace? - Game consoles used for online gaming (XBox,PSP,WII)? - Internet-capable Flatscreen-TVs - Set-Top boxes (e.g. feature-enhanced DVB-C of DVB-S Receivers) - SOHO Network attached storage (NAS) - other internet enabled home appliances (e.g. refrigerator) You could view these as not problems -- they are good reasons to keep your network in dual stack for quite some time. (But some game consoles do get frequent firmware updates from the network, as some people with PS3s have found out. So do set-top boxes. And AFAICT a common application of Internet in the DVD player/TV space is firmware upgrades from the network -- how else would my Blue Ray player play the latest Java-enhanced disks? I'll postulate that a good fraction home entertainment equipment either can upgrade itself or has a very short lifetime anyway.) Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The point is to change it: Was: IPv4 depletion makes CNN
Nice to hear just worked in the context of IPv6. Did your router give you just an IPv6 address, or also an IPv4 address? If both, does the IPv6 address ever get anywhere on the Internet, or is it always NATted? -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Wednesday, June 02, 2010 1:22 AM To: ietf@ietf.org Subject: Re: The point is to change it: Was: IPv4 depletion makes CNN On 6/1/10 9:57 AM, Olivier MJ Crepin-Leblond wrote: On 30/05/2010 23:52, Phillip Hallam-Baker wrote : People are not going to use IPv6 if it takes the slightest effort on their part. People are not going to switch their home networks over to IPv6 if it means a single device on the network is going to stop working. In my case it would cost me $4K to upgrade my 48 plotter to an IPv6 capable system. No way is that going to happen till there are $50 IPv6 plotters on EBay. Sorry, but that's a red herring. You're speaking about IPv4 decommissioning, not IPv6 implementation. Implementing IPv6 will do nothing to your local plotter. Your computer will keep addressing IPv4 to it. Nothing stops you from always running dual stack at home, with your IPv4 behind your NAT/PAT. Have you tried implementing IPv6 at home? By accident when solving a network drop-out problem within a congested wireless environment, installing an airport extreme router also offered IPv6 over an IPv4 ISP. Everything just worked. When later changing providers, the cable modem needed extensive tweaking before everything worked, which then lowered throughput by about 35%. To overcome this, several commodity routers were tried, but they were unable run DHCP once the modem's NAT was disabled. Double NATs cause additional breakage. Once again, the airport extreme just worked. This was learning the hard way it seems. Unless one is careful, one might find themselves using IPv6 without their knowledge, both globally and locally. Capturing local traffic showed several applications already making use of the local IPv6 address space. And I'd even wager that an IPv4 plotter would work, since an HP IPv4 printer does. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scanned by Check Point Total Security Gateway. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/2/10 12:39 AM, Yoav Nir wrote: Nice to hear just worked in the context of IPv6. Did your router give you just an IPv6 address, or also an IPv4 address? If both, does the IPv6 address ever get anywhere on the Internet, or is it always NATted? The router appears to use RFC3056, with the external IP address in the range for 6to4 that was noticed when visiting APNIC.NET. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 2010-06-02 07:36, Phillip Hallam-Baker wrote: On Tue, Jun 1, 2010 at 1:19 PM, Ned Freedned.fr...@mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned That is my conclusion as well. D-link Dir 825 http://www.dlink.com/products/?pid=DIR-825 real firewall knobs, ipv6 in the gui etc... It think all their high-end home router small business devices are getting features as they get replaced. I have one deployed, screenshot is here: http://www.flickr.com/photos/joelja/4663980030/ now would people please stop on this subject, the manufacturers know how to build this stuff. But the basic principle for me is that I have to put no effort into this changeover at all as a network admin. Its got to be no more than a replacement of one gateway box with another. Expecting more is futile as the power users are not going to be early adopters for single stack IPv6. We are the ones who are going to want IPv4 connectivity the longest. The target market for IPv6 has to be the less demanding users for whom a full IPv6 connection and a NAT-ed IPv4 are going to serve perfectly well. I am not going to tell any of my friends or family to move to IPv6 unless it is absolutely guaranteed to be painless. Otherwise I am going to be the one doing long distance tech support. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On May 30, 2010, at 3:52 PM, Phillip Hallam-Baker wrote: 1) Branding Every technology company that has wanted to establish an infrastructure to support their product has used branding as leverage. Remember 'Novell Ready', 'Entrust Ready', 'Windows Vista Ready'? We need an Internet Next Ready. And when consumers see that brand they need to know that what they are getting is going to work with the next generation Internet. Demanding 'Internet Next Ready' in new products, in Internet service is the ask. http://www.ipv6ready.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
In message 4c06a72c.20...@bogus.com, joel jaeggli writes: On 2010-06-02 07:36, Phillip Hallam-Baker wrote: On Tue, Jun 1, 2010 at 1:19 PM, Ned Freedned.fr...@mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned That is my conclusion as well. D-link Dir 825 http://www.dlink.com/products/?pid=DIR-825 real firewall knobs, ipv6 in the gui etc... It think all their high-end home router small business devices are getting features as they get replaced. I have one deployed, screenshot is here: http://www.flickr.com/photos/joelja/4663980030/ now would people please stop on this subject, the manufacturers know how to build this stuff. The only reference to IPv6 is IPv6 Gold Does that mean that it does PD? I don't know and I'm not about to wade through the 135 page test spec for DHCPv6 to find out. Does it do DHCPv6 client / server. But the basic principle for me is that I have to put no effort into this changeover at all as a network admin. Its got to be no more than a replacement of one gateway box with another. Expecting more is futile as the power users are not going to be early adopters for single stack IPv6. We are the ones who are going to want IPv4 connectivity the longest. The target market for IPv6 has to be the less demanding users for whom a full IPv6 connection and a NAT-ed IPv4 are going to serve perfectly well. I am not going to tell any of my friends or family to move to IPv6 unless it is absolutely guaranteed to be painless. Otherwise I am going to be the one doing long distance tech support. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 2010-06-02 15:44, Mark Andrews wrote: now would people please stop on this subject, the manufacturers know how to build this stuff. The only reference to IPv6 is IPv6 Gold Does that mean that it does PD? It does not. I don't know and I'm not about to wade through the 135 page test spec for DHCPv6 to find out. Does it do DHCPv6 client / server. It has both dhcpv6 client and server. it makes the assumuption that if you want to assign v6 nameservers that you'll do so with stateful dhcpv6. the product is closing in on a year old so I imagine the product managers fixed the feature set in stone rather a long while ago. But the basic principle for me is that I have to put no effort into this changeover at all as a network admin. Its got to be no more than a replacement of one gateway box with another. Expecting more is futile as the power users are not going to be early adopters for single stack IPv6. We are the ones who are going to want IPv4 connectivity the longest. The target market for IPv6 has to be the less demanding users for whom a full IPv6 connection and a NAT-ed IPv4 are going to serve perfectly well. I am not going to tell any of my friends or family to move to IPv6 unless it is absolutely guaranteed to be painless. Otherwise I am going to be the one doing long distance tech support. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
ned+i...@mauve.mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. While I believe that many many millions of SOHO-grade routers out there are not capable of that and will remain so for easily 5 more years, they're are fairly easy to replace. Change your ISP (after two years) and you'll get a new router almost free from you new ISP, at least here in Germany. And they've made configuring these Routers realy easy for non-techies! Some ISP are down to a 12 alphanum code that makes the router download its entire configuration from the ISP. What about the IPv6 capabilities and configurability of devices that are much more difficult to configure or update and much more expensive to replace? - Game consoles used for online gaming (XBox,PSP,WII)? - Internet-capable Flatscreen-TVs - Set-Top boxes (e.g. feature-enhanced DVB-C of DVB-S Receivers) - SOHO Network attached storage (NAS) - other internet enabled home appliances (e.g. refrigerator) -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 2010-06-02 16:09, Martin Rex wrote: What about the IPv6 capabilities and configurability of devices that are much more difficult to configure or update and much more expensive to replace? - Game consoles used for online gaming (XBox,PSP,WII)? - Internet-capable Flatscreen-TVs - Set-Top boxes (e.g. feature-enhanced DVB-C of DVB-S Receivers) - SOHO Network attached storage (NAS) - other internet enabled home appliances (e.g. refrigerator) Let's face it, your Internet Fridge while not OSI compliant unlike your Decnet Phase IV fridge, is a bad idea that will be consigned to history, it will still keep beer cold. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
In message 4c06e306.3050...@bogus.com, joel jaeggli writes: On 2010-06-02 15:44, Mark Andrews wrote: now would people please stop on this subject, the manufacturers know how to build this stuff. The only reference to IPv6 is IPv6 Gold Does that mean that it does PD? It does not. I don't know and I'm not about to wade through the 135 page test spec for DHCPv6 to find out. Does it do DHCPv6 client / server. It has both dhcpv6 client and server. it makes the assumuption that if you want to assign v6 nameservers that you'll do so with stateful dhcpv6. the product is closing in on a year old so I imagine the product managers fixed the feature set in stone rather a long while ago. So you think I should expect support for a option that was specified in 2003 in products that first shipped in 2009? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 2010-06-02 16:40, Mark Andrews wrote: It has both dhcpv6 client and server. it makes the assumuption that if you want to assign v6 nameservers that you'll do so with stateful dhcpv6. the product is closing in on a year old so I imagine the product managers fixed the feature set in stone rather a long while ago. So you think I should expect support for a option that was specified in 2003 in products that first shipped in 2009? RFC 1884 was December 1995 and we're still bitching and moaning about it... QED. Mark ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv4 depletion makes CNN
You articulated the view from my knothole. Thanks! -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, May 28, 2010 1:29 AM To: David Conrad Cc: IETF Discussion Subject: Re: IPv4 depletion makes CNN snip No, it means it is going to require double NAT unless providers deploy IPv6. That is the message that needs to be got across. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The point is to change it: Was: IPv4 depletion makes CNN
We keep coming back to the same old problem and the same reasons we are going to hope it solves itself without having to change anything. 1) Its the wrong type of pain IPv4 exhaustion does cause problems, but not really enough problems or immediate enough problems to create an incentive to move away from the IPv4 Internet. It really does not matter very much to the typical Internet user if there are other people unable to join the party. It matters even less to them if those people are in far away countries. 2) NAT-NAT IPv4 still beats IPv6 Even with the restrictions of carrier NAT, most Internet users are going to prefer an Internet connection that gives access to the millions of IPv4 hosts than the hundreds of IPv6 hosts. This is an adoption trap. Nobody is going to move to IPv6 unless the functionality is superior to IPv4. Saying that IPv6 is X years behind is to miss the point. 3) There is no ask ISOC and others are very good at putting out these stories warning about the imminent IPv4 exhaustion. But this is wasted effort when the message reaches people who can do nothing in response. For a message to be effective, there has to be an ask, there has to be something concrete that the audience can do in response. As before I will suggest how I would address the issue: 1) Branding Every technology company that has wanted to establish an infrastructure to support their product has used branding as leverage. Remember 'Novell Ready', 'Entrust Ready', 'Windows Vista Ready'? We need an Internet Next Ready. And when consumers see that brand they need to know that what they are getting is going to work with the next generation Internet. Demanding 'Internet Next Ready' in new products, in Internet service is the ask. 2) Design for deployment People are not going to use IPv6 if it takes the slightest effort on their part. People are not going to switch their home networks over to IPv6 if it means a single device on the network is going to stop working. In my case it would cost me $4K to upgrade my 48 plotter to an IPv6 capable system. No way is that going to happen till there are $50 IPv6 plotters on EBay. I try to do as little management of my home network as possible. For the architecture to be acceptable it has to be totally transparent to me. Otherwise carrier grade NAT is going to be preferable as at least that is going to work. 3) Create incentives Even with branding, the incentives have to make sense. Merely having access to the IPv6 Internet available is not going to cause people to use it. Pretty much every host on the Internet can use IPSEC at this point. The portion that use it is ~ 0%. The way that I plot out a campaign is to list every stakeholder that I need to take action. I consider the positive/negative balance sheet from their point of view. I look at the incentive they have to take action and how they are to get the message that they need to take action. Now I can draft out an architecture that would have the necessary properties quite easily. And so could many others on this list. But that would be a mistake. In order to get buy in from all the people whose buy in is needed, they have to be involved at the design stage. Having the had the opportunity to be involved is not the same thing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
So we need to extend the UPNP protocol so that when the local NAT box receives a request to open up an external port, it relays the request to the carrier NAT. Or we could do what we did last time and pretend that nobody will deploy carrier grade NAT if we don't specify a way that it can work without pain. On Sun, May 30, 2010 at 11:02 AM, Arnt Gulbrandsen a...@gulbrandsen.priv.no wrote: On 05/30/2010 04:44 PM, Sabahattin Gucukoglu wrote: BitTorrent is popular, yes. People at home *are* behind NAT boxes, with all the usual pain that implies *. It's just that BitTorrent, being a straightforward TCP protocol with no embedded payload addresses **, can operate behind NATs, and those NATs can be configured either manually or automatically by users or their client software ***. If the NAT should move to the ISP, it seems possible that this is no longer true. Not quite. 1. Bittorrent clients connect to each other via TCP. Each connection is incoming at one end. Torrent clients mostly use UPNP to accept incoming connections. 2. UPNP is an ethernet-level protocol (it uses UDP/IP broadcasts), so it works only if the USER is on the public internet. Hence, NAT within the user's network is now very different from NAT within the ISP's network. That's why I said the wide popularity of bittorrent shows that USERS are on the public internet. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On Mon, May 31, 2010 at 3:02 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: paf wrote: It all works pretty well if the client have IPv4 and IPv6 _AND_ both works. But to some degree the functionality and user experience goes down if either of IPv4 or IPv6 have problems. Same is true for a host with two IPv4 addresses and either of the IPv4 addresses have problems. Same is true for a host with two IPv6 addresses and either of the IPv6 addresses have problems. The problem can be solved by carefully designing connection establishment protocols to support multiple addresses of a host, which means no solution exists at the connectionless layer of IP. Modified TCP, which send multiple SYN to several addresses of a peer helps a lot to reduce timeout. I am pretty sure we can fix the problem if we are prepared to adapt the stack somewhat. The alternative is to do nothing and let various people hack the stack up completely with meat axes and then we will be working round the consequences for decades. But really, the challenge is that carrier grade NAT works just fine for the ISPs who have the decision making power here. Whatever happens, 4 billion IPv4 addresses is probably more than enough for the people who really, really care about having an IPv4 address. The punters want to be on the Web, do video conferencing and maybe do some SMTP email. Thats not much of a demand to work with. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
It is a feature that should be part of the Internet base protocol stack. It is bad enough having to work out which RFCs matter and which should be ignored. Knowing that you have to search out to various other organizations to find secret sauce to make it work is a recipe for chaos. Its bad enough having kludges like the robots.txt file in HTTP. On Mon, May 31, 2010 at 7:59 AM, Arnt Gulbrandsen a...@gulbrandsen.priv.no wrote: On 05/31/2010 03:49 AM, Phillip Hallam-Baker wrote: So we need to extend the UPNP protocol so that when the local NAT box receives a request to open up an external port, it relays the request to the carrier NAT. So what are you waiting for? Go ahead, read http://upnp.org, find the relevant WG, propose the extension, talk to implementers, you know the routine as well as I do. Arnt -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 30/05/2010 23:52, Phillip Hallam-Baker wrote : People are not going to use IPv6 if it takes the slightest effort on their part. People are not going to switch their home networks over to IPv6 if it means a single device on the network is going to stop working. In my case it would cost me $4K to upgrade my 48 plotter to an IPv6 capable system. No way is that going to happen till there are $50 IPv6 plotters on EBay. Sorry, but that's a red herring. You're speaking about IPv4 decommissioning, not IPv6 implementation. Implementing IPv6 will do nothing to your local plotter.Your computer will keep addressing IPv4 to it. Nothing stops you from always running dual stack at home, with your IPv4 behind your NAT/PAT. Have you tried implementing IPv6 at home? Kind regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 5/30/2010 3:52 PM, Phillip Hallam-Baker wrote: We keep coming back to the same old problem and the same reasons we are going to hope it solves itself without having to change anything. 1) Its the wrong type of pain IPv4 exhaustion does cause problems, but not really enough problems or immediate enough problems to create an incentive to move away from the IPv4 Internet. AMEN, and ARIN could recover any number of multiply issued /8's to corporate entities who acquired blocks by merger, like HP for instance. The have TANDEM's DEC's Compaq's and HP's /8's and do they need anywhere near that many IPv4 addresses? NO... So the issue is ARIN and its sloppy operating policies - and yes Cathy (their attorney) has heard this from me already. It really does not matter very much to the typical Internet user if there are other people unable to join the party. It matters even less to them if those people are in far away countries. Duh... the only people who need a fully flat-routed world are the Standards Practitioners. 2) NAT-NAT IPv4 still beats IPv6 Even with the restrictions of carrier NAT, most Internet users are going to prefer an Internet connection that gives access to the millions of IPv4 hosts than the hundreds of IPv6 hosts. Yep This is an adoption trap. Nobody is going to move to IPv6 unless the functionality is superior to IPv4. Saying that IPv6 is X years behind is to miss the point. 3) There is no ask ISOC and others are very good at putting out these stories warning about the imminent IPv4 exhaustion. But this is wasted effort when the message reaches people who can do nothing in response. For a message to be effective, there has to be an ask, there has to be something concrete that the audience can do in response. As before I will suggest how I would address the issue: 1) Branding Every technology company that has wanted to establish an infrastructure to support their product has used branding as leverage. Remember 'Novell Ready', 'Entrust Ready', 'Windows Vista Ready'? We need an Internet Next Ready. And when consumers see that brand they need to know that what they are getting is going to work with the next generation Internet. Demanding 'Internet Next Ready' in new products, in Internet service is the ask. yes but this then is a marketing effort to convince people (the end users) that they need this new gizmo more than the old gizmo and not a technological one. 2) Design for deployment People are not going to use IPv6 if it takes the slightest effort on their part. Yep... People are not going to switch their home networks over to IPv6 if it means a single device on the network is going to stop working. In my case it would cost me $4K to upgrade my 48 plotter to an IPv6 capable system. No way is that going to happen till there are $50 IPv6 plotters on EBay. I try to do as little management of my home network as possible. For the architecture to be acceptable it has to be totally transparent to me. Otherwise carrier grade NAT is going to be preferable as at least that is going to work. Yep, meaning that NAT and not IPv6 is the solution. 3) Create incentives Even with branding, the incentives have to make sense. Merely having access to the IPv6 Internet available is not going to cause people to use it. Pretty much every host on the Internet can use IPSEC at this point. The portion that use it is ~ 0%. This speaks all that needs to be said here, so unless there is some real reason that the Internet is going to break unless IPv6 is rolled out there is no reason to do it. Again - IPv4 and NAT are a very reasonable solution as it network segmentation. The way that I plot out a campaign is to list every stakeholder that I need to take action. I consider the positive/negative balance sheet from their point of view. I look at the incentive they have to take action and how they are to get the message that they need to take action. Now I can draft out an architecture that would have the necessary properties quite easily. And so could many others on this list. But that would be a mistake. In order to get buy in from all the people whose buy in is needed, they have to be involved at the design stage. Having the had the opportunity to be involved is not the same thing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf attachment: tglassey.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 30/05/2010 23:52, Phillip Hallam-Baker wrote : People are not going to use IPv6 if it takes the slightest effort on their part. People are not going to switch their home networks over to IPv6 if it means a single device on the network is going to stop working. In my case it would cost me $4K to upgrade my 48 plotter to an IPv6 capable system. No way is that going to happen till there are $50 IPv6 plotters on EBay. Sorry, but that's a red herring. No, not really. Unless you're willing to fully upgrade to IPv6, you're talking about continuing to use NAT for the legacy IPv4 devices. And that buys you into substantial complexity in terms of routing and configuration. You're speaking about IPv4 decommissioning, not IPv6 implementation. Implementing IPv6 will do nothing to your local plotter.Your computer will keep addressing IPv4 to it. Nothing stops you from always running dual stack at home, with your IPv4 behind your NAT/PAT. Have you tried implementing IPv6 at home? As a matter of fact I have. It was a total disaster and after spending several days trying to get it to work I gave up. The specific problems I had were with DNS queries being blocked for mysterious reasons and hairpin routing configuration problems, but the simple fact that such esoteric issues had to be dealt with by a home network admin sort of says it all. As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 31 May 2010, at 02:49, Phillip Hallam-Baker wrote: Or we could do what we did last time and pretend that nobody will deploy carrier grade NAT if we don't specify a way that it can work without pain. Well, I'd be interested to know what your plan is. Do you think we should use DNS for everything, SRV to specify the location of every service, and make port numbers insignificant? Do you think this is better than IPv6, or that it will take any more time to deploy IPv6? And, what do you think of the NAT scaling problem that you are proposing we mutely suffer in perpetuity? I don't like IPv4+NAT for sure (my favourite has got to be A+P) however I really don't see anything but good coming of (A) not delaying IPv6 deployment any further and (B) making every arrangement to avoid NAT in future. This seems to work for everybody except the end-users, for whom this whole thing is completely insignificant, who drag the market with them into a state of complacency. They don't care. Therefore, I think we must elongate IPv4's life as much as possible, so as to give the unfortunate time to transition, but no more. Then, content providers and end-users can continue enjoying the 'net (albeit more slowly than usual due to all that translation load for all the usual purposes) while the faster and more capable Internet gradually transitions into use. This is the best we can do given that the dual-stack opportunity passed over a decade ago, and even then it was important enough to commence work on what was, and I think is, the obvious (if a little imperfect) plan for the future. That's where we stand today, everybody capable of IPv6, and nobody connected, while the red alert signs all begin to flash. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 1 Jun 2010, at 18:19, ned+i...@mauve.mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. I agree. With the exception (g) of a non-configurable packet filter (besides the NAT function and per-port-based IPv6), Apple's Airport Extreme and Time Capsule do IPv6 very nearly out of the box (it was disabled by default because a load of Security researchers took issue with exposing computers to the IPv6 Internet by default). In about ten clicks, and assuming your Internet connection is provided by ethernet to a global IPv4 address, these base stations will set up and advertise a 6to4 routed block for your network, and handle transparent v4/v6 DNS from one proxy. They're supposed to be able to handle custom tunnels, but bugs prevent it from working; it also works as a native router, a host on an existing v6 network, and link-local for configuration (no more slipping/forgotten netmasks). So all in all, I'm quite pleased with them, and they're the reason I decided IPv6 was no longer hard for anybody. No doubt there are others out there, or should be (IE, from ISPs) and of course there's Teredo or custom protocols if you want to stay behind an existing legacy NAT. And of course, if you want to, you can build your own with a Linux box, though I agree that sort of misses the deployability aspect, and is more toward the enthusiast, though that's how my original setup went for my DSL provider. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 6/1/10 9:57 AM, Olivier MJ Crepin-Leblond wrote: On 30/05/2010 23:52, Phillip Hallam-Baker wrote : People are not going to use IPv6 if it takes the slightest effort on their part. People are not going to switch their home networks over to IPv6 if it means a single device on the network is going to stop working. In my case it would cost me $4K to upgrade my 48 plotter to an IPv6 capable system. No way is that going to happen till there are $50 IPv6 plotters on EBay. Sorry, but that's a red herring. You're speaking about IPv4 decommissioning, not IPv6 implementation. Implementing IPv6 will do nothing to your local plotter. Your computer will keep addressing IPv4 to it. Nothing stops you from always running dual stack at home, with your IPv4 behind your NAT/PAT. Have you tried implementing IPv6 at home? By accident when solving a network drop-out problem within a congested wireless environment, installing an airport extreme router also offered IPv6 over an IPv4 ISP. Everything just worked. When later changing providers, the cable modem needed extensive tweaking before everything worked, which then lowered throughput by about 35%. To overcome this, several commodity routers were tried, but they were unable run DHCP once the modem's NAT was disabled. Double NATs cause additional breakage. Once again, the airport extreme just worked. This was learning the hard way it seems. Unless one is careful, one might find themselves using IPv6 without their knowledge, both globally and locally. Capturing local traffic showed several applications already making use of the local IPv6 address space. And I'd even wager that an IPv4 plotter would work, since an HP IPv4 printer does. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
In message aanlktilmjpietg4hybcb_pik9chxtsjekhn0r3vo2...@mail.gmail.com, Phil lip Hallam-Baker writes: We keep coming back to the same old problem and the same reasons we are going to hope it solves itself without having to change anything. 1) Its the wrong type of pain IPv4 exhaustion does cause problems, but not really enough problems or immediate enough problems to create an incentive to move away from the IPv4 Internet. It really does not matter very much to the typical Internet user if there are other people unable to join the party. It matters even less to them if those people are in far away countries. 2) NAT-NAT IPv4 still beats IPv6 But we are not talking NAT-NAT IPv4 vs IPv6. We are talking NAT-NAT/Distributed NAT IPv4 with plain IPv6. Even with the restrictions of carrier NAT, most Internet users are going to prefer an Internet connection that gives access to the millions of IPv4 hosts than the hundreds of IPv6 hosts. If you present it to them that way then they would agree with you. If you present it to them as NAT-NAT along or NAT-NAT plus IPv6 you will get a different answer especially when IPv6 is not more complicated than IPv4 is today. This is an adoption trap. Nobody is going to move to IPv6 unless the functionality is superior to IPv4. Saying that IPv6 is X years behind is to miss the point. 3) There is no ask ISOC and others are very good at putting out these stories warning about the imminent IPv4 exhaustion. But this is wasted effort when the message reaches people who can do nothing in response. For a message to be effective, there has to be an ask, there has to be something concrete that the audience can do in response. As before I will suggest how I would address the issue: 1) Branding Every technology company that has wanted to establish an infrastructure to support their product has used branding as leverage. Remember 'Novell Ready', 'Entrust Ready', 'Windows Vista Ready'? We need an Internet Next Ready. And when consumers see that brand they need to know that what they are getting is going to work with the next generation Internet. Demanding 'Internet Next Ready' in new products, in Internet service is the ask. Most of the equipment they already have is IPv6 ready. It's the home router that isn't. 2) Design for deployment People are not going to use IPv6 if it takes the slightest effort on their part. People are not going to switch their home networks over to IPv6 if it means a single device on the network is going to stop working. In my case it would cost me $4K to upgrade my 48 plotter to an IPv6 capable system. No way is that going to happen till there are $50 IPv6 plotters on EBay. Turning on IPv6 does not mean that you have to turn off IPv4. You can continue to use IPv4 until you no longer need to use it. I try to do as little management of my home network as possible. For the architecture to be acceptable it has to be totally transparent to me. Otherwise carrier grade NAT is going to be preferable as at least that is going to work. Except for the additional things that it breaks. 3) Create incentives Even with branding, the incentives have to make sense. Merely having access to the IPv6 Internet available is not going to cause people to use it. Pretty much every host on the Internet can use IPSEC at this point. The portion that use it is ~ 0%. Actually it is well above zero and lots of people are using it without being aware that they are using it. If you turn on IPv6 on your servers you will get traffic. The way that I plot out a campaign is to list every stakeholder that I need to take action. I consider the positive/negative balance sheet from their point of view. I look at the incentive they have to take action and how they are to get the message that they need to take action. Now I can draft out an architecture that would have the necessary properties quite easily. And so could many others on this list. But that would be a mistake. In order to get buy in from all the people whose buy in is needed, they have to be involved at the design stage. Having the had the opportunity to be involved is not the same thing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
In message eef83942-7b6d-4169-a7e2-f51306182...@cisco.com, =?iso-8859-1?Q?Pat rik_F=E4ltstr=F6m?= writes: On 31 maj 2010, at 03.39, Mark Andrews wrote: And have any of those that say this tried: 1) tried dual stack 2) tried IPv6 only through NAT64 (NAT-PT) with a sample of customers or are they just talking without any reference points. I am spending lots of my time trying to get some _real_data_, but I do not have it yet. I am though running dual stack with native IPv4 and native IPv6 in my home office, on all my servers, and have quite some experience on dual stack. And that was not as fun as I expected. I.e. my data is based on dual stack be worse than I expected, and having people asking me would native IPv6 only be better, or what about native IPv6 with NAT64/DNS64. And I have also read various papers people in IETF have written on how to handle the quite normal case with SMTP where MX records are in use (which have been far from complete), and then maybe IP6 or IPv4, and IPv6 or IPv4 for DNS transport, and quite often search paths in DNS as well... The number of DNS lookups needed explode exponentially, you get timeouts on application layer, applications show timeout boxes as if the mail server is not responding when in reality multiple seconds are used for DNS lookups. MTAs should never search. MX records are absolute (explict or implicit). MSAs should only search to qualify unqualified domains in user submitted data. Just curious. What percentage addresses in your address book are not fully qualified. I know I gave up on unqualified address back in the early '90s. Also are all the search element served locally or do you need to do a remote lookup for them? And it shouldn't be exponential growth. Double maybe. It is messy with dual stack. Messier than what I think many people think. Including me (and I thought I had quite good overview of how it worked). Runing dual stack internally without external IPv4 connectivity is just as bad as running dual stack internally without external IPv6 connectivity. You just don't want to go down that path. I claim it is worse than having IPv6 only. Yes. I've tried to run IPv6 only. Real IPv6 only, IPv4 completely disabled in the OS. It wasn't fun. So have I. For example at the IETF in Anaheim one morning when IPv4 connectivity was broken. For me it worked better than dual stack, when accessing things that was reachable over IPv6. But that was with my OS (MacOSX) that have relatively good IPv6 support. And problems with its resolver trying to be too smart. :-) So there are good things and bad things with both dual stack and IPv6 only. And no, we do not have any data, but we do not have good documents on how to run dual stack either. Patrik -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 31 maj 2010, at 08.03, Mark Andrews wrote: MTAs should never search. MX records are absolute (explict or implicit). Agree. MSAs should only search to qualify unqualified domains in user submitted data. I agree with this as well. These are just two details that have not been clear in some drafty-draft documents I have seen on SMTP and IPv6. Just curious. What percentage addresses in your address book are not fully qualified. I know I gave up on unqualified address back in the early '90s. Also are all the search element served locally or do you need to do a remote lookup for them? I really think we should get rid of the search path in resolvers. And it shouldn't be exponential growth. Double maybe. If you have search path, and then choice of IPv4 and IPv6 transport for DNS, and then A and to look up for the MTA you connect to, that at least multiplies the number of choices. The best is double. Then in some cases it is worse. It all works pretty well if the client have IPv4 and IPv6 _AND_ both works. But to some degree the functionality and user experience goes down if either of IPv4 or IPv6 have problems. Anyway, the biggest problem is still, as you say, that we do not really know... For me it worked better than dual stack, when accessing things that was reachable over IPv6. But that was with my OS (MacOSX) that have relatively good IPv6 support. And problems with its resolver trying to be too smart. :-) You bet! Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
In message 6e881f81-991d-4e98-932c-65cb49b02...@cisco.com, =?iso-8859-1?Q?Pat rik_F=E4ltstr=F6m?= writes: On 31 maj 2010, at 08.03, Mark Andrews wrote: MTAs should never search. MX records are absolute (explict or implicit). Agree. MSAs should only search to qualify unqualified domains in user submitted data. I agree with this as well. These are just two details that have not been clear in some drafty-draft = documents I have seen on SMTP and IPv6. Just curious. What percentage addresses in your address book are not fully qualified. I know I gave up on unqualified address back in the early '90s. Also are all the search element served locally or do you need to do a remote lookup for them? I really think we should get rid of the search path in resolvers. And it shouldn't be exponential growth. Double maybe. If you have search path, and then choice of IPv4 and IPv6 transport for = DNS, and then A and to look up for the MTA you connect to, that at = least multiplies the number of choices. The best is double. Then in some cases it is worse. You have qualification searchs. MX (1 + search), A (1 + search), (1 + search) Delivery (A + ) * MX targets (implict or explict). If it's more than that then the MTA is broken and is a security incident waiting to happen. It all works pretty well if the client have IPv4 and IPv6 _AND_ both works. But to some degree the functionality and user experience goes down if either of IPv4 or IPv6 have problems. SMTP is store and forward. Your MSA should just accept and queue. The actual delivery should be done in the background or do you have debugging turned on where you are trying to see the delivery step? Anyway, the biggest problem is still, as you say, that we do not really = know... For me it worked better than dual stack, when accessing things that = was reachable over IPv6. But that was with my OS (MacOSX) that have relatively good IPv6 support. And problems with its resolver trying to be too smart. :-) You bet! Patrik -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Sabahattin Gucukoglu wrote: Right, yes, I didn't see it from that standpoint. However UPnP can of course be substituted by NAT-PMP/PCP or something else that doesn't have the same discovery problem, and ISP-level NATs will no longer be a Problem for clients needing incoming connections even though they can no longer be said to be Public. Right. For example, an ISP, today, can tell its client public IP addresses assigned to the client. Then, the client can configure them by hand. There is no discovery problem. Just like that, an ISP can tell its client a public IP address and public port numbers of the address assigned to the client. Then, the client can configure them by hand. Or, it is trivially easy to add DHCP/PP option so that ISPs can automatically tell their clients the address/port information for each client. If port allocation is more dynamic involving gateway-client communication, there should be a DHCP/PPP option to tell client the IP address (and port) of a gateway for the gateway-client communication. Of course we're assuming that clients are in direct contact with their gateway here, I'm not sure how true that is, there may need to be added proxying to replicate requests otherwise. It certainly isn't impossible to do. Sure. What is necessary is clear documentation of DHCP/PPP extensions and gateway-client protocols. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
paf wrote: It all works pretty well if the client have IPv4 and IPv6 _AND_ both works. But to some degree the functionality and user experience goes down if either of IPv4 or IPv6 have problems. Same is true for a host with two IPv4 addresses and either of the IPv4 addresses have problems. Same is true for a host with two IPv6 addresses and either of the IPv6 addresses have problems. The problem can be solved by carefully designing connection establishment protocols to support multiple addresses of a host, which means no solution exists at the connectionless layer of IP. Modified TCP, which send multiple SYN to several addresses of a peer helps a lot to reduce timeout. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 05/31/2010 03:49 AM, Phillip Hallam-Baker wrote: So we need to extend the UPNP protocol so that when the local NAT box receives a request to open up an external port, it relays the request to the carrier NAT. So what are you waiting for? Go ahead, read http://upnp.org, find the relevant WG, propose the extension, talk to implementers, you know the routine as well as I do. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= p...@cisco.com Messier than what I think many people think. Including me (and I thought I had quite good overview of how it worked). The difference between theory and practise is even bigger in practise than it is in theory. -- Our very own S. Crocker :-) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 31 maj 2010, at 19.35, Noel Chiappa wrote: The difference between theory and practise is even bigger in practise than it is in theory. -- Our very own S. Crocker I have for years said In theory there is no difference between theory and practice, but in practice there is. Jan L. A. van de Snepscheut/Yogi Berra :-) Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Phillip Hallam-Baker wrote: The problem can be solved by carefully designing connection establishment protocols to support multiple addresses of a host, which means no solution exists at the connectionless layer of IP. Modified TCP, which send multiple SYN to several addresses of a peer helps a lot to reduce timeout. I am pretty sure we can fix the problem if we are prepared to adapt the stack somewhat. FYI, modified socket API and TCP with multiple IPv4 and/or IPv6 (optionally with ID/locator separation) addresses was designed and implemented several years ago. It's not very hard unless you desperately try to solve the problem at the connectionless IP layer. But, I see no point to insist on IPv6 with a lot of wrong design choices. The alternative is to do nothing and let various people hack the stack up completely with meat axes and then we will be working round the consequences for decades. The alternative is to live with IPv4 with port restriction, which is a lot more realistic because we can continue to use the current backbone. But really, the challenge is that carrier grade NAT works just fine for the ISPs who have the decision making power here. While legacy NAT is a form of port restricted IP, lack of end to end transparency is still a problem. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 28 maj 2010, at 21.39, Jari Arkko wrote: ... the simplest (and recommended) way to do this is to use dual stack (full stop). Unfortunately on applications layer I do not see enough operational experience/best practice/actual implementations that handle this in a very good way. The number of people I talk with that are nervous the cost for customer support will be higher(!) for dual stack situations than IPv6 only. I.e. that there are some arguments in favor of one day simply give the client an IPv6 address only instead of an IPv4 address only. That I get the question, that people think in these terms, I think is interesting. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Patrik, ... the simplest (and recommended) way to do this is to use dual stack (full stop). Unfortunately on applications layer I do not see enough operational experience/best practice/actual implementations that handle this in a very good way. There are issues, of course. The number of people I talk with that are nervous the cost for customer support will be higher(!) for dual stack situations than IPv6 only. I.e. that there are some arguments in favor of "one day simply give the client an IPv6 address only instead of an IPv4 address only". That I get the question, that people think in these terms, I think is "interesting". It is interesting, and naturally there will be a day when IPv6-only is the preferred model. The day comes at different times for different people. I'm already there myself. However, we have to understand this situation not merely from the point of view of whether there are issues with dual stack. There are. But there are also issues with IPv6 only. My personal experience is that in today's world, dual stack works better due to its greater operational experience, software availability, and other reasons. Others may have their own experiences and may draw different conclusions. What I would like to advocate, though, is making decisions on network architecture based on actual operational experience as opposed to assumptions (e.g., "just one address implies no problems"). Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 28 May 2010, at 17:39, David Conrad wrote: On May 28, 2010, at 8:57 AM, Arnt Gulbrandsen wrote: Consider bittorrent. Bittorrent clients generally can run behind NAT, but in that case they have to be on the same ethernet as the NATbox, so it's a safe bet that the bittorrent USER has a real address. Am I stepping out on a limb if I state that most users can run bittorrent? No idea. No clue how popular bittorrent is. I was under the impression that the vast majority of folks on residential-level connections were sitting behind a NAT box. Perhaps my impression is wrong? BitTorrent is popular, yes. People at home *are* behind NAT boxes, with all the usual pain that implies *. It's just that BitTorrent, being a straightforward TCP protocol with no embedded payload addresses **, can operate behind NATs, and those NATs can be configured either manually or automatically by users or their client software ***. If the NAT should move to the ISP, it seems possible that this is no longer true. Cheers, Sabahattin * Subjective, I know, but people for whom NAT is not a problem are not full participants of the Internet, and do not use it to full potential. Most of them think the web is the Internet. I regret losing my public addresses to the cloud. ** Actually, BitTorrent does allow clients to tell trackers their addresses, for example to get around proxies; in such cases dynamic addresses are a problem, as are cases where tracker and client live on the same machine, as happens when publishing. This doesn't affect most users though, because trackers default to taking the public IP address of the connecting client as the peer address given to other clients. *** Of course, there's still a learning curve, in which users will sooner or later become acquainted with the mechanics of port forwarding and all that; it rarely Just works. I'm reluctant to admit everybody capable of comprehending this stuff at first blush; certainly there are many peers who are firewalled and thus get reduced speeds. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 05/30/2010 04:44 PM, Sabahattin Gucukoglu wrote: BitTorrent is popular, yes. People at home *are* behind NAT boxes, with all the usual pain that implies *. It's just that BitTorrent, being a straightforward TCP protocol with no embedded payload addresses **, can operate behind NATs, and those NATs can be configured either manually or automatically by users or their client software ***. If the NAT should move to the ISP, it seems possible that this is no longer true. Not quite. 1. Bittorrent clients connect to each other via TCP. Each connection is incoming at one end. Torrent clients mostly use UPNP to accept incoming connections. 2. UPNP is an ethernet-level protocol (it uses UDP/IP broadcasts), so it works only if the USER is on the public internet. Hence, NAT within the user's network is now very different from NAT within the ISP's network. That's why I said the wide popularity of bittorrent shows that USERS are on the public internet. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 30 May 2010, at 16:02, Arnt Gulbrandsen wrote: On 05/30/2010 04:44 PM, Sabahattin Gucukoglu wrote: BitTorrent is popular, yes. People at home *are* behind NAT boxes, with all the usual pain that implies *. It's just that BitTorrent, being a straightforward TCP protocol with no embedded payload addresses **, can operate behind NATs, and those NATs can be configured either manually or automatically by users or their client software ***. If the NAT should move to the ISP, it seems possible that this is no longer true. Not quite. 1. Bittorrent clients connect to each other via TCP. Each connection is incoming at one end. Torrent clients mostly use UPNP to accept incoming connections. 2. UPNP is an ethernet-level protocol (it uses UDP/IP broadcasts), so it works only if the USER is on the public internet. Hence, NAT within the user's network is now very different from NAT within the ISP's network. That's why I said the wide popularity of bittorrent shows that USERS are on the public internet. Right, yes, I didn't see it from that standpoint. However UPnP can of course be substituted by NAT-PMP/PCP or something else that doesn't have the same discovery problem, and ISP-level NATs will no longer be a Problem for clients needing incoming connections even though they can no longer be said to be Public. Of course we're assuming that clients are in direct contact with their gateway here, I'm not sure how true that is, there may need to be added proxying to replicate requests otherwise. It certainly isn't impossible to do. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
In message e4783be7-33a8-46f3-b9bf-5273c82ee...@cisco.com, =?iso-8859-1?Q?Pat rik_F=E4ltstr=F6m?= writes: On 28 maj 2010, at 21.39, Jari Arkko wrote: ... the simplest (and recommended) way to do this is to use dual stack (full stop). Unfortunately on applications layer I do not see enough operational experience/best practice/actual implementations that handle this in a very good way. The number of people I talk with that are nervous the cost for customer support will be higher(!) for dual stack situations than IPv6 only. I.e. that there are some arguments in favor of one day simply give the client an IPv6 address only instead of an IPv4 address only. And have any of those that say this tried: 1) tried dual stack 2) tried IPv6 only through NAT64 (NAT-PT) with a sample of customers or are they just talking without any reference points. There is a lot of legacy equipment that requires IPv4 for something (e.g Windows XP for DNS servers, NFS support, ...) so you can't go to IPv6 only on the local net. Dual-stack in one form or another will be with us for a long time on the local net. Runing dual stack internally without external IPv4 connectivity is just as bad as running dual stack internally without external IPv6 connectivity. You just don't want to go down that path. We are years away from being able to run IPv6 only networks locally. There is way too much software that is not IPv6 ready. Yes. I've tried to run IPv6 only. Real IPv6 only, IPv4 completely disabled in the OS. It wasn't fun. Mark That I get the question, that people think in these terms, I think is interesting. Patrik -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 31 maj 2010, at 03.39, Mark Andrews wrote: And have any of those that say this tried: 1) tried dual stack 2) tried IPv6 only through NAT64 (NAT-PT) with a sample of customers or are they just talking without any reference points. I am spending lots of my time trying to get some _real_data_, but I do not have it yet. I am though running dual stack with native IPv4 and native IPv6 in my home office, on all my servers, and have quite some experience on dual stack. And that was not as fun as I expected. I.e. my data is based on dual stack be worse than I expected, and having people asking me would native IPv6 only be better, or what about native IPv6 with NAT64/DNS64. And I have also read various papers people in IETF have written on how to handle the quite normal case with SMTP where MX records are in use (which have been far from complete), and then maybe IP6 or IPv4, and IPv6 or IPv4 for DNS transport, and quite often search paths in DNS as well... The number of DNS lookups needed explode exponentially, you get timeouts on application layer, applications show timeout boxes as if the mail server is not responding when in reality multiple seconds are used for DNS lookups. It is messy with dual stack. Messier than what I think many people think. Including me (and I thought I had quite good overview of how it worked). Runing dual stack internally without external IPv4 connectivity is just as bad as running dual stack internally without external IPv6 connectivity. You just don't want to go down that path. I claim it is worse than having IPv6 only. Yes. I've tried to run IPv6 only. Real IPv6 only, IPv4 completely disabled in the OS. It wasn't fun. So have I. For example at the IETF in Anaheim one morning when IPv4 connectivity was broken. For me it worked better than dual stack, when accessing things that was reachable over IPv6. But that was with my OS (MacOSX) that have relatively good IPv6 support. So there are good things and bad things with both dual stack and IPv6 only. And no, we do not have any data, but we do not have good documents on how to run dual stack either. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Ofer Inbar wrote: ... what's next? Carrier-based NAT? Virtual-hosting encrypted http? Actually using IPv6 en masse? Something else? Something else of port restricted IP, with which an IPv4 address can be shared by 100 or 1,000 hosts while keeping the end to end transparency. Heavy use of NAT causes lots of problems and will continue to. End to end NAT is a form of port restricted IP without any problem of legacy NAT. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 2010-05-28 04:51, David Conrad wrote: ... Well, no. While that is a problem, I suspect the real issue is: 'Within 18 months it is estimated that the number of new devices able to connect to the world wide web will plummet as we run out of IP addresses' I strongly suspect that Daniel said connect directly, which is certainly true when an ISP runs out of global IPv4 addresses. and this quote: The internet as we know it will no longer be able to grow, That's just factually incorrect Today, most users are *not* behind ISP NAT or some other form of global address sharing. A double-NATted Internet is very different from a single-NATted Internet as we know it today. and sensationalistic hype. Whether it is counter-productive depends on whether people simply dismiss it out of hand as yeah, yeah, just like the world will end at Y2K. IPv4 free pool runout simply means connecting to the Internet is going to get more expensive. No, it means it is going to require double NAT unless providers deploy IPv6. That is the message that needs to be got across. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Patrik, Of course, the exact depletion date experienced by an ISP will vary very widely. 2015 is the date *most frequently* cited by the ISPs reported on in draft-ietf-v6ops-isp-scenarios. Regards Brian Carpenter On 2010-05-28 17:04, Patrik Fältström wrote: I also think 2015 is very optimistic for some players. Specifically cellphone providers that provide data access over for example 3G or 4G. The growth is so fast that the block allocations from the RIRs are hard to compute. I helped one at the last RIPE meeting in Prague, and then will now get a /13 that will help them through calendar year 2010. They will definitely not be able to get today the addresses they need until 2015. And they definitely do not have it. And that is in Sweden, only 9 million people. Patrik On 27 maj 2010, at 22.02, jason.w...@cox.com wrote: 2015 seems awfully optimistic. I wouldn't want to be the poor soul responsible for their ISP network who built a transition plan based on a 2015 depletion and then realized I was wrong by a few years. Jason -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, May 27, 2010 12:14 PM To: Ole Jacobsen Cc: Noel Chiappa; ietf@ietf.org Subject: Re: IPv4 depletion makes CNN On 2010-05-28 02:44, Ole Jacobsen wrote: I guess my point was more that this article actually quotes a *real* expert rather than someone we've never heard of --- a more common practice for the press. Whether or not you agree with Daniel, he does at least have extensive experience in these matters. The major problem with the story is that it confounds IANA runout (objectively predicted for 2011) with when ISPs run out of IPv4 space (which is not so easy to predict, but 2015 is a popular estimate). The rest is pretty good for a story in the non-technical media, IMHO. You can find Daniel's recent talk at http://www.ipv6.ie/summit2010/. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
- Original Message - From: Mark Andrews ma...@isc.org To: Ofer Inbar c...@a.org Cc: ietf@ietf.org Sent: Friday, May 28, 2010 12:37 AM The point of the article was to make more people aware of IPv6 and to urge them actually start planning to move to IPv6. I've got IPv6 at home today (tunneled). If my ISP moves to CGN without also enabling native IPv6 I will loose my IPv6. That would be going backwards. For the client side there is no downside in enabling IPv6 today. Recently I set up a new account with the incumbent ISP and asked their sales department (several times) about IPv6 support. Their reply was odd, and I eventually found that the translation was 'you have mentioned something we have had no training in so this is our stock response.' This persisted even when I got into second and third level support, so there are big ISP out there who have not yet heard of IPv6. We have a long way to go and not much time to go it in. Tom Petch Mark You can find Daniel's recent talk at http://www.ipv6.ie/summit2010/. I can find a link to his talk on that site, but each time I click on that link I get a quickly-broken TCP connection. Overloaded, perhaps? -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
The size and timing of the address resource problem depends on your viewpoint, of course. Your existing address resources, your growth rate, your subscriber base, the extent to which more NATs remove your problem all vary. But I would argue this does not really matter so much. I think we have already run out of the addresses, with consequent implications to applications, end-to-end nature of the Internet, and business planning. Just as an example, one mobile operator who participates in the IETF IPv6 and NAT work has half a billion subscribers. Think their planning revolves around asking the RIRs for an address to each customer, as they are rapidly transitioning from circuit switched voice to voip and browser/email/google/facebook-on-everyone's-device model? Arguing about exact dates or the level of catastrophe seems like rearranging the deck chairs on Titanic. Things will be bad. We should focus on changing the direction and making things better. In any case, I think we are missing the point if we try to argue about the accuracy of mainstream media news articles. Of course they are simplified and twisted to a ridiculous level. Just check any other article where you knew what really was going on. But I think the important point is that a change is needed. For that to happen, we need to have both an alternative and global awareness of the problem. We will need also mainstream news articles in the latter. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 05/28/2010 03:42 PM, Jari Arkko wrote: We will need also mainstream news articles in the latter. Expect that around the end of July, intoning «In one year, the Internet Assigned Numbers Authority is expected…» Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= p...@cisco.com As native IPv6 connections are compared more and more with IPv4 NAT:ed connections, I think this will go quicker than what people think. Note that most of the difference between the protocols are features and operational experiences the ISPs have. For the end user...how much difference is there really in how Google or Facebook works? ... The end user though, will not notice when IPv6 is in use. Really? As far as I can tell, there is still no general, defined, method to allow an IPv6 host with a v6-only address (i.e. not an IPv4 address embedded in an IPv6 address) to talk to an IPv4-only host. So, for all that content which is IPv4 only, how does an IPv6-only host get to it? And if there is no 'it just works' mechanism to do so, people will definitely notice if their machines convert to IPv6. (I'm not talking about ISPs which use IPv6 internally, but don't expose it to the user: that just like ISPs which use ATM internally, but don't expose it to the user - yet another internal technology. I'm talking about the _users_ using IPv6 as their service interface. CGNAT doesn't count either, that's just a differently engineered NAT - i.e. existing IPv4 technology.) I mean, for example, people go to lots and lots of web sites, so saying 'oh, as long as the big top sites support IPv6 access to content, that's all we need' won't cut it. Yes, the top content providers get the bulk of the traffic, but the tail (even for an individual) is very long. So are people really going to want to convert to IPv6, unless there's some 'it just works' mechanism that lets them get to basically everyone in that long tail? Without having _all_ the content v6-accessible, I reckon there's a _substantial_ actual disincentive for users to go v6-only. (Think Metcalfe's Law.) And without a lot of users who are v6-only, what's the incentive for _everyone_ to make content available in v6? (Close loop, feed back.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 2010-05-29 03:01, David Conrad wrote: On May 28, 2010, at 1:29 AM, Brian E Carpenter wrote: Today, most users are *not* behind ISP NAT or some other form of global address sharing. An interesting assertion. I'd agree on the ISP NAT part. Not sure about the other form of global address sharing part, since single NAT is address sharing. Do you have any data? Sorry, I should have written subscribers instead of users. Most subscribers get global addresses on the outside of their domestic gateway, but of course that gateway is unfortunately a NAT in most cases. IPv4 free pool runout simply means connecting to the Internet is going to get more expensive. No, it means it is going to require double NAT unless providers deploy IPv6. I've been told on numerous occasions that multi-layer NAT will significantly increase opex. Yes. It will also significantly increase breakage at application level. I understand there is plenty of running code proof of this, for example in India. That is the message that needs to be got across. I suspect your message will result in a response of Double whasis? I can still get my pr0n, right?. I'd imagine a message that says you're going to end up paying more for your pr0n will get more people's attention. In fact I think the message now should be to content *providers*, because they will bear the costs unless they pressure their ISPs into doing the right thing. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 05/28/2010 05:01 PM, David Conrad wrote: On May 28, 2010, at 1:29 AM, Brian E Carpenter wrote: Today, most users are *not* behind ISP NAT or some other form of global address sharing. An interesting assertion. I'd agree on the ISP NAT part. Not sure about the other form of global address sharing part, since single NAT is address sharing. Do you have any data? Consider bittorrent. Bittorrent clients generally can run behind NAT, but in that case they have to be on the same ethernet as the NATbox, so it's a safe bet that the bittorrent USER has a real address. Am I stepping out on a limb if I state that most users can run bittorrent? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Noel , Really? As far as I can tell, there is still no general, defined, method to allow an IPv6 host with a v6-only address (i.e. not an IPv4 address embedded in an IPv6 address) to talk to an IPv4-only host. So, for all that content which is IPv4 only, how does an IPv6-only host get to it? And if there is no 'it just works' mechanism to do so, people will definitely notice if their machines convert to IPv6. For your specific problem there is NAT64 - http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework and related drafts (soon in IETF last call). This is an improved version of the old NAT-PT mechanism. FWIW, I have been behind some of this stuff for some time. It generally just works, largely for the same definition of just works that we have for plain old IPv4 NATs, i.e., its far from a perfect solution but still workable. There are a few additional issues though that get exposed when you turn your network into an IPv6-only network. There's generally very little operational experience of running IPv6-only networks, so you'll be likely to run into at least some issues, such as specific apps that fail to use IPv6-capable APIs, network detection tool confusion from lack of IPv4 connectivity, DNS configuration issues, and so on. Given all this, the general advice is still to run both IPv4 and IPv6. Some networks are going to try the IPv6-only model even now, however, and I hope that in a couple of years we can be there with a larger number of users. But it is going to take work, mostly operational and implementation work, perhaps also some minor standard changes. One example of the type of standard changes is what we are currently doing in 6MAN, bringing RFC 5006-based DNS discovery to a standard from an experimental specification. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
In message 20100528154216.d9fee6be...@mercury.lcs.mit.edu, Noel Chiappa write s: From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= p...@cisco.com As native IPv6 connections are compared more and more with IPv4 NAT:ed connections, I think this will go quicker than what people think. Note that most of the difference between the protocols are features and operational experiences the ISPs have. For the end user...how much difference is there really in how Google or Facebook works? ... The end user though, will not notice when IPv6 is in use. Really? As far as I can tell, there is still no general, defined, method to allow an IPv6 host with a v6-only address (i.e. not an IPv4 address embedded in an IPv6 address) to talk to an IPv4-only host. A IPv6 only host has to have access to a IPv4 address to talk to IPv4 only hosts. The simplest way to do this is to actually stay dual stack and use DS-lite. The other way is to go through a NAT64 which will tend to break more applications as it need to change more on the data streams. So, for all that content which is IPv4 only, how does an IPv6-only host get to it? And if there is no 'it just works' mechanism to do so, people will definitely notice if their machines convert to IPv6. The are product which do DS-lite today. There are products that do NAT64 today. As for people noticing. They won't generally notice IPv6 being turned on. They will notice IPv4 being turned off. But one does not imply the other. (I'm not talking about ISPs which use IPv6 internally, but don't expose it to the user: that just like ISPs which use ATM internally, but don't expose it t o the user - yet another internal technology. I'm talking about the _users_ using IPv6 as their service interface. CGNAT doesn't count either, that's jus t a differently engineered NAT - i.e. existing IPv4 technology.) I mean, for example, people go to lots and lots of web sites, so saying 'oh, as long as the big top sites support IPv6 access to content, that's all we need' won't cut it. Yes, the top content providers get the bulk of the traffic, but the tail (even for an individual) is very long. So are people really going to want to convert to IPv6, unless there's some 'it just works' mechanism that lets them get to basically everyone in that long tail? Without having _all_ the content v6-accessible, I reckon there's a _substantial_ actual disincentive for users to go v6-only. (Think Metcalfe's Law.) And without a lot of users who are v6-only, what's the incentive for _everyone_ to make content available in v6? (Close loop, feed back.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On May 28, 2010, at 8:57 AM, Arnt Gulbrandsen wrote: Consider bittorrent. Bittorrent clients generally can run behind NAT, but in that case they have to be on the same ethernet as the NATbox, so it's a safe bet that the bittorrent USER has a real address. Am I stepping out on a limb if I state that most users can run bittorrent? No idea. No clue how popular bittorrent is. I was under the impression that the vast majority of folks on residential-level connections were sitting behind a NAT box. Perhaps my impression is wrong? Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
My objective when talking to reporters who write for the *business* section is to project that mere awareness is not good enough anymore for businesses; businesses need to have a plan. For you all on this list this should help the next time you talk to the suits who decide about strategy and investments ... independently of which particular strategy you are going to recommend. The non-technical press always simplifies and exaggerates; this is a fact of life. I am sure all of us evaluate news stories based on the source. It is fine if you say to the suits this is exaggerated, let's .., just make the right recommendation or decision. ;-) This reporter did a very reasonable job considering the space he has to operate in. And no I am not going to ask them to rectify the technical inaccuracies that crept in. This is besides the main point to the intended audience. Daniel Karrenberg Chief Scientist RIPE NCC PS: Note that I just re-subscribed to this list in order to react. I had left it because I do not currently have any work in the IETF and I stay away as long as I have no work here; I will visit in Maastricht though since it is 30 mins down the road from my home and a nice place to be in general. PPS: Recommendations: Brussels airport is closer than Amsterdam by high speed train. Rent a bicycle in Maastricht. Get out of the conference centre and meeting hotel! If you are not cycling you can walk to downtown or take the buses that leave about every 10 minutes during the day. Keep your passport with you, the city borders on Belgium in the west and you may be there before you know it. Aachen in Germany is close by, by public bus, worth the trip. Daniel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Mark, A IPv6 only host has to have access to a IPv4 address to talk to IPv4 only hosts. The simplest way to do this is to actually stay dual stack and use DS-lite. ... the simplest (and recommended) way to do this is to use dual stack (full stop). DS-Lite is needed in some situations, primarily if you want to enable a v6-only ISP network and want to share one IPv4 address among multiple subscribers. But regular dual stack works very well, too, and is often deployed in the NATted-IPv4 and routed IPv6 configuration. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
In message 4c001bd5.4020...@piuha.net, Jari Arkko writes: Mark, A IPv6 only host has to have access to a IPv4 address to talk to IPv4 only hosts. The simplest way to do this is to actually stay dual stack and use DS-lite. ... the simplest (and recommended) way to do this is to use dual stack (full stop). DS-Lite is needed in some situations, primarily if you want to enable a v6-only ISP network and want to share one IPv4 address among multiple subscribers. But regular dual stack works very well, too, and is often deployed in the NATted-IPv4 and routed IPv6 configuration. Jari The simplest thing for the medium term is full dual stack, but at some point one is going to need to share IPv4 addresses between different customers and DS-lite will break less things than NAT64. Any box that supports tunnelling IPv4 in IPv6 can be the B4 component with a little bit of tweaking. DS-lite also keeps all the internal IPv4 legacy boxes working. By tweaking I mean configuring the DHCPv6 client to request the appropriate option then calling out to configure the tunnel and IPv4 routing table. If one is trying to reduced the size of the IP stack on the client (e.g. in a phone) then NAT64 may be a better alternative but for home users it really isn't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
Jari Arkko wrote: A IPv6 only host has to have access to a IPv4 address to talk to IPv4 only hosts. The simplest way to do this is to actually stay dual stack and use DS-lite. ... the simplest (and recommended) way to do this is to use dual stack (full stop). Do you mean IPv6 deployment has fully stopped? DS-Lite is needed in some situations, But regular dual stack works very well, too, Thank you for demonstration of self-inconsistency. A problem of IPv6, among many, is that it can't properly handle hosts with multiple (IPv4 and IPv6 or IPv6 and IPv6) addresses, a.k.a. multihomed hosts. As the proper support for multihoming needs careful and fundamental design at the IP, transport and application layers, latter tweaking of DS or DS-light can not be useful. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IPv4 depletion makes CNN
http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 27 May 2010, at 14:16, Ole Jacobsen wrote: Is that the Matt Ford who works for ISOC or somebody else? The latter. The person quoted is well-known, so that makes me think this story was written by someone with a clue. No comment ;) Mat ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
